DNS for email

When you send a message to ana@example.com, your mail server only cares about the part after the at sign. It asks DNS for the MX records (mail exchanger) of example.com. Each MX record holds two things: a preference, a plain number, and the name of a host that accepts mail for the domain. The sender sorts the answers by preference, lowest first, and works down the list until a server takes the message.

The numbers are only compared with each other. Preferences 10 and 20 behave exactly like 1 and 2, or 100 and 2000; the gaps just leave room to slot a server in between later without renumbering. When two records share a preference, RFC 5321 says the sender must pick between them at random, which spreads load across a pool of equal servers for free.

An MX record names a host, not an address. The sender then looks up that host's A or AAAA records to get something it can connect to. That second step is where two classic mistakes live. An MX target must be a name that has its own address records: pointing MX at a CNAME falls outside the mail standard, and putting an IP address in the MX field does not work at all, because the field is a domain name. Both errors tend to work with one sender's software and fail with another's, which makes them miserable to diagnose.

Two edge cases matter as much as the normal one. If a domain has no MX records at all but the name exists, RFC 5321 §5.1 tells the sender to treat the domain's own A or AAAA record as an implicit MX with preference 0. That rule dates from before MX existed, and it means a domain with only a web server address can still receive mail attempts, whether anyone is listening on port 25 or not.

That is why RFC 7505 added the null MX: a single record, MX 0 ., whose target is the root itself. It says, in a way no sender can misread, that this domain accepts no mail. A sender that sees it should fail the message at once (RFC 7505 suggests reply code 556) instead of queuing it for days. And if the domain does not exist at all (an NXDOMAIN answer), the sender must report an error straight away; there is nothing to retry.

To understand mail authentication you have to know that a message carries its sender's name in two different places. During the SMTP conversation, before any of the message is sent, the sending server announces an envelope sender with the MAIL FROM command. That address is where bounces go, and it is what the post office would see on the outside of the envelope. Then comes the message itself, the letter inside, with its own From: header, the one your mail program shows. Nothing in SMTP requires the two to match, and for legitimate reasons they often do not: a newsletter service sends with its own bounce address while the From shows the brand.

Each of the three DNS-published checks looks at a different identifier. SPF checks the envelope domain against the connecting IP address. DKIM checks a cryptographic signature made on behalf of a domain named inside the signature, the d= domain. DMARC then asks the question people actually care about: does either of those passing results belong to the domain in the visible From?

The Sender Policy Framework (RFC 7208) lets a domain publish, in a TXT record at its own name, the list of machines allowed to send mail using it as the envelope sender. A receiving server takes the connecting IP address and the MAIL FROM domain, fetches that domain's TXT records, finds the one that begins v=spf1, and reads it left to right. The first mechanism that matches the IP decides the result.

Each mechanism can carry a qualifier that says what a match means: + pass (the default if you write nothing), - fail, ~ softfail, and ? neutral. So -all at the end means "anything not listed before this point is not authorized," while ~all means "probably not authorized, but do not be harsh about it." If nothing matches and there is no redirect=, the result is neutral.

The word include misleads almost everyone. It does not paste the other record in. It runs a complete, separate SPF check against the other domain and counts as a match only if that check passes. A -all inside an included record therefore cannot fail your mail; it just makes the include "not match," and evaluation carries on with your next term.

Because includes nest, one innocent-looking record can fan out into dozens of queries. RFC 7208 caps this: the terms that cause DNS queries (include, a, mx, ptr, exists and redirect) may be used at most 10 times in a single evaluation, counting everything inside every include. The eleventh is a permerror, a permanent error that says the record itself is broken. It also caps void lookups, queries that come back empty or NXDOMAIN, at two by default. Every large organization that signs up for a few mail services eventually hits the ten, usually without noticing until a receiver starts treating its mail as unauthenticated.

DomainKeys Identified Mail (RFC 6376) works on the message rather than the connection. The sending system hashes the body and a chosen list of header fields, signs the result with a private key, and adds a DKIM-Signature header. Two tags in that header tell the receiver where to find the matching public key: d=, the signing domain, and s=, the selector. The receiver glues them together with the fixed label _domainkey and fetches a TXT record:

If the body still hashes to bh= and the signature verifies with the published key, the receiver knows two things: the signed parts have not changed since signing, and someone holding example.com's private key signed them. DKIM passes for d=example.com. Unlike SPF, that result does not depend on which server delivered the message, so it survives ordinary forwarding. It does not survive a mailing list that rewrites the subject or adds a footer, because then the hash no longer matches.

