--- title: "Why domain verification should never be a one-time check" description: "DNS changes after you verify a domain. How continuous re-verification with a grace period catches regressions without turning a transient blip into an outage." url: https://www.unitpost.com/blog/continuous-domain-verification section: Blog updated: 2026-07-27 --- # Why domain verification should never be a one-time check Most platforms verify a sending domain once and trust it forever, which breaks silently when DNS changes — a migration drops a record, a registrar edit removes DKIM, and mail starts failing authentication with no signal. Continuous re-verification catches that, but it needs a grace period, or a transient DNS timeout becomes a sending outage. ## Why domain verification should never be a one-time check > DNS changes after you verify a domain. How continuous re-verification with a grace period catches regressions without turning a transient blip into an outage. Domain verification is usually treated as onboarding: add records, click verify, done. That model assumes DNS is static. It isn't. Domains get migrated between registrars, records get pruned during cleanups, and a well-meaning change to consolidate TXT records drops a DKIM selector. ### The failure is silent, which is the problem When authentication records disappear, sending doesn't stop. Messages go out, fail authentication at the receiver, and land in spam. From the sender's side everything looks healthy — the API returns success, the dashboard shows sends — while delivery quietly collapses. That gap between apparent and actual health is what makes one-time verification dangerous. ### Re-verifying continuously The fix is to keep checking. A background reconcile re-queries each verified domain's records on a schedule and compares them against what should be published. A regression is detected in minutes rather than whenever someone notices delivery has degraded. ### Why a naive version is worse than none If detection immediately blocks sending, you've built a system where any DNS hiccup stops your customers' password resets. Resolvers time out, authoritative servers have brief outages, and propagation is eventually-consistent. Treating a single failed lookup as proof of misconfiguration guarantees false positives on exactly the mail that matters most. So a verified domain that starts failing moves to a degraded state rather than straight to blocked: sending continues while the failure is retried with backoff. Only sustained failure escalates to blocked. Transient blips resolve themselves; genuine misconfiguration gets caught. > **What gates sending and what doesn't:** SPF, DKIM, and MX determine verified status. DMARC and tracking CNAMEs are detected and reported but deliberately don't gate sending — DMARC is a policy choice, and blocking sending because a customer hasn't set one would be us enforcing our opinion. ### Rotation without a gap The same reasoning applies to DKIM key rotation. Replacing a key in place means in-flight mail signed with the old key fails verification. Make-before-break avoids it: publish the new key, confirm it resolves, switch signing, and retire the old record only once nothing signs with it. ## FAQ ### How often should a sending domain be re-verified? Frequently enough that a regression is caught in minutes, with backoff so a persistently failing domain isn't queried aggressively forever. Roughly once a minute with exponential backoff up to a few hours is a reasonable shape. ### What should happen when a verified domain starts failing? Degrade, don't block. Keep sending, mark the domain as degraded, notify the owner, and retry. Escalate to blocked only after sustained failure. Blocking on the first failed lookup turns every DNS blip into an outage on your most critical mail. ### Does DMARC need to pass before I can send? It shouldn't be required by your provider. DMARC is a policy you publish about how receivers should treat authentication failures — valuable, and increasingly expected by mailbox providers, but a choice. SPF, DKIM, and MX are what prove you control the domain. ## Related - [How to let an AI agent send email safely](https://www.unitpost.com/blog/send-email-from-ai-agent): The concrete controls that make agent-initiated email safe: scoped credentials, a verified-domain gate, idempotency, approval before send, and an audit trail. - [What is an email MCP server?](https://www.unitpost.com/blog/email-mcp-server): How Model Context Protocol exposes email sending as agent tools, what a well-designed email MCP surface looks like, and how authentication and scopes work. - [How to fix an SPF record that isn't found](https://www.unitpost.com/blog/spf-record-not-found): Why an SPF lookup returns nothing even after you've added the record, and how to diagnose it: propagation, wrong host, quoting, and the one-SPF-record rule.