That asymmetry, sending works and receiving doesn’t, is the single most useful clue in the whole problem. It narrows the search enormously. Yet most guides on Zoho Mail not receiving email open by telling you to check your SPF record, which has nothing whatsoever to do with inbound delivery. People lose a full day tuning an SPF string while their MX records quietly point at a data center that has never heard of their domain.

This guide walks the inbound path in the order a sending mail server actually walks it, groups the real causes by failure family, and gives you the exact commands to prove which one you’re looking at. Everything here applies whether your DNS lives at Cloudflare, Namecheap, GoDaddy, Route 53, or a cPanel box at InterServer or Contabo.

Sending and receiving are two separate systems

This is worth internalizing before you touch a single DNS record, because it eliminates most of the internet’s advice on this topic in one move.

When you send from Zoho, your client authenticates against Zoho’s outbound SMTP server with a username and password. Your domain’s DNS plays no part in that handshake. SPF, DKIM and DMARC records exist so that the recipient’s server can decide whether to trust mail claiming to be from you. They are judgements other people make about your outbound mail.

When someone sends to you, none of that matters. Their server looks up your MX records, connects to whatever hostname it finds, and hands the message over. Your SPF record is never consulted. Your DKIM key is never consulted.

So if outbound works and inbound doesn’t, the fault is in the MX lookup, the connection that follows it, or Zoho’s decision about what to do with the message once it arrives. Not SPF. There is one narrow exception, covered later, where Zoho’s own inbound spam checks reject mail because the sender’s SPF fails. That is a different record on a different domain.

The inbound path, in the order it actually happens

Six things happen between someone hitting send and a message appearing in your Zoho inbox:

1. The sending server splits the recipient address and takes the domain part.
2. It asks DNS for the MX records of that domain, following delegation from the root down to whichever nameservers the registry says are authoritative for you.
3. It sorts the results by preference number and takes the lowest one first.
4. It resolves that hostname to an address record.
5. It opens an SMTP connection and offers the message with MAIL FROM and RCPT TO.
6. The receiving server decides whether that recipient exists in its organization and where to file the message.

Steps two through four are pure DNS. Step five is network. Step six is Zoho configuration. Diagnosing this well is mostly a matter of finding out which step you’re stuck on instead of guessing.

Five DNS failure families behind Zoho Mail not receiving email

Nearly every inbound failure I’ve seen falls into one of these. They present almost identically from the user’s chair, which is why guessing goes badly.

1. You’re editing records at a provider that isn’t authoritative

This is the most common one and the most frustrating, because the records look perfect in the control panel you’re staring at. They’re just not the records the internet reads.

It happens whenever the domain is registered in one place and the nameservers point somewhere else. You buy at Namecheap, delegate to Cloudflare, then add MX records back in the Namecheap DNS panel out of habit. Or a previous developer moved DNS to a hosting account you no longer log into. The registrar panel accepts your edits and stores them faithfully. Nobody queries them.

Find out where authority actually sits:

# Which nameservers does the parent zone delegate to?
dig +short NS example.com

# What do those nameservers say about your MX, directly?
dig MX example.com @ns1.yourprovider.com +norecurse

# Watch the full delegation chain from the root
dig +trace MX example.com

The +trace output is the one to read carefully. It shows each referral step, so you can see exactly which nameserver set the world is being pointed at. If those names don’t match the provider where you’ve been editing, you’ve found your problem and the fix takes thirty seconds.

2. Correct-looking MX records for the wrong Zoho data center

This is the failure mode that stays invisible longest, and it’s the reason copying MX values off a random blog post is dangerous.

Zoho runs regional data centers, and your account lives in exactly one of them. The mail hostnames differ by region: the international service uses .com hostnames, and the European and Indian deployments use their own regional equivalents. Your domain’s mailboxes exist only in the data center where your organization was created.

Point your MX at the wrong region and everything looks healthy. The records resolve. The hostnames are genuine Zoho servers. A lookup tool will show green. But mail arrives at infrastructure that has no record of your domain, and senders get a rejection saying the address doesn’t exist, or nothing at all.

For the international service, Zoho’s documentation specifies three records, in this order of preference:

Priority 10   mx.zoho.com
Priority 20   mx2.zoho.com
Priority 50   mx3.zoho.com

Do not take that as gospel for your account. The authoritative source is the DNS Mapping section of your own Zoho Mail Admin Console, which shows the exact hostnames for the data center your organization sits in. Read them there, copy them from there. If you’re unsure which region you’re on, the domain in the URL when you log into the admin console tells you.

Verify what the world sees, not what your panel shows:

dig +short MX example.com

# Confirm the target hostname itself resolves
dig +short mx.zoho.com

3. Leftover MX records from whatever came before

MX preference is not a fallback list in the sense most people assume. A sending server tries the lowest number first, and if that server accepts the message, the transaction is over. It never touches the others.

So a stale record from your old host sitting at priority 0 or 5 doesn’t compete with Zoho. It wins outright, every time. The mail is delivered successfully, to a mailbox nobody checks, on a server that may still be quietly accepting for your domain. The sender sees no error. You see nothing at all.

This is also why partial migrations bite. Two providers both accepting mail for one domain means your messages split between them based on preference and retry timing, which looks like random message loss and is nearly impossible to reason about from the inside.

The rule is simple: after cutover, the only MX records in the zone should be Zoho’s. Delete everything else, including records for subdomains you forgot about. Check the full answer rather than a truncated view:

dig MX example.com +noall +answer

4. A CNAME sitting where the MX records live

Two related problems here, and both are structural rather than typos.

The first: an MX record must point to a hostname with an address record. Pointing an MX at a name that is itself a CNAME is forbidden by the DNS specifications, and Zoho documents this explicitly. Some resolvers cope, others don’t, and the ones that don’t will fail intermittently in ways that look like a network problem.

The second: a CNAME at the zone apex. Classic DNS forbids a CNAME coexisting with any other record at the same name, and MX records at the apex are exactly that. Providers like Cloudflare work around this with CNAME flattening, which synthesizes an address record and does keep your MX records functional. Providers with a naive implementation may shadow or drop them. If someone added an apex CNAME to point the bare domain at a hosting platform or a site builder, that’s worth checking early.

dig CNAME example.com +short
dig A example.com +short

One thing that is not a problem, despite frequent claims otherwise: Cloudflare’s orange-cloud proxy setting. Proxying applies to HTTP traffic on address records. It has no effect on MX records, and toggling it grey will not fix inbound mail.

5. DNSSEC left broken after a nameserver change

Less common, but spectacular when it happens, because it takes the entire domain down rather than just mail.

If DNSSEC was enabled and the DS record at the registry no longer matches the signing keys at your current DNS provider, validating resolvers refuse to return any answer at all. They return SERVFAIL. Non-validating resolvers still work, which is why the site loads fine for you and mail from major providers, who mostly validate, vanishes.

