Support Library

Why is email not being delivered? (DNS perspective)

Troubleshoot email delivery from the DNS side: MX routing, MTA-STS and DANE, SPF, DKIM selectors from real headers, DMARC alignment and reverse DNS.

Author
CategoryDNS Troubleshooting Playbooks
Length4 minute read
UpdatedOctober 24, 2026

The short answer

When mail to or from a domain fails, DNS is involved at three points: senders find your mail servers through MX records, receivers check your sending servers' reverse DNS, and receivers check SPF, DKIM and DMARC records before accepting mail. Start with the bounce message, which usually names the step that failed, then check the matching records below.

Read the bounce first

A code such as 550 5.7.26 or text mentioning DMARC, SPF or "unauthenticated" points at authentication. "Host not found" or "no MX" points at routing. TLS or certificate errors point at MTA-STS or DANE.

Mail to your domain is not arriving

CheckCommandHealthy result
MX recordsdig +short MX example.comOne or more hosts with priorities, all of them yours or your provider's
MX host addressesdig +short A mx1.example.comAn address. An MX target must be a host name with A or AAAA records, not a CNAME and not an IP address.
Null MXThe MX answer is 0 .Only on domains that deliberately accept no mail (RFC 7505)
MTA-STS policydig +short TXT _mta-sts.example.comIf present, the policy file lists every current MX host; see MTA-STS and TLS-RPT
DANEdig +short TLSA _25._tcp.mx1.example.comIf present, it matches the certificate the MX host presents

With no MX record at all, senders fall back to the domain's own A or AAAA address, which usually is not a mail server. A recently changed MX may also still be cached by senders until its TTL runs out.

Mail from your domain is rejected or sent to spam

CheckCommandHealthy result
SPFdig +short TXT example.comOne v=spf1 record that includes every service sending as you
DKIMdig +short TXT s1._domainkey.example.comA v=DKIM1 key, at the selector named in your messages
DMARCdig +short TXT _dmarc.example.comOne v=DMARC1 record
Reverse DNS of the sending IPdig +short -x 192.0.2.25A host name that resolves back to the same address

Do not guess the DKIM selector. Open a message that was sent, find its DKIM-Signature header, and read two tags: d= is the signing domain and s= is the selector. The key is at s._domainkey.d. Common names such as selector1 only apply to some providers, and NXDOMAIN for a selector you do not use is expected.

A key in DNS does not prove that mail passes. The message's Authentication-Results header shows what the receiver actually concluded, including whether SPF or DKIM aligned with the From domain, which is what DMARC requires. DKIM vouches for the signing domain and the parts of the message it signed; it does not by itself prove the visible author, and it fails if a forwarder changes signed content. SPF/DMARC Misconfigurations lists the usual record mistakes.

Large senders' requirements

Gmail and Yahoo require bulk senders to have SPF and DKIM, a DMARC record, aligned From domains, and valid forward and reverse DNS for sending addresses, and Microsoft has announced similar rules for Outlook.com. If only mail to one of these providers fails, compare your setup with its published sender guidelines.

How DNS Panopticon helps

Domain Visualizer checks the routing and policy records: MX records and their addresses, null MX, SPF, DMARC, MTA-STS and TLS-RPT records, BIMI, DANE TLSA records for each MX host, and DKIM at the two selectors selector1 and selector2. A missing DKIM key at those two selectors is reported as informational only, for the reason above. Visualizer reads DNS; it does not send or receive mail, check reverse DNS of your sending servers, or read message headers, so the message-based checks above are still needed.

Sources and further reading