MX, SPF, DKIM, and DMARC: Email Auth in One Sitting

Email authentication has a reputation for being a rabbit hole of acronyms. It is not, really. There are four records, each with one job, and they stack in a specific order. Once you can say what each one does in a sentence, the rest is detail.

This is a setup guide rather than a troubleshooting guide. It walks through what each record is for, what a working example looks like, and the order in which you should publish them — the last of which matters more than most people expect.

Four records, four jobs

MX tells the world where to deliver mail for your domain. SPF lists who is allowed to send as you. DKIM signs your outgoing messages. DMARC tells receivers what to do when the first three do not line up, and where to send reports about it.

Notice that only the first one is about routing, and the other three are about identity. That distinction explains a lot of confusion: if mail is bouncing entirely, look at MX. If mail is being delivered but landing in spam, the other three are where the story is.

MX: where mail goes

An MX record names the servers that accept mail for your domain, and each one carries a preference number. Lower numbers are tried first, so a typical setup looks like this:

Name	Type	Priority	Value
example.com	MX	10	mx1.mailhost.example
example.com	MX	20	mx2.mailhost.example

Two details are worth remembering. MX values must be hostnames, never bare IP addresses — the specification requires it, and some providers will reject the record rather than accept it. And if you want mail for a subdomain, you need MX records on that subdomain too; the apex does not lend its records downwards.

Check that your MX hostnames resolve, and that they answer on port 25, before you look at anything else. Try it on DNS Checkers MX Lookup

SPF: the guest list

SPF is a TXT record that tells receivers which servers may send mail claiming to be from your domain.

v=spf1 include:_spf.google.com include:sendgrid.net -all

Read it left to right. The version tag marks the record. Each include: pulls in another provider's published list of legitimate senders. The final mechanism decides what happens to everything else: -all is a hard fail, ~all is a soft fail, ?all asserts nothing at all.

The single most common SPF mistake is having more than one record. Two TXT records beginning with v=spf1 is a permanent error, and receivers will fail the check rather than guess which one you meant. When you add a sending service, edit the existing record. Never add a second one.

The second most common mistake is running out of lookups. SPF allows at most ten DNS lookups to resolve every mechanism in the record, and includes are nested — one provider's list may pull in several more. Go over ten and receivers return permerror, which is worse than a clean fail because it has no obvious owner. If you are near the limit, look for includes you no longer need before you reach for flattening services. Try it on DNS Checkers Check TXT / SPF

DKIM: the signature

DKIM gives each message a cryptographic signature, and publishes the matching public key in DNS. The private half stays on the sending server. The public half goes in a TXT record at a name like this:

selector1._domainkey.example.com

The word to notice is selector. You do not publish one DKIM key, you publish one per selector, and the sender tells the receiver which selector to look up. That design is what lets you rotate keys safely: publish a new selector, switch the sender to it, and retire the old one once nothing is signing with it any more.

A DKIM record contains a version tag, a key type, and a base64 public key, with optional flags and a note about the key. Use at least 1024 bits, and 2048 if your provider supports it.

If DKIM verification fails, the usual causes are a selector that no longer exists in DNS, a key that was rotated on one side but not the other, or something in your mail pipeline rewriting the message after signing. A signature covers the message, so appending a footer after signing invalidates it completely.

DMARC: the policy

DMARC is a TXT record at _dmarc.example.com. It does two things: it tells receivers what to do when SPF or DKIM fails, and it asks them to send you reports.

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s

The p tag is the policy: none means deliver anyway, quarantine means treat failures as suspicious, reject means refuse them. The rua address receives aggregate reports. The adkim and aspf tags control how strictly forwarded mail must align.

Almost everyone should start at p=none. Publishing a strict policy before you know what you actually send is how domains end up rejecting their own invoices.

Alignment: the rule that decides everything

This is the concept people skip, and it is the one that determines whether DMARC works.

DMARC does not simply ask whether SPF or DKIM passed. It asks whether the domain that passed is aligned with the domain in the visible From header. A message can pass SPF cleanly and still fail DMARC, because the domain that authenticated was not the one the recipient sees.

That is why sending through a third party sometimes passes SPF and still gets flagged. The authentication worked. It just authenticated a different identity.

The misconfigurations you will actually meet

Almost every authentication problem is one of a short list, and recognising them saves a lot of time.

Two SPF records is the most common by a wide margin. It usually arrives when a second sending service is onboarded and someone adds a new record rather than editing the existing one. The tell is a lookup that returns two strings both beginning with v=spf1.

Running past the ten-lookup limit comes next, and it is harder to spot because the record looks perfectly reasonable. Each include: is a separate lookup, several pull in further includes of their own, and the total creeps upwards as services accumulate. Receivers return permerror, which is usually reported as "SPF is broken" with no further detail.

Missing DKIM selectors are the third. A provider rotates a key, the old selector is removed, and the sender is still signing with it. The signature fails — and because DKIM is the mechanism that survives forwarding, mail that used to pass now fails every time it is relayed.

The fourth is DMARC published at a strict policy before the senders were known. It works fine until a legitimate service you had forgotten about sends its first monthly invoice, at which point invoices start disappearing. This one is entirely avoidable by starting at p=none and actually reading the reports.

A complete example

Put together, a working domain looks something like this.

Name	Type	Value
example.com	MX 10	mx1.mailhost.example
example.com	TXT	v=spf1 include:_spf.google.com -all
selector1._domainkey.example.com	TXT	v=DKIM1; k=rsa; p=MIGfMA0...
_dmarc.example.com	TXT	v=DMARC1; p=none; rua=mailto:dmarc@example.com

Four records, and nothing exotic in any of them.

The order to publish things

Routing first, then authentication, then policy, then enforcement.

Get MX right and confirm mail is delivered. Merge every sender into a single SPF record and confirm it stays under the lookup limit. Enable DKIM at each sending service and confirm signatures verify. Publish DMARC at p=none with a reporting address. Then, once the reports are clean, step up to quarantine and later reject.

Each step is verifiable on its own, which is the point. A setup you can verify one layer at a time is a setup you can fix.

What DNS cannot fix

Two things are worth being clear about, because both are commonly blamed on records.

DNS cannot rescue a poor sending reputation. A brand-new domain or a newly allocated IP range has no history, and history is most of what inbox providers are weighing. Authentication gives you the right to be evaluated. It does not guarantee the outcome.

And DNS cannot fix content. If your messages look like the messages filters are trained to distrust, no policy will save them. Authentication removes the excuse; it does not create trust on its own.

What the first week of reports looks like

Once DMARC reports begin arriving, the first thing worth looking at is volume rather than failure. A handful of messages failing from a source you do not recognise is usually noise, or occasionally someone spoofing you. A steady percentage of your real mail failing is a legitimate system you have not onboarded yet.

The second thing to look for is alignment. Messages where SPF passed but DMARC still failed are the interesting ones, because they mean a sender is authenticating as a domain the recipient never sees. That is precisely the case a strict policy will break, so it is far better to find it now than after you move to p=reject.

Read one report all the way through the first time. They are dense XML, but the fields that matter are few: the sending IP, its reverse name, the SPF and DKIM results, and the domain that actually authenticated.

Where to check your work

Look up MX and confirm the hosts answer. Read the SPF record and count the lookups. Ask for the DKIM selector your provider actually signs with. And check that the DMARC record exists and says what you think it says. Try it on DNS Checkers Lookup All DNS Records

Four records, checked in order, and you have eliminated every deliverability problem that was ever yours to solve in DNS.