The test is a one-liner. +cd disables validation checking:

# Fails with SERVFAIL if validation is broken
dig MX example.com

# Same query, validation bypassed
dig +cd MX example.com

If the second command returns your records and the first doesn’t, you have a DNSSEC mismatch. The fix is at your registrar: either update the DS record to match your current provider’s keys, or remove DNSSEC entirely, confirm mail flows, and re-enable it properly afterwards.

When DNS is clean and mail still doesn’t arrive

If your MX records resolve correctly to the right data center and nothing else is in the zone, DNS has done its job. The remaining causes sit on either side of it.

Your own server is intercepting the mail

This catches people running a site on cPanel or DirectAdmin, and it’s genuinely counterintuitive. Control panels have an email routing setting per domain, typically offering local, remote, or automatic delivery. If it’s set to local mail exchanger, the mail server on that box delivers messages for your domain into its own accounts and never performs an MX lookup.

The effect is narrow but confusing: external senders reach Zoho normally, while anything sent from a script or a form on that server goes to a local mailbox instead. Contact form submissions disappear while ordinary email works. Set routing to remote mail exchanger on any host where the site lives but the mailboxes don’t.

The address doesn’t exist in your Zoho organization

Zoho will only accept mail for addresses it knows about. A user account, an alias on a user, or a group. If someone hands out an address that was never created, Zoho rejects it and the sender gets an address-not-found bounce that they may not think to forward to you.

Zoho supports a catch-all address for exactly this, and it’s worth setting one during a migration so misaddressed mail lands somewhere recoverable rather than bouncing into the void.

Zoho accepted it and quarantined it

Under Security and Compliance in the Admin Console, Zoho lets you decide what happens to mail that fails SPF, DKIM, DMARC or DNSBL checks. The available actions include delivering it, quarantining it, or rejecting it outright, with or without a bounce.

Set to reject-without-bounce, a sender whose own SPF is slightly wrong gets silently dropped, and neither party learns anything. This is the narrow SPF connection I mentioned earlier: it’s the sender’s SPF being judged, not yours. Check the incoming quarantine before concluding mail never arrived, and check the organization blocked list while you’re there, since a blocked domain or TLD produces exactly the same silence.

The domain lapsed or lost verification

If a domain expires, its DNS stops resolving and every associated record becomes unreachable, which also invalidates the domain verification Zoho performed. Zoho’s documentation notes that after renewal you have to reconfigure MX records as part of reverification. Renewing the domain alone doesn’t restore mail.

A troubleshooting sequence that ends in an answer

Work these in order. Each step either clears a layer or hands you the cause, so you never end up changing three things at once and losing track of which one worked.

1. Confirm delegation. Run dig +short NS example.com and check it matches the provider you’re editing. If not, stop here and fix that first.
2. Read the MX records from an authoritative nameserver. Use dig MX example.com @ns1.yourprovider.com so you’re seeing the source of truth rather than a cached copy.
3. Compare against the Admin Console. Open the DNS Mapping page in Zoho Mail and match hostnames character for character, including the regional suffix.
4. Confirm nothing else is in the answer. Any non-Zoho MX record is a suspect, especially one with a lower preference number.
5. Test resolution from a public resolver. Try dig MX example.com @1.1.1.1 and @8.8.8.8. Differences between them mean you’re mid-propagation and waiting is the fix.
6. Rule out DNSSEC. Compare dig MX example.com against dig +cd MX example.com.
7. Prove the SMTP conversation. Send a real test and watch what the server says.
8. Check quarantine and blocked lists in the Zoho Admin Console before concluding anything was lost.

For step seven, swaks is the cleanest tool. It speaks SMTP for you and prints the full exchange, so you see the actual response code rather than guessing from a bounce message:

# Stop after RCPT TO so no message is actually delivered
swaks --to you@example.com --server mx.zoho.com --quit-after RCPT

A 250 after RCPT TO means Zoho recognises the address and would accept the mail. A 550 means it doesn’t know that recipient, which points straight at a missing mailbox or the wrong data center. A connection timeout usually isn’t Zoho at all: many residential and cloud providers block outbound port 25 by default, so run this from a machine you know has egress on 25. If you only have a laptop on a consumer connection, testing through a VPN endpoint that permits SMTP, or from a small VPS, avoids chasing a phantom.

Common mistakes

• Fixing SPF to solve an inbound problem. Your SPF record has no role in receiving mail. If you can send but not receive, it is not SPF.
• Copying MX values from a tutorial. Regional deployments have different hostnames. Use your own Admin Console every time.
• Adding Zoho’s records without removing the old ones. A lower preference number beats Zoho outright and nothing warns you.
• Trusting the DNS panel over a query. A saved record and a published record are different things. Query it.
• Cutting MX over before creating the mailboxes. Every address that doesn’t exist yet bounces, and those messages are gone.
• Blaming propagation on day three. Propagation is bounded by the TTL that was in effect before the change. If it’s been longer than that, something is genuinely wrong.
• Trailing dot confusion. Some panels want mx.zoho.com. with the dot, others append the zone themselves and turn mx.zoho.com into an unresolvable name. Always confirm with a query afterwards.

Best practices

• Drop the TTL before you migrate. Lower the MX TTL to a few minutes a day ahead of cutover, do the change, then raise it back. This turns a rollback from an overnight wait into a coffee break.
• Create every mailbox, alias and group before touching MX. Zoho’s own guidance is to configure users first and change MX last.
• Set a catch-all during the transition. It converts “we lost an email” into “it’s in the catch-all mailbox”.
• Keep DNS in one place. One authoritative provider, one panel, no ambiguity about where records live.
• Monitor the MX record itself. An uptime or synthetic monitoring service that checks DNS answers, or a scheduled dig comparison in your own pipeline, catches an accidental zone edit before a client does.
• Enable DKIM and set DMARC after inbound is confirmed working. They matter for your outbound reputation. Doing them first just adds variables while you’re debugging.
• Keep a copy of the zone. Export it before major changes. Reconstructing a zone from memory during an outage is miserable.

Frequently asked questions

Why can I send from Zoho Mail but not receive?

Because sending authenticates directly against Zoho’s outbound servers and doesn’t consult your domain’s DNS, while receiving depends entirely on your MX records. Working outbound with broken inbound is a strong signal that the problem is an MX record, a nameserver delegation issue, or a leftover record from a previous provider.

How long should MX changes take to work?

Propagation is governed by the TTL that was set on the old record, not by any fixed schedule. If the previous TTL was one hour, resolvers holding a cached copy will refresh within an hour. If it was set to a day, expect a day. Nothing you do afterwards speeds up a cache that has already been populated.

Do I need all three Zoho MX records?

Mail will flow with only the primary, but the backups exist so that senders have somewhere to deliver if the primary is unreachable. Without them, sending servers queue and retry, which delays delivery and eventually bounces. Add the full set your Admin Console lists.

