how to debug DNS propagation for a custom email domain

You changed your MX records, added SPF, published a DKIM key, and your email provider's dashboard still says "not verified." It's been two hours. Maybe three. You're refreshing the portal like it owes you something.

DNS propagation issues are the single most common reason custom domain email setups stall. The records are correct, the syntax is fine, but something between your registrar and the rest of the internet hasn't caught up yet. This guide walks through exactly how to debug it, record by record, tool by tool.

If you'd rather not wrestle with DNS at all, get your agent its own inbox on LobsterMail and it works immediately. No DNS required. But if you're already deep into TXT records, keep reading.

How to debug DNS propagation for a custom email domain#

Here's the full debugging process, start to finish:

1. Lower your TTL to 300 seconds at least 24 hours before making any DNS changes.
2. Add or update your MX, SPF, DKIM, DMARC, and domain verification TXT records at your DNS host.
3. Run a global propagation check on dnschecker.org or whatsmydns.net for each record type individually.
4. Use dig or nslookup to confirm the record value matches exactly what your email provider expects, character by character.
5. Check for trailing spaces, subdomain misplacement, or quoting issues in TXT records.
6. If the provider portal still shows "unverified," remove and re-add the domain to trigger a fresh validation attempt.
7. Wait for the old TTL to expire, then re-test in the regions that were failing.
8. Confirm all five record types resolve correctly from at least three continents before marking setup as complete.

Most issues resolve within 30 minutes if your TTL was already low. If you created records on a fresh domain with a default 24-hour TTL, expect a much longer wait.

The five records you need (and how to check each one)#

Email DNS isn't a single record. It's five independent records that all need to propagate on their own schedules.

MX records tell other mail servers where to deliver email for your domain. Wrong or missing MX records mean inbound mail bounces immediately. Check yours with:

dig MX yourdomain.com +short
**SPF records** declare which servers are authorized to send email on your domain's behalf. A missing SPF record won't block sending outright, but recipients will treat your messages as suspicious. SPF lives inside a TXT record:

dig TXT yourdomain.com +short | grep "v=spf1"
**DKIM records** are public keys published as TXT records under a selector subdomain (something like `selector1._domainkey.yourdomain.com`). They allow recipients to verify the email body wasn't tampered with in transit. The most common DKIM mistake is placing the record on the wrong subdomain:

dig TXT selector1._domainkey.yourdomain.com +short

DMARC records tie SPF and DKIM together with a policy telling recipients what to do when authentication fails. DMARC lives at _dmarc.yourdomain.com:

dig TXT _dmarc.yourdomain.com +short

Domain verification TXT records prove to your email provider that you control the domain. These are provider-specific, usually a random string you add to your root domain's TXT records.

All five must be live and correct at the same time. Four out of five won't do it.

Why propagation looks complete but email still fails#

I see this catch people constantly. You check dnschecker.org, see green checkmarks across the globe, and assume everything is working. Then your provider's dashboard still reads "not configured."

Three common causes:

Your provider cached a negative result. When the provider first queried your domain and found no records, it stored that "not found" response internally. Even after global propagation completes, the provider may hold onto the stale result for hours. Removing the domain from the provider dashboard and re-adding it forces a fresh DNS lookup. Azure Communication Services, for example, has no manual "recheck" button, so this remove-and-readd approach is your only option.

You checked the wrong record type. dnschecker.org defaults to A records. If you're debugging email, you need to select MX or TXT from the dropdown explicitly. Green checks on A records tell you absolutely nothing about your mail configuration.

Regional resolver caching is stale. Your local ISP's recursive resolver may cache old records longer than the TTL suggests. Switch to a public resolver for testing:

dig @8.8.8.8 MX yourdomain.com +short
dig @1.1.1.1 TXT yourdomain.com +short

If the public resolvers show the correct value but your ISP's resolver doesn't, the issue is local caching and it will resolve on its own once the old TTL expires.

What happens to email during propagation#

Here's the question nobody answers clearly: what happens to mail sent to your domain while DNS records are still propagating across the globe?

If you're migrating from one email provider to another, both old and new MX records may be active in different regions at the same time. Some mail routes to the old server, some to the new one. This is expected behavior, not a bug. It's how DNS works during transitions, and both servers should be capable of accepting mail until propagation completes everywhere.

If you're setting up a brand-new domain with no prior MX record, the situation is worse. Mail sent before your MX records propagate will bounce permanently with a "no MX record found" error. Those messages are not queued or retried by the sender's server. The sender gets a bounce notification, and you never see the email. This is why you should verify propagation fully before sharing your new address with anyone.

For agents that need a working email address right now, waiting hours for DNS to settle across dozens of global resolvers is a non-starter. LobsterMail's @lobstermail.ai addresses work the instant they're created because the DNS is pre-configured. When you're ready to send from your own custom domain, LobsterMail validates propagation automatically and only activates the domain once every record is confirmed live.

Tools worth using#

I skip the ad-heavy SEO farm sites. These three actually do the job:

• whatsmydns.net shows propagation status from 49+ global locations. Select the record type manually; it defaults to A, which is useless for email debugging.
• dnschecker.org offers a similar global view with a different server list. Good for a second opinion when whatsmydns results look inconsistent.
• dig on your own machine gives the most control. Use +trace to follow the full resolution chain from root servers down to your authoritative nameserver, which pinpoints exactly where a stale cache is hiding:

dig +trace TXT _dmarc.yourdomain.com

For automated checks in CI pipelines or agent workflows, query DNS programmatically instead of refreshing a browser tab:

# Verify MX record matches expected value
dig +short MX yourdomain.com | grep -q "mail.provider.com" \
  && echo "MX OK" || echo "MX MISSING"

You can run this against multiple public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9) in a loop to approximate a global propagation check without any web UI.

When DNS isn't actually the problem#

Sometimes every record is correct and fully propagated, and email still doesn't work. At that point, stop debugging DNS. Look at these instead:

Sending reputation. A brand-new domain with no sending history will land in spam regardless of perfect authentication records. You need to warm the domain gradually over days, starting with small volumes to engaged recipients who will open and reply.

SPF alignment failures. SPF might pass on its own, but if the From: domain doesn't align with the Return-Path: domain, DMARC still fails. This is a common gotcha after switching providers, because the new provider's bounce address often uses a different domain than your visible From: header.

Content filtering. Some recipients run aggressive filters that reject or quarantine messages based on body content, link reputation, or attachment types. Perfect authentication doesn't override content-based rules.

Start with the eight-step debugging process at the top of this article before chasing reputation or content problems. Get DNS right first. If you'd rather skip DNS management entirely, LobsterMail handles record validation and propagation monitoring automatically when you connect a custom domain, and the free tier gets you started at $0 with 1,000 emails per month.