Email DNS Records and the Receiver's Decision Chain

What the receiver learns, and when it learns it

A receiving mail server checks the connecting address first, then the reverse DNS name it maps to, then the greeting name the sender announces, then SPF against the envelope sender, then any DKIM signature, and last DMARC alignment against the From line the recipient sees. Each step becomes possible only when the conversation reaches the stage that supplies its input, so the sequence is fixed by the protocol rather than chosen.

RFC 5321 gives the spine. The transaction starts with a MAIL command that gives the sender identification, a series of one or more RCPT commands follows, and then a DATA command initiates transfer of the mail data. Three facts arrive before any of that: the connecting address, free with the TCP session; its reverse name, one query; the greeting name, volunteered.

How the sender found this host is an earlier lookup, covered by the MX record guide, which is also where a null MX belongs.

The greeting is a claim, not a credential

Nothing corroborates the EHLO name when it is given: a false one costs what a true one costs. RFC 5321 puts the obligation on the sender: the name given in the EHLO command must be either a primary host name, one that resolves to an address record, or, where the host has none, an address literal. That binds the client, and what a receiver does about a bad one is local policy.

Local policy sits well above that floor. M3AAWG's Sender Best Common Practices, version 4.0 of August 2026, holds that the HELO must be a resolvable hostname and that a bracketed address literal is not acceptable — the very fallback RFC 5321 allows — and that on a dedicated address it must exactly match the primary forward name. That distance is where most deliverability trouble lives.

The reverse lookup, and the round trip that gives it meaning

The check on the connecting address is a round trip, not one query. RFC 8601 registers it as the iprev method and states it as set membership: if the client peer's IP address is I, the list of names to which I maps after a PTR query is the set N, and the union of IP addresses to which each member of N maps after corresponding A and AAAA queries is L, then this test is successful if I is an element of L.

The outcome vocabulary repays attention. A fail means the round trip completed and the halves disagreed; no PTR record at all is a permerror, because the evaluation could not be completed when no PTR data are published for the connecting address. Collapsing both into “reverse DNS failed” hides what an owner needs: whether to create an entry or repair one.

RFC 8601 is candid about its limits, recording some contention regarding the wisdom and reliability of this test, declining to specify how a verifier should perform it, and judging its value as an authentication mechanism limited. No standards-track text weights the outcome; weighting is receiver policy.

The requirement is real anyway, because the receivers impose it: Google tells senders to ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records; Yahoo asks for valid, meaningful, non-generic entries, judging the name as well as the round trip; and M3AAWG requires one reverse name per address, matching the forward name exactly.

SPF answers a question about the envelope

SPF is the first test with a published policy behind it, and it asks about an identity the recipient never sees. RFC 7208 requires verifiers to check the MAIL FROM identity where a HELO check has not reached a definitive result, and recommends checking HELO too. Neither is the From line a mail client displays.

The advice on acting is restrained. A neutral result must be treated exactly like none, the distinction existing only for information. On a softfail, receiving software should not reject based solely on that result, but may subject the message to closer scrutiny than normal. A hard fail is local policy.

The ten-term lookup ceiling fails in a way worth knowing. Exceeding it produces a permerror, not a fail: the receiver has not decided the sender is unauthorized, only that the policy could not be interpreted, so a DMARC evaluation resting on SPF loses that leg. Syntax belongs to the TXT record guide; the point here is that one more include from another vendor can quietly end a domain's ability to pass.

DKIM, and the one lookup a receiver cannot predict

A verifier cannot fetch a DKIM key until it has read the header, and that, rather than the body's size, is why DKIM sits later than SPF. The selector is chosen by the signer and travels inside the signature, in its s= tag; paired with d= it composes the name to query, under the _domainkey subdomain the TXT record guide describes.

A broken signature also means less than most advice implies. RFC 5585, the IETF's service overview of DKIM, says a verifier is to treat messages with signatures that fail as if they were unsigned, and that by itself a valid signature neither lowers nor raises the level of trust associated with the message. What signing supplies is an organization taking responsibility for transmitting a message, in a way a recipient can verify.

DMARC is the step that looks at the visible address

DMARC authenticates nothing itself. It reads what SPF and DKIM concluded and asks whether the identity either of them authenticated belongs to the same domain as the From line the recipient reads, a field chosen as the anchor because it is present in every compliant message.

Alignment has two strengths: domains are in relaxed alignment if they share an organizational domain, and in strict alignment if and only if they are identical. The rule combining the mechanisms is an or, not an and, so if one or more of the authenticated identifiers align with the author domain the message passes. One aligned pass suffices, which keeps forwarded mail alive, since forwarding breaks the SPF path but leaves an untouched signature verifiable. Large receivers can ask more than that, but the extra is their policy, not the standard's.

What changed in the DMARC specification in May 2026

Most guidance on the web describes a superseded document. RFC 9989, dated 19 May 2026, is the current specification, an Internet Standards Track document obsoleting RFC 7489 and RFC 9091. RFC 7489, from March 2015, was Informational and arrived on the Independent Submission stream, so the familiar line that DMARC has been an internet standard since 2015 became true only this year. The IANA Email Authentication Methods registry now cites RFC 9989.

Three changes matter in practice. Rather than just using a Public Suffix List to identify an organizational domain, the update defines a discovery technique known colloquially as the DNS Tree Walk, which asks DNS itself while working up the name, bounded at eight queries. The pct tag is gone, so rollout advice built on percentages runs against the current text. And a valid policy with no p tag is now read as p=none, making the permissive default explicit rather than discarding the policy.

Aggregate reporting moved to RFC 9990 and failure reporting to RFC 9991 the same day, so the format most tooling consumes sits outside the core document.

Where SRV records fit, and where they do not

Nothing in the sequence above reads an SRV record. The SRV records defined by RFC 6186 serve a different actor entirely: they let a user's mail client work out which server to talk to from the email address alone. The labels pair a service with a transport:

• _submission._tcp, where a client hands outbound mail in
• _imap._tcp, _imaps._tcp, _pop3._tcp and _pop3s._tcp, for access with negotiated or immediate TLS
• _submissions._tcp, added by RFC 8314 for implicit TLS, one letter from the label above

RFC 6186 draws the boundary itself: RFC 5321 specifies how to use MX resource records to locate SMTP services for a domain, it notes, but mail clients use the submission protocol, which does not use MX records. The fields themselves — target, port, priority and weight — are the subject of the SRV record page rather than this one. A Microsoft 365 tenant shows the split: inbound traffic runs on an MX and a TXT holding SPF, while the client-facing entries are a CNAME for Autodiscover and one SRV, for Teams federation rather than mail.