Does SPF affect whether I receive email?

Your own SPF record does not. It’s evaluated by servers receiving mail from you. The one indirect connection is that Zoho evaluates the sender’s SPF on incoming mail, and if your Admin Console is set to reject or quarantine on SPF failure, legitimate mail from badly configured senders can disappear.

Why do lookup tools say my MX records are fine when mail still fails?

Lookup tools verify that records exist and resolve. They can’t know which Zoho data center your organization lives in, whether the mailbox has been created, or whether a message is sitting in quarantine. A green result rules out one layer, not all of them.

Can I run Zoho Mail alongside another mail provider on one domain?

Not by simply listing both sets of MX records. That splits mail unpredictably. Zoho does offer routing arrangements designed for gradual migration, configured on the Zoho side rather than by stacking MX records in DNS. If you need a genuine split, use the supported mechanism.

My contact form emails vanish but normal email works. Why?

Almost always the control panel email routing setting on the server hosting the site. If it’s on local mail exchanger, mail generated on that machine is delivered into a local account rather than sent out to Zoho. Switch it to remote.

Conclusion

If you take one thing from this: when Zoho Mail is not receiving email but sending works, stop looking at authentication records. Inbound mail is decided by your MX records, and those records have to be published by the nameservers that are actually authoritative for your domain, pointing at the data center your Zoho organization lives in, with nothing else in the answer competing with them.

Query, don’t assume. Read the answer from the authoritative nameserver rather than the panel, compare it against your own Admin Console instead of a tutorial, then work down through SMTP and Zoho’s own quarantine. Almost every case resolves in that order, and the ones that don’t are usually a mailbox that was never created in the first place.

Need someone to untangle your mail DNS?

I work on DNS and mail delivery problems like this regularly, usually for people who have already tried three fixes and made things harder to reason about. Things I can help with:

• Diagnosing inbound mail failures end to end, from delegation through SMTP response codes to Zoho’s quarantine
• Planning and executing a mail migration to Zoho with a TTL schedule and a rollback path that actually works
• Auditing and cleaning up a zone that several people have edited over the years
• Setting up SPF, DKIM and DMARC properly once inbound is stable, including staged DMARC enforcement
• Fixing DNSSEC mismatches after a nameserver move without taking the domain down again
• Adding DNS and mail-flow monitoring so the next zone edit doesn’t go unnoticed for a week

Send me the output of dig +trace MX yourdomain.com and a rejection message from a sender, and I can usually tell you where it’s breaking before we’ve agreed on anything.

The post Zoho Mail Not Receiving Email? A DNS Troubleshooting Guide appeared first on John Nessime.

So you check the zone. There is an MX record. There is an SPF record. There is a DKIM key published under a selector. There is a DMARC record. You paste the domain into three free checkers and every one of them lights up green.

Everything is configured. The domain is still trivially spoofable.

This is the failure mode that makes business email DNS worth writing about. It is not that people forget to publish records. It is that publishing a record and enforcing a policy are different acts, the checkers reward the first one, and nothing anywhere in DNS will tell you that you stopped halfway.

What follows is what each of the four records actually does, what breaks when it is wrong, the domain architecture decision that stops the problem recurring, and an order of operations that gets you to enforcement without losing legitimate mail on the way.

The two jobs your business email DNS actually does

Almost every confused email ticket traces back to one misunderstanding: people treat these four records as a single feature called “email setup.” They are two unrelated systems that happen to share a zone file.

• Receiving mail. This is MX, and only MX. Nothing else in the set participates.
• Authorizing senders. This is SPF, DKIM and DMARC. None of them affect whether a single message reaches your mailbox.

The consequence is blunt. If inbound mail is not arriving, editing SPF cannot help and never will. If your domain is being spoofed, a perfect MX configuration contributes nothing. It is common to see an afternoon spent rewriting an SPF record for a problem that lived entirely in a mail routing rule.

A third job hides inside the second, and it is the one people skip. SPF and DKIM only produce evidence: this server was authorized, this content was signed by this domain. Neither tells a receiving server what to do when the evidence is missing. Only DMARC does, through its policy tag, and that tag is the single enforcement dial in the whole arrangement.

MX: the only record inbound delivery depends on

An MX record carries exactly two values: a preference number and a hostname. Lower preference numbers are tried first. Equal preference numbers let a sender spread load across the listed hosts, which is how most hosted mail providers publish theirs.

dig +short MX example.com

The hostname side has two constraints panels will happily let you violate. The target must be a name resolving to A or AAAA records, not an IP typed into the field, and it must not point at a CNAME. Some panels accept an IP and quietly invent a hostname behind the scenes, which works until you move providers and find the record you thought you published is not the one that exists.

If a domain has no MX record at all, the SMTP specification tells senders to fall back to its A or AAAA address. On a business domain that is your web server. The connection times out or is refused, and the sender queues and retries for days before anyone sees a bounce. The mail is not rejected; it is late, sometimes by a working week.

And subdomains do not inherit MX records from the parent. If example.com has MX records, mail.example.com does not. It falls back to its own A record, or to nothing.

Null MX for domains that should never receive mail

Most businesses own more domains than they use for mail: typo-squat defenses, old brand names, a marketing microsite, the domain from the company they acquired. RFC 7505 defines a way to say “this domain accepts no mail” explicitly, using a single MX record with preference 0 and a target of a lone dot.

example-parked.com.  3600  IN  MX  0  .

A conforming sender sees this and rejects immediately instead of falling back to the A record and retrying for days. The bigger benefit is backscatter: when someone forges a return address at a domain of yours, bounce messages get aimed at it. A null MX turns those into an instant rejection at the sender’s end.

One rule attached to this: a domain advertising a null MX must not publish any other MX records. It is the whole set or nothing.

One operational note: drop MX TTLs to a few minutes before a mail migration and raise them afterwards. A low TTL costs a little query volume. A high TTL during a cutover costs you mail delivered to a server you already decommissioned, with no error anywhere to tell you. Per-record TTL control and fast propagation matter here, which is why I would rather do a cutover on something like Cloudflare than a registrar’s default panel.

SPF: an authorization list with a hard budget

SPF is a TXT record at the domain apex that begins with v=spf1 and lists the systems allowed to send with your domain in the envelope sender. Publish two of them and you have published none: the result is a permanent error, which receivers treat as a failure.

dig +short TXT example.com

The constraint everyone eventually hits is the lookup budget. Evaluation is capped at ten DNS-querying mechanisms. The terms that count are include, a, mx, ptr, exists and redirect, and the count follows nested includes all the way down, so one vendor include: can carry four lookups inside it. Literal ip4 and ip6 ranges cost nothing, and neither does all.

Exceed ten and evaluation stops with a permanent error. It does not fail open. It does not keep counting and pass anyway.

There is a second, quieter limit: void lookups, meaning queries that return nothing. Implementations are told to cap those at two. This is the one that bites long after you stop paying attention, because the trigger is a vendor you cancelled whose include: target eventually stopped resolving. Your record did not change. Your mail started failing anyway.

Over budget, the honest options are to drop vendors you no longer use, replace lookup-heavy mechanisms with the literal IP ranges they resolve to, or move senders onto their own subdomains so each gets a fresh budget. Flattening services that resolve includes and keep the record updated do work, but understand the trade: you have taken on a dependency that must track your vendors’ IP changes, and cloud senders rotate ranges.

Why hard fail is not automatically the safer choice

SPF records end with a qualifier on all. Soft fail is ~all; hard fail is -all. The instinct is that hard fail is the stricter, more secure choice, and it is, but the DMARC specification calls out a specific cost that is easy to miss.

SPF is evaluated early in the SMTP conversation. A hard fail can get a message rejected before the message body is ever transmitted, which means before the From header is visible and before DMARC is evaluated at all. A message that would have passed DMARC on an aligned DKIM signature can be rejected purely on SPF.

Messages rejected that early never reach the DATA phase, so they never appear in your DMARC aggregate reports. You lose the failure and the evidence of the failure in the same move.

That is the argument for staying on ~all while you are still discovering who sends as you, and moving to -all once your reports have gone quiet. On a parked domain with no legitimate senders at all, publish v=spf1 -all immediately; there is nothing to discover.

One more thing SPF does not do, and this is the root of most DMARC confusion. SPF authenticates the envelope sender, the address in the SMTP MAIL FROM command. Your recipients never see that address. They see the From header, which SPF does not check at all.

DKIM: the signature that survives a forward

DKIM adds a cryptographic signature over selected headers and the message body. The public key lives in DNS under a selector, in the form selector._domainkey.example.com, and the signature header names both the selector and a signing domain in its d= tag.

dig +short TXT s1._domainkey.example.com

That d= value is the part that matters and the part that gets ignored. A message can carry a perfectly valid signature from your provider’s own domain. It verifies. It proves nothing about you, because the identity it asserts is theirs. Completing your provider’s domain authentication step, the one that has you publish records under your own zone, is what moves d= onto your domain.

Algorithms and key size

The rules here are settled. Signers must use rsa-sha256. The older rsa-sha1 must not be used for signing or verifying, and signatures using it fail permanently. Keys must be at least 1024 bits and should be at least 2048. Verifiers are required to reject anything under 1024 outright.

A useful field heuristic follows from a DNS quirk. A single TXT character string maxes out around 255 characters, and a 2048-bit RSA key does not fit in one. So if your DKIM record comes back from dig as one quoted string, it is probably 1024-bit; split into two concatenated strings, probably 2048. A hint rather than proof, but it takes two seconds.

An Ed25519 signing algorithm is also defined for DKIM, with compact keys and good cryptographic properties, but support across platforms and verifiers is still uneven. RSA with SHA-256 remains the safe universal choice unless you sign with both.

Rotating a key without breaking anything

Never edit a DKIM key in place. Mail already in flight, in a queue, or sitting in a mailing list’s outbound spool was signed with the old key, and overwriting the record invalidates all of it retroactively.

1. Publish the new key under a new selector name and confirm it resolves.
2. Switch the signing platform to the new selector.
3. Wait out the longest plausible delivery delay, which is days rather than hours if mailing lists are involved.
4. Remove the old selector record.

DKIM has one property SPF does not, and it decides your architecture later. A signature travels with the message. When mail passes through a forwarder, a role alias or a mailing list, the connecting IP is no longer yours and SPF fails; the DKIM signature usually still verifies. This is why the DMARC specification states that domains publishing a reject policy must not rely on SPF alone and must apply valid DKIM signatures.

DMARC: connecting the visible domain to the proof

DMARC is a TXT record at _dmarc.example.com. It asks one question that neither SPF nor DKIM asks: does the domain your recipient can actually see match the domain that proved itself?

dig +short TXT _dmarc.example.com

That match is called alignment. Relaxed alignment, the default, accepts any domain sharing the same organizational domain, so mail.example.com aligns with example.com. Strict requires them to be identical. A message passes DMARC if either SPF or DKIM passes and the domain that passed aligns with the From header. One aligned mechanism is enough. Both passing while neither aligns is a fail, and that is the most common cause of “but all my checkers are green.”

The tags worth knowing

• p is the policy for the domain itself: none, quarantine or reject. Omit it and the record is treated as p=none.
• sp sets a separate policy for existing subdomains.
• np sets a policy for subdomains that do not exist in DNS at all. This is the anti-spoofing tag most zones are missing.
• rua is where aggregate reports are sent. Without it you get no reports, and without reports you are guessing.
• adkim and aspf switch the two alignment modes from relaxed to strict.
• t=y is test mode. It tells receivers to apply one level below your stated policy, so a record saying reject behaves as quarantine, and quarantine behaves as none.

The DMARC specification has been rewritten and promoted onto the IETF standards track as RFC 9989, with aggregate and failure reporting split into RFC 9990 and RFC 9991, obsoleting the original RFC 7489. Existing records keep working and still begin with v=DMARC1, so nothing is urgent. Three things are worth acting on at your next zone edit.

The pct, rf and ri tags are gone. Unknown tags are ignored rather than treated as errors, so leaving them does no damage, but pct no longer means anything and the staged rollout it was used for is now t=y.

The Public Suffix List is no longer how receivers determine your organizational domain. They now walk up the DNS hierarchy looking for a DMARC record at each level, capped at eight queries. For a two-label domain this changes nothing. For a deep subdomain hierarchy it can resolve differently than the old method did, and a name deeper than eight labels will never have its policy record found by the walk. If you run a complex namespace, publish an explicit record at the exact name rather than relying on inheritance.

And if two DMARC TXT records are returned for the same name, both are discarded. A duplicate is not a merge or a tiebreak. It is the same as having none.

Reading the reports

Aggregate reports arrive as gzipped XML, typically once a day per reporting provider. They are technically human-readable and practically not, especially once a dozen providers are reporting on a domain with several sending services.

Two honest choices. Parse them yourself, which is a small satisfying project that gives you exactly the view you want. Or point rua at a hosted processor; Dmarcian, Valimail and PowerDMARC all do this competently, with entry tiers sufficient for one domain. The trade is that you are sending metadata about your mail flows to a third party and inheriting their retention terms. Read those terms first in a regulated environment.

Domain architecture: the decision that stops this recurring

Everything above is records. This part is structure, and it is what separates a zone that stays correct from one that quietly rots.

Put each sending stream on its own subdomain. People mail from the apex. Marketing sends from something like news.example.com. Transactional and application mail sends from mail.example.com or similar. Each subdomain gets its own SPF record, its own DKIM selectors, and its own DMARC record if you want a different policy there.