Selectors are what make keys manageable. A domain can publish as many keys as it likes, one per selector: one for its own servers, one for each mail service that signs on its behalf, and a new one each time it rotates. Key rotation is a three-step DNS exercise: publish the new key under a new selector, switch the signer over, and once mail signed with the old selector has had time to be delivered and checked, publish the old selector with an empty p=, which RFC 6376 defines as a revoked key.

SPF and DKIM each prove something about a domain. Neither proves anything about the domain in the From line. DMARC (Domain-based Message Authentication, Reporting, and Conformance) closes that gap with one rule: a message passes DMARC if SPF passed for a domain aligned with the From domain, or DKIM passed for a domain aligned with the From domain. Either one is enough.

Alignment comes in two strengths. Strict means the domains are identical. Relaxed, the default, means they share the same organizational domain, so a DKIM signature from mail.example.com aligns with a From of news.example.com, because both belong to example.com. Each check has its own setting: aspf for SPF and adkim for DKIM.

The domain owner publishes the policy as a TXT record at _dmarc under the From domain:

The three policies are requests, not commands. none asks for nothing; the owner just wants the reports. quarantine says failing mail is suspicious, which usually means the spam folder. reject says failing mail is not legitimate and can be refused during the SMTP conversation. Receivers combine the request with their own judgment, and the standard says they should.

The reports are what make DMARC deployable. With rua=, receivers send the domain owner a daily XML summary: which IP addresses sent mail using its From domain, how many messages, and whether SPF and DKIM passed and aligned. A domain owner starts at p=none, reads the reports until every legitimate stream (the office mail, the billing system, the newsletter service, the help desk) shows up aligned, and only then moves to quarantine and reject. Skipping that step is the classic way to lose your own invoices.

SPF, DKIM and DMARC are about who sent a message. A separate problem is whether the delivery to you is private. Server-to-server SMTP uses STARTTLS opportunistically: if both sides offer encryption they use it, and if not, they quietly carry on in plain text. Someone who can tamper with the connection can strip the offer, and the sender will never know. Worse, because MX records are usually unsigned, a forged DNS answer can point the sender at the wrong server altogether.

MTA-STS (RFC 8461) lets a receiving domain say "always use TLS to reach me, with a valid certificate, and only to these MX hosts." It takes two pieces. A TXT record at _mta-sts.example.com announces that a policy exists and gives it an id. The policy itself is a small text file served over HTTPS at a fixed address, so it is protected by the web certificate system rather than by DNS. A sender fetches the policy, caches it for max_age seconds (up to about a year), and checks the id on later deliveries to notice changes.

Start MTA-STS in mode: testing, which asks senders to report failures but deliver anyway. The reports come from TLS-RPT (RFC 8460): a TXT record at _smtp._tls.example.com naming where senders should send a daily summary of successful and failed TLS connections. Read them until they are clean, then switch to enforce. When you change the policy file, change the id in the TXT record too, or senders will keep using their cached copy.

There is a second, DNS-native way to do the same job: DANE for SMTP, which publishes the server's certificate fingerprint in TLSA records protected by DNSSEC. It depends on a signed zone, so it lives in Chapter 11.

Most organizations own more domains than they use for mail: old brand names, typo-protection registrations, a domain held for a future project. Each one is a From address someone else can borrow, and with no records published, receivers have nothing to check it against. Locking a parked domain down takes three records, and nothing else:

The null MX stops anyone from delivering to the domain, including bounces aimed at it. v=spf1 -all says no server is authorized, so SPF fails everywhere. DMARC p=reject covers the visible From and, with no sp= or np=, every subdomain below it, existing or not. There is no DKIM to publish: with no selector records, every signature claiming the domain fails, which is exactly what you want. Pointing rua= at a domain you do watch tells you when someone tries. (If the report address is in a different domain, that domain has to publish a small authorization record agreeing to receive them; RFC 9990 describes it.)

For a domain that does send mail, the same pieces add up to a short checklist, and the largest mailbox providers now require most of it. Google's published sender guidelines require every sender to Gmail to set up SPF or DKIM, have valid forward and reverse DNS for its sending addresses (Chapter 07), and use TLS. Senders of more than 5,000 messages a day to Gmail accounts must set up SPF and DKIM, publish a DMARC record (p=none is acceptable), align the From domain with either the SPF or the DKIM domain, and support one-click unsubscribe for marketing mail.