What a DNS check can and cannot tell you about email deliverability

Gmail and Yahoo require authenticated mail. A DNS check confirms part of that and cannot see the rest. What each record proves, why DKIM is hard to verify, and the order to fix things in before any outbound starts.

On this page7

Short answer

DNS shows whether a domain publishes what Gmail and Yahoo look for: an SPF record, a DMARC policy and mail servers. It cannot confirm DKIM without the selector from a real message, and it cannot see alignment, unsubscribe headers, sending IPs, volume or spam complaints. Fix the records first, then watch the sending itself.

What do Gmail's sender requirements ask for?

#

Since February 1, 2024, Gmail has required everyone who sends to Gmail accounts to authenticate with SPF or DKIM and to keep the spam rate reported in Google Postmaster Tools below 0.3%, among other technical requirements.

Senders of more than 5,000 messages a day to Gmail accounts must also publish SPF, DKIM and a DMARC record (a policy of none is enough), make sure the From domain aligns with the SPF or DKIM domain, and support one-click unsubscribe on marketing and subscribed messages. Yahoo published similar requirements for bulk senders.

What can a DNS check confirm?

#
  • SPF: whether the domain publishes exactly one SPF record, and whether it stays within the 10 DNS lookups the SPF standard (RFC 7208) allows. Two SPF records, or an eleventh lookup, make SPF fail with a permanent error.
  • DMARC: whether a record exists at _dmarc on the domain, which policy it sets, and where aggregate reports are sent.
  • Mail servers: which MX records the domain publishes, or whether it publishes a null MX (RFC 7505), which states that the domain accepts no mail at all.

Why can't a DNS check confirm DKIM?

#

A DKIM public key is published at a name that includes a selector, and whoever signs the mail chooses the selector. It travels in the DKIM-Signature header of each message (RFC 6376). Without a real message, a checker can only try the selectors that common sending tools use. If none of them answer, the accurate result is that DKIM could not be verified, not that the domain sends unsigned mail.

Does a domain without an MX record reject email?

#

No. Under RFC 5321, when a domain has no MX record, sending servers fall back to its A or AAAA record and deliver there. A missing MX record is untidy. A null MX, a single MX record with priority 0 pointing at ".", is the explicit statement that the domain receives no mail.

What can't a DNS check see?

#

Anything that depends on the message or the sending history: whether a particular message passed DMARC alignment, whether it carried the List-Unsubscribe and List-Unsubscribe-Post headers, which IP it left from and that IP's reputation, how many messages went out, and how many recipients marked them as spam. Those need the message headers, your sending tool's logs and Postmaster Tools. A score that claims to predict inbox placement from DNS alone is a guess.

In what order should you fix email authentication?

#
  1. Publish one SPF record that includes every service that sends as your domain.
  2. Publish DMARC with a policy of none and a reporting address, then read the reports for two weeks to find senders you forgot.
  3. Turn on DKIM signing in every sending tool, and confirm it by sending yourself a message and reading the headers.
  4. Register the domain in Google Postmaster Tools and watch the spam rate before you raise volume.

When I ran orme.co through our own checker on the night we launched it, the domain scored 34 out of 100, with no SPF record and no DMARC. Both are published now. It is an easy thing to miss on a new domain, and much cheaper to fix before the first outbound email than after it.

All posts

Bring the problem. We will scope the work on the call.

The first call is a real working conversation, not a pitch.