• Each subdomain gets a fresh ten-lookup SPF budget, which is usually what forced the decision in the first place.
• A marketing platform that gets breached or blocklisted does not drag your invoices and password resets down with it.
• Reputation is scoped. Bulk sending and one-to-one business mail get judged separately, which is what you want, because they behave nothing alike.
• You can hold the apex at a strict policy while a subdomain is still being brought into line.

The cost is more records to maintain and one more thing to explain to whoever inherits the zone. It is worth it the first time a vendor migration happens and you only have to touch one subdomain.

Then close the gaps. Every domain that never sends and never receives should carry a null MX, an SPF record of v=spf1 -all, and DMARC at p=reject. Three records, five minutes, and the domain leaves the pool of things abusable in your name. Add np=reject on live domains too, because an attacker does not need a subdomain to exist in order to put it in a From header.

Rolling it out without losing mail

The order matters, because each step depends on evidence produced by the one before it.

1. Inventory every sender. Mailbox provider, CRM, helpdesk, billing system, marketing platform, monitoring alerts, and the tool a department signed up for without telling anyone. This list is always longer than expected and it is the highest-value step here.
2. Fix MX first, with a low TTL if you are migrating. Inbound is what people notice within minutes.
3. Publish SPF within budget, ending in ~all for now. Count lookups before publishing, not after mail fails.
4. Get DKIM signing on your own domain for every stream. Verify d= in the headers of a real received message rather than trusting a dashboard.
5. Publish DMARC at p=none with a rua address. This changes nothing about delivery and starts the flow of evidence.
6. Read reports for several weeks. Longer if you have quarterly patterns like invoicing runs or annual renewals, which is exactly the mail you cannot afford to break.
7. Move to p=quarantine once every remaining failure is one you recognize as spoofing. Use t=y for a softer first step.
8. Move to p=reject, confirming DKIM is aligned on every stream first, then tighten SPF to -all.

Step six is the one people compress, and it is the only step that generates the information the last two depend on. Skipping it means going to enforcement blind and finding out which stream you broke from a colleague rather than from a report.

Steps one and six are also the two that never finish. Keep the sender inventory current as vendors come and go, and keep reading reports after you reach enforcement, because a new tool bought by a department you never talk to shows up in a report long before it shows up in a conversation.

Troubleshooting, in the order worth checking

When something is wrong, the first question is which of the two jobs failed. Inbound problems and spoofing problems share no diagnostic steps.

Inbound mail is not arriving

1. Confirm the MX records exist and resolve, and that each target has an A or AAAA record.
2. Query your authoritative nameservers directly rather than a resolver, so you are looking at what you published rather than what is cached.
3. Confirm the mail host actually answers on port 25 and offers STARTTLS.
4. If all three pass, the problem is inside the mail platform: routing rules, a filter, an aliasing mistake, a mailbox over quota. It is no longer DNS.

dig +short NS example.com
dig @ns1.example-dns.net example.com MX
openssl s_client -starttls smtp -connect mail.example.com:25

Legitimate mail is being rejected or quarantined

1. Read the SMTP rejection text. Receivers name the reason, and DMARC-related rejections usually say so in plain words.
2. Open the headers of a message that failed and read the authentication results. They tell you which check failed and which domain was evaluated.
3. Compare the d= value in the DKIM signature against the From domain. If they differ and share no organizational domain, alignment is your problem.
4. Count your SPF lookups. A permanent error there presents as a plain SPF failure with nothing in the record that looks wrong.
5. Check the sending IP has a valid reverse DNS record that resolves forward again. Only whoever controls the IP can set this, which means your provider if you are on shared infrastructure, or you if you run your own server.

dig -x 203.0.113.10 +short

That reverse DNS point matters more than it looks. Major mailbox providers expect sending IPs to have valid forward and reverse DNS, so if you run your own mail server, PTR control is a hard requirement rather than a nice-to-have. Confirm it before you buy. Hosts aimed at self-hosting, InterServer and Contabo among them, expose PTR in the panel; plenty of budget instances do not, and some block port 25 outright.

Common mistakes

• Treating p=none as done. It is a monitoring mode. It provides no protection whatsoever, and every checker will still show you a green tick.
• Publishing two SPF records. Usually one from the mailbox provider’s setup wizard and one from a marketing tool. The result is worse than either alone.
• Assuming a passing DKIM signature is your DKIM signature. Check d=, not the presence of a signature.
• Editing a DKIM key in place instead of rotating through a second selector.
• Leaving parked and brand domains bare. No MX, no SPF, no DMARC is an open invitation, and these domains are usually the ones nobody is monitoring.
• Going to p=reject without DKIM aligned on every stream. Forwarded mail will break, and forwarded mail is disproportionately mail from customers.
• Setting rua and never reading it. Reports you do not process are the same as reports you never requested.

Frequently asked questions

Do I need both SPF and DKIM, or is one enough?

DMARC only needs one of them to pass and align. Publish both anyway. They fail in different circumstances, and having only one means any situation that breaks it breaks all your authentication at once. Major mailbox providers also expect both from higher-volume senders, and DKIM specifically is required if you intend to publish a reject policy.

How long should I stay at p=none?

Long enough to see a full cycle of your sending patterns, plus time to fix what the reports reveal. For a small business with a mailbox provider and two SaaS tools, a few weeks. For an organization with quarterly billing runs and departments who buy their own software, months. The signal to move is that you recognize every remaining failure as illegitimate, not that a calendar reminder fired.

Will DMARC stop phishing?

It stops exact-domain spoofing, one technique among several. It does nothing about lookalike domains, nothing about display-name spoofing where the visible name says your CEO but the address is free webmail, and nothing about a compromised mailbox sending properly authenticated mail. One control worth having, not a phishing solution.

Does any of this affect whether I receive email?

No. SPF, DKIM and DMARC describe mail leaving your domain. Only MX affects mail arriving at it. The one indirect connection is that your own inbound filtering may evaluate other people’s SPF and DKIM when deciding what to do with their mail, but that is your mail platform’s behavior, not your DNS records.

Do I need to update my records for the new DMARC RFCs?

Nothing breaks if you do nothing. At your next edit, drop pct, rf and ri if they are present, consider adding np to close the non-existent subdomain gap, and if you run a deep subdomain hierarchy, publish explicit records rather than relying on inheritance. Leave the rest at defaults, because the defaults are sensible.

My mail goes to spam even though everything passes. What now?

Authentication and reputation are different problems. Passing DMARC tells a receiver the mail genuinely came from you; it says nothing about whether recipients want it. If authentication is clean, look at complaint rates, list hygiene, volume ramps and content. Google publishes a spam complaint ceiling and its guidance is to operate well below that ceiling, not near it.

Wrapping up

If you take one thing from this, take the distinction between publishing and enforcing. Business email DNS gives you four records that answer four different questions, and only one of them, the DMARC policy tag, actually instructs a receiving server to do anything. Every free checker will confirm the records exist. None of them will tell you the dial is at zero.

