How DNS decides where mail goes — Email Authentication Fundamentals

A sending server has an address like bob@recipient.org and needs an IP address to connect to. DNS is what bridges that gap, and the mechanism it uses is the first of many places where email delegates a decision to the domain owner.

MX records, and preference

An MX record names a host that accepts mail for a domain, together with a preference number. Lower numbers are tried first.

$ dig +short MX bbc.co.uk

10 cluster1.eu.messagelabs.com.
20 cluster1a.eu.messagelabs.com.

Checked 2026-09-12. Two hosts: 10 is tried first, 20 only if it cannot be reached.

The number is a preference, not a priority ranking or a weight. Equal values are used interchangeably, which is how load sharing is expressed. A single MX with preference 0 is perfectly normal:

$ dig +short MX github.com

0 github-com.mail.protection.outlook.com.

Checked 2026-09-12. One host, and the name tells you who runs the mail.

Lower is more preferred, and this gets inverted constantly

People read "priority 10" and assume higher means more important. It is the reverse, and the consequence of getting it backwards is that all your mail goes to your backup host — which usually still works, so nobody notices until the backup has a different spam configuration and starts rejecting things.

When there is no MX

If a domain publishes no MX record, a sender falls back to its address records and delivers to the domain itself, per RFC 5321 §5.1. This is called the implicit MX, and it is why a domain with a website and no mail configuration can still receive mail — usually at a web server that is not expecting it.

This matters for parked and retired domains. A domain you are not using for mail, with an A record pointing at a web host, is still a valid destination as far as every sender on the internet is concerned.

TXT records, and why email policy lives in DNS

The other record type doing heavy lifting is TXT. It has no defined meaning — it carries arbitrary text — which is exactly why it became the place every email-authentication standard put its policy.

What	Where it lives	How it is recognised
SPF	TXT at the domain itself	Starts `v=spf1`
DKIM public key	TXT at `{selector}._domainkey.{domain}`	Position in the name
DMARC policy	TXT at `_dmarc.{domain}`	Starts `v=DMARC1`
Domain verification	TXT at the domain itself	A vendor-specific prefix

Two consequences follow from this design, and both bite people later:

A domain can have many TXT records at the same name, and often does. Publishing a second SPF record does not replace the first — it makes the domain’s SPF configuration permanently broken, because the standard requires exactly one.
A single TXT record is a sequence of strings, each at most 255 characters. Long records are split, and the pieces are joined back together with nothing between them. Here is GitHub’s SPF record, split mid-IP-address:

$ dig +short TXT github.com | grep spf1

"v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com ... ip4:62.253.2" "27.114 ip4:166.78.69.169 ... ~all"

Checked 2026-09-12, abbreviated. The address 62.253.227.114 is split across the two strings — concatenation happens with no separator, so a space added "to tidy it up" would corrupt it.

Checking by hand

Throughout this course, the instruction is to look at the record yourself rather than trusting a control panel’s rendering of it. Two commands cover most of it:

dig +short MX example.com        # where does mail for this domain go
dig +short TXT example.com       # every TXT record at the name

A control panel shows you what it stored. dig shows you what the world can see, which is occasionally a different thing.

Knowledge check

A domain publishes MX records at preference 10 and 50, and separately two TXT records that both begin v=spf1. Which statement is true?

Mail is delivered to the preference-50 host first, and the two SPF records are merged.
Mail is delivered to the preference-10 host first, and the domain’s SPF evaluation now fails permanently.
Mail is delivered to the preference-10 host first, and receivers use whichever SPF record appears first.
The domain cannot receive mail at all until the duplicate SPF record is removed.

Not this — Mail is delivered to the preference-50 host first, and the two SPF records are merged. Both halves are inverted. Lower preference is tried first, and SPF records are never merged — a second one is a configuration error, not an extension.

Correct — Mail is delivered to the preference-10 host first, and the domain’s SPF evaluation now fails permanently. Lower preference is more preferred. And because RFC 7208 permits exactly one SPF record, a receiver that finds two cannot choose between them and returns permerror — a hard failure, not a fallback to the first one.

Not this — Mail is delivered to the preference-10 host first, and receivers use whichever SPF record appears first. The delivery half is right. But there is no defined ordering for TXT records at a name — a receiver has no basis for picking one, which is precisely why the standard makes two records an error rather than a preference.

Not this — The domain cannot receive mail at all until the duplicate SPF record is removed. SPF describes who may send as this domain. It has no bearing on whether the domain can receive mail, and the MX records are unaffected.