Get MX right so mail arrives. Keep SPF inside its lookup budget. Make DKIM sign with your own domain so d= aligns. Publish DMARC at p=none with a reporting address, read what comes back for as long as it takes, then move the dial until it reaches reject.

And while you are in the zone, spend five minutes on the domains nobody thinks about. A null MX, an empty SPF record and a reject policy on a parked domain is the cheapest security work available to you.

Need a second pair of eyes on your mail domain?

Mail DNS is unusually well suited to outside help, because the failure is almost always somewhere the domain owner cannot see it: in a header, in a report nobody parses, or in a vendor’s include chain. Things I regularly help with:

• Auditing an existing zone across MX, SPF, DKIM and DMARC and telling you plainly what is exposed and what is fine
• Getting an SPF record back under the ten-lookup limit without breaking a sender you forgot about
• Planning and executing the move from p=none to p=quarantine to p=reject, including the sender inventory and the report reading
• Setting up DMARC aggregate report collection and parsing, either self-hosted or on a processor
• Splitting sending streams onto subdomains and migrating each one without a delivery gap
• Locking down parked and brand-protection domains so they stop being usable in your name

If you would rather not describe the problem in the abstract, send me the output of a dig against your domain, or a set of headers from a message that failed, and I will tell you what I see in it.

The post Business Email DNS Done Right: MX, SPF, DKIM and DMARC appeared first on John Nessime.

It usually is. Not because DNS is fragile, but because it’s the one layer where caching, delegation, and propagation all conspire to make the same domain behave differently depending on who’s asking and when. A record can be perfectly correct in your control panel and still resolve to the wrong IP for half the internet.

This article is the DNS troubleshooting workflow I actually use — the order of checks, the commands worth memorising, how to read what they tell you, and the specific failure patterns that show up over and over. No theory dumps. Just the path from “something’s broken” to “here’s exactly which record on which server is wrong.”

First, Get the Mental Model Right

You can’t debug a system you don’t have a picture of. When a browser resolves example.com, several independent parties are involved, and any one of them can be the liar:

1. The application — browsers keep their own short-lived DNS cache, and HSTS or connection pooling can mask changes entirely.
2. The operating system — the local stub resolver, /etc/hosts, nscd, systemd-resolved, or the Windows DNS Client service.
3. The recursive resolver — your router, your ISP, or a public resolver like 1.1.1.1 or 8.8.8.8. This is where most stale answers live.
4. The delegation chain — root servers, then the TLD servers, then whichever name servers your registrar says are authoritative.
5. The authoritative name server — the only place where the truth actually lives.

Effective DNS troubleshooting is just working down that list and asking each party the same question directly, instead of trusting whatever the browser tells you. The moment you find two parties giving different answers, you’ve found your boundary — and the problem is between them.

The Tools That Matter

You need surprisingly few. My honest ranking:

dig — the one you should learn properly

dig is the only tool that shows you everything: the query it sent, the response status, the TTL remaining, the authority section, and whether the answer came from a cache or from the source. On Debian and Ubuntu it lives in dnsutils; on RHEL-family systems it’s in bind-utils.

# Just the answer, nothing else
dig +short example.com A

# The full picture — status, flags, TTL, authority
dig example.com A

# Ask one specific resolver instead of the system default
dig @1.1.1.1 example.com A

# Ask a specific authoritative server directly
dig @ns1.example-dns.com example.com A

host — for quick sanity checks

host example.com
host -t MX example.com
host -t TXT example.com

nslookup — fine, but know its limits

nslookup is everywhere, including Windows, which is its main virtue. But it hides details you often need, and its “Non-authoritative answer” banner confuses people constantly — it simply means the answer came from a cache rather than the authoritative server. That’s completely normal. On Windows I reach for PowerShell instead:

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Server 1.1.1.1

resolvectl — essential on modern Linux

If the machine runs systemd-resolved, your /etc/resolv.conf probably points at 127.0.0.53, which tells you nothing about the real upstream servers. resolvectl does:

resolvectl status
resolvectl query example.com
resolvectl statistics

getent — the reality check

dig talks to DNS. Your applications talk to the C library resolver, which also consults /etc/hosts and whatever else /etc/nsswitch.conf lists. When dig and the application disagree, this is the command that explains why:

getent hosts example.com
getent ahosts example.com

A Repeatable DNS Troubleshooting Workflow

This is the sequence. Don’t skip ahead — each step eliminates a whole class of causes, and jumping straight to the authoritative server is how you spend an hour fixing something that was never broken.

Step 1 — Confirm it’s actually DNS

Resolve the name, then connect to the resulting IP directly. If the IP works and the name doesn’t, it’s DNS. If neither works, you’re troubleshooting the wrong layer.

dig +short example.com A
curl -I --resolve example.com:443:203.0.113.10 https://example.com/

The --resolve flag is underrated. It forces curl to use an IP you specify while still sending the correct Host header and SNI, which lets you test the web server as if DNS were already fixed. Replace 203.0.113.10 with the IP you expect.

Step 2 — Compare local vs public resolvers

dig +short example.com A
dig +short @1.1.1.1 example.com A
dig +short @8.8.8.8 example.com A
dig +short @9.9.9.9 example.com A

If your local answer differs from all three public resolvers, the problem is on your side — a cache, a hosts file entry, a VPN pushing internal DNS, or a router doing something creative. If all four agree but the answer is wrong, the problem is upstream at the authoritative layer.

Step 3 — Find out who is actually authoritative

This is the step people skip, and it’s the one that catches the nastiest problems. The name servers listed in your DNS provider’s dashboard are not necessarily the ones the internet is using.

# What the parent zone (the registry) says
dig +short NS example.com

# What the zone itself says, straight from one of those servers
dig @ns1.example-dns.com example.com NS

Those two lists should match. When they don’t, you’ve usually found a half-finished DNS migration: the registrar still delegates to the old provider, so the world keeps reading a zone nobody has updated in months.

Step 4 — Query every authoritative server individually

A zone with four name servers can be inconsistent across them if a zone transfer failed. Intermittent, “it works every third time” problems are almost always this. Compare the SOA serial on each:

# Pull the SOA record from every authoritative server in one shot
dig +nssearch example.com

# Or check them one by one
dig +short @ns1.example-dns.com example.com SOA
dig +short @ns2.example-dns.com example.com SOA

Different serial numbers mean the secondaries haven’t caught up with the primary. Different answers for the same record mean something is genuinely broken in replication.

Step 5 — Walk the delegation chain

When nothing else explains it, follow the query the way a recursive resolver would — from the root, down through the TLD, to the authoritative servers:

dig +trace example.com A

Read it top to bottom. Each block is one hop. The point where the output stops making sense — a referral to servers that don’t answer, a missing glue record, an unexpected NXDOMAIN — is your break point. This single command has saved me more time than any other in DNS troubleshooting.

Reading dig Output Without Guessing

The status line in a dig response tells you the category of failure immediately. Learn these four and you’ve eliminated most of the guesswork.

• NOERROR — the query succeeded. Note that NOERROR with an empty answer section is not a failure: it means the name exists but has no record of the type you asked for. Asking for an A record on a name that only has MX records gives you exactly this.
• NXDOMAIN — the name does not exist at all. Not a typo in the record; the label itself isn’t in the zone. Check for a missing record, a misspelled hostname, or a zone that isn’t loaded.
• SERVFAIL — the resolver tried and failed. This is the ambiguous one, and in practice it usually means DNSSEC validation failure, an authoritative server that’s unreachable or refusing queries, or a broken delegation.
• REFUSED — the server you asked is not willing to answer for that zone. Typically you’re querying a server that isn’t authoritative and doesn’t do recursion for you.

Two other things worth reading in every response:

• The aa flag — present when the answer came from an authoritative server. If it’s missing, you’re looking at a cached answer, and the TTL tells you how stale it might be.
• The TTL column — on a cached answer this counts down. Query the same resolver twice a few seconds apart; if the TTL drops, you’re being served from cache. If it stays constant, you’re hitting the source.

The Propagation Myth (and What’s Really Happening)

“DNS propagation takes 24 to 48 hours” is the most repeated and least accurate sentence in web hosting. Nothing propagates. When you change a record, the authoritative server has the new value instantly. What takes time is the expiry of cached copies held by thousands of independent resolvers — and that duration is entirely determined by the TTL you set before the change.

The practical consequence: lowering a TTL after you’ve made the change does nothing for anyone who already cached the old value. Plan ahead instead.

1. Well before a migration, drop the TTL on the records you’ll change to something short — 300 seconds is a common choice.
2. Wait at least the length of the old TTL so the short value fully replaces it in caches.
3. Make the actual change. Old cached answers now expire within minutes.
4. Verify against several public resolvers and from a couple of different networks.
5. Once everything is stable, raise the TTL back to something sane — an hour or more — so you’re not paying for lookups you don’t need.

The TTL you set today determines how painful next month’s migration will be. It’s the cheapest piece of planning in infrastructure work, and the one most consistently skipped.

One more thing people miss: negative caching. When a lookup returns NXDOMAIN, resolvers cache that “doesn’t exist” answer too, for a duration derived from the minimum field in the zone’s SOA record. So if you query a hostname before creating it, you may keep getting NXDOMAIN for a while even after the record is live. Check what you’re in for:

dig +short example.com SOA

The last number in that output is the negative caching TTL. Resist the urge to test a hostname before you’ve actually created it.

Failure Patterns You’ll Meet Again and Again

A CNAME on the zone apex

You cannot put a plain CNAME on the root of a domain. The apex must carry SOA and NS records, and a CNAME is not allowed to coexist with other records at the same name. Providers work around this with ALIAS, ANAME, or “CNAME flattening” records that resolve the target server-side and return an A record. If your root domain misbehaves while www is fine, this is the first thing to check.

Stale cache — everywhere at once

Correct at the authoritative server, wrong on your machine. Clear caches from the outside in:

# Linux with systemd-resolved
sudo resolvectl flush-caches

# Linux with nscd
sudo systemctl restart nscd

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Windows (run as Administrator)
ipconfig /flushdns

Then remember the browser. Chromium-based browsers keep a separate cache you can clear at chrome://net-internals/#dns. And if the site uses HSTS, a browser may refuse to fall back to HTTP regardless of what DNS says — test with curl before you conclude anything from a browser.

A forgotten line in /etc/hosts

Someone adds a hosts entry during a migration to test the new server, and never removes it. Six months later the server is “randomly” hitting the wrong backend. It costs three seconds to rule out:

grep -i example.com /etc/hosts
getent hosts example.com

DNSSEC validation failures

A domain with broken DNSSEC returns SERVFAIL from validating resolvers while working perfectly on non-validating ones. That produces the maddening symptom where the site loads for some users and not others, with no geographic pattern.

The diagnostic trick is +cd, which disables validation. If the query fails normally but succeeds with +cd, DNSSEC is your culprit:

dig @1.1.1.1 example.com A
dig @1.1.1.1 +cd example.com A

# Show the DNSSEC records themselves
dig example.com DNSKEY +dnssec
dig example.com DS

# delv performs validation and explains the outcome
delv example.com A

The usual cause is a DS record at the registrar that no longer matches the keys published in the zone — classic after changing DNS providers without disabling DNSSEC first. Always turn DNSSEC off at the registrar before migrating name servers, then re-enable it once the new provider is live and stable.

Split-horizon DNS surprises

Internal resolvers hand out private addresses; external resolvers hand out public ones. Perfectly intentional — until a VPN, a container, or a misconfigured search domain puts a client on the wrong side of the split. When a name resolves differently depending on where you run the query, compare the local resolver against a public one and check whether a VPN profile is pushing its own DNS servers.

Proxied records hiding the origin

If a domain sits behind Cloudflare or a similar proxy, public DNS returns the proxy’s IP, not your server’s. That’s the whole point — but it means you cannot verify an origin change through public DNS at all. Query the authoritative provider’s own API or dashboard for the real record value, and test the origin directly with curl --resolve.

Wildcards masking a missing record

A * record in the zone means every hostname resolves — including the ones you typo’d, and including subdomains you thought you’d deleted. If everything resolves but half of it points somewhere unexpected, check for a wildcard before you go hunting for phantom records.

Missing trailing dots in zone files

Hand-editing BIND zone files? A record value without a trailing dot gets the origin appended to it. Write mail.example.com instead of mail.example.com. and you’ve just created mail.example.com.example.com. Validate before reloading:

named-checkconf
named-checkzone example.com /var/named/example.com.zone

And bump the SOA serial. A zone edit without a serial increment won’t reach the secondaries, which is exactly the inconsistency you were chasing in Step 4.

Containers and the ndots trap

Inside Kubernetes pods, /etc/resolv.conf commonly sets ndots:5. Any name with fewer than five dots gets tried against every search domain first, so an external lookup like api.example.com can generate several failed queries before the correct one. It works — it’s just slow, and under load it looks like intermittent DNS failure. Adding a trailing dot to fully qualify the name skips the search list entirely:

cat /etc/resolv.conf
dig api.example.com.        # note the trailing dot

DNS Troubleshooting for Email Delivery

Mail problems are DNS problems more often than they are mail-server problems. When messages bounce or land in spam, check these before touching the mail server config:

# Where should mail for this domain go?
dig +short example.com MX

# SPF and DMARC live in TXT records
dig +short example.com TXT
dig +short _dmarc.example.com TXT

# DKIM lives under a selector you choose
dig +short selector1._domainkey.example.com TXT

# Reverse DNS for the sending IP
dig -x 203.0.113.10 +short

Things that regularly go wrong here:

• Two SPF records. A domain must publish exactly one. Two SPF TXT records is a permanent error, and receiving servers are entitled to fail the check outright. Merge them into one.
• An MX pointing at a CNAME. MX targets must resolve to address records, not aliases.
• Missing reverse DNS. If the PTR record for your sending IP doesn’t match the hostname the server announces, expect a lot of spam folder.
• DKIM selector mismatch. The selector in the message header must match the one published in DNS — a detail that quietly breaks after a mail platform migration.

While you’re in TXT territory: if certificate issuance is failing, check for a CAA record. A CAA entry that only authorises one certificate authority will silently block every other one, and the error you get back from the ACME client rarely says “DNS.”

dig +short example.com CAA

Mistakes That Cost the Most Time

• Testing only in a browser. Browser caches, HSTS, service workers, and QUIC connection reuse will all lie to you. Confirm with dig and curl.
• Trusting the control panel. The dashboard shows what the zone should contain. Only a query against the authoritative server shows what it actually serves.
• Changing several things at once. Adjust one record, verify, then move on. Batch changes turn a five-minute fix into an archaeology project.
• Forgetting IPv6. A stale or wrong AAAA record produces “works for some people” behaviour, because dual-stack clients generally prefer IPv6. Always check dig +short example.com AAAA.
• Leaving DNSSEC enabled through a provider migration. The single most reliable way to take a domain fully offline for hours.
• Not documenting the zone before a migration. Export or record every record first. Rebuilding a zone from memory at 2am is not a plan.

Best Practices That Prevent the Next Incident

• Use at least two name servers, ideally on separate networks or providers. Single-provider DNS is a single point of failure for your entire presence.
• Keep TTLs deliberate. Long TTLs for stable infrastructure, short ones ahead of planned changes. Not the other way round.
• Monitor DNS resolution itself, not just HTTP endpoints. A check that queries your authoritative servers directly and alerts on a changed or missing answer catches problems before users do.
• Version-control your zone data if your provider supports API or zone-file export. Diffing two zone versions turns “what changed?” into a one-second question.
• Keep a record inventory — what each record is for, who owns it, and whether it’s still needed. Old A records pointing at decommissioned servers are a genuine security risk, not just clutter.
• Standardise your checks. A short script that runs your Step 1–5 sequence against a domain makes DNS troubleshooting repeatable instead of improvised.

A Quick Reference You Can Keep

# Basic resolution
dig +short example.com A
dig +short example.com AAAA

# Compare resolvers
dig +short @1.1.1.1 example.com A
dig +short @8.8.8.8 example.com A

# Authority and delegation
dig +short example.com NS
dig +trace example.com A
dig +nssearch example.com

# Cache behaviour
dig example.com A            # watch the TTL count down
dig +norecurse @1.1.1.1 example.com A   # cached-only lookup

# DNSSEC
dig +cd example.com A
delv example.com A

# Mail and verification records
dig +short example.com MX
dig +short example.com TXT
dig +short _dmarc.example.com TXT
dig -x 203.0.113.10 +short

# System-level view
resolvectl status
getent hosts example.com
cat /etc/resolv.conf

Frequently Asked Questions

How long does a DNS change really take to take effect?

At the authoritative server, immediately. For everyone else, up to the TTL that was in place when they last cached the record. If the old TTL was 3600 seconds, worst case is roughly an hour. The “24 to 48 hours” figure is a legacy of very long default TTLs and badly behaved resolvers, not a rule.

What’s the difference between SERVFAIL and NXDOMAIN?

NXDOMAIN is a definitive answer: the name doesn’t exist. SERVFAIL means the resolver couldn’t produce an answer at all — commonly a DNSSEC validation failure, an unreachable authoritative server, or a broken delegation. NXDOMAIN points you at the zone contents; SERVFAIL points you at the infrastructure.

Why does the site work for me but not for a colleague?

Different resolvers with different cache states, a hosts file entry on one machine, a VPN pushing internal DNS, an IPv6 versus IPv4 difference, or DNSSEC failing only on validating resolvers. Have both people run the same dig against the same public resolver — if the answers match, the difference is local to one machine.

Should I use dig or nslookup?

dig, whenever it’s available. It shows response status, flags, TTLs and the authority section, all of which you need for real DNS troubleshooting. Use nslookup or Resolve-DnsName when you’re on a Windows box without other tooling.

Do online “DNS propagation checker” sites actually help?

They’re useful for one thing: seeing what different resolvers around the world currently have cached. They won’t tell you why an answer is wrong, and they can’t see proxied origins or internal split-horizon zones. Treat them as a rough sanity check, not a diagnosis.

Can a CNAME point to another CNAME?

Technically yes, and resolvers will follow the chain — but every extra hop adds latency and another thing to break. Keep chains short, and never let one loop back on itself. Also remember a CNAME cannot coexist with other records at the same name, which is why it doesn’t belong on a zone apex.

Why do my DNS changes keep reverting?

Usually because something else owns the zone: an infrastructure-as-code pipeline, a control panel that rewrites records on certain actions, or an external DNS controller in a Kubernetes cluster. Decide on one source of truth and make every change through it.

Is switching to a public resolver a fix?

It’s a workaround for one user, not a fix for the domain. It’s genuinely useful as a diagnostic — if 1.1.1.1 gives the right answer and your ISP’s resolver doesn’t, you’ve isolated the problem to that resolver’s cache. But if the record itself is wrong, changing resolvers just changes who tells you the wrong thing.

Wrapping Up

Good DNS troubleshooting isn’t about knowing obscure record types. It’s about discipline: confirm it’s DNS, compare resolvers, find out who’s really authoritative, ask each of them directly, and follow the delegation chain when the answers stop agreeing. Five steps, in order, every time.

Do that consistently and most incidents collapse into something small and obvious — a stale cache, a TTL nobody lowered, a DS record left behind after a migration, a hosts entry from six months ago. The problems aren’t usually exotic. They’re just invisible until you ask the right party the right question.

Keep the quick-reference commands somewhere you can reach in thirty seconds, set your TTLs before you need them, and monitor resolution as seriously as you monitor uptime. Future you will appreciate it at 2am.

Need a Hand With DNS, Hosting or Cloud Infrastructure?

If you’re stuck on a DNS issue, planning a migration you’d rather not do twice, or you just want someone to review a zone before you flip the switch, I’m available for freelance work.

I work on DNS configuration and troubleshooting, domain and hosting migrations, SSL and certificate issues, email deliverability records (SPF, DKIM, DMARC), server setup and hardening, AWS and cloud infrastructure, and monitoring and alerting — plus WordPress performance and maintenance.

You can see my profile, past work and reviews on Upwork, and message me directly there with what you’re dealing with.

Got a DNS problem this article didn’t cover? Leave a comment describing the symptoms and what dig +trace shows — that output alone usually narrows it down fast.

The post DNS Troubleshooting: How to Find the Real Cause in Minutes, Not Hours appeared first on John Nessime.