SPF, DKIM, DMARC, and MX in plain English

Every guide to email authentication assumes you already know what a DNS TXT record is for. This one does not. By the end you will know what SPF, DKIM, DMARC, and MX each do, what the records actually look like, and why passing one check while failing another still lands you in spam.

One mental model carries the whole thing: receiving mail servers are bouncers. Your domain is the name on the guest list. Each record answers one question the bouncer asks before letting a message in.

SPF answers: who is allowed to send for this domain?

SPF is a TXT record on your domain that lists the servers permitted to send mail claiming to come from it. When Gmail receives a message that says it is from you@yourapp.com, it looks up the SPF record on yourapp.com and checks whether the sending server is on the list.

yourapp.com.  TXT  "v=spf1 include:spf.zevsend.com ~all"

Read it right to left. The ~all means "anything not listed here should be treated with suspicion". The include: pulls in another domain’s list, which is how you authorise an email provider without copying their server addresses by hand.

Two rules people learn the hard way. First, a domain gets exactly one SPF record; publishing a second one fails validation for both, so when a new provider asks you to add SPF and one already exists, merge them into a single record. Second, SPF allows at most ten DNS lookups per check. Every include: costs at least one, and some cost several, so a domain that authorises five services can silently go over the limit and fail.

DKIM answers: was this message changed in transit?

DKIM is a cryptographic signature. Your email provider signs each outgoing message with a private key, and publishes the matching public key in your DNS so any receiver can verify the signature. If the message was altered after signing, or the signature does not match the published key, DKIM fails.

zevsend._domainkey.yourapp.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The zevsend part before ._domainkey is called a selector. It exists so several services can each publish their own key on the same domain without colliding. That is why the record your provider gives you has a strange host name: the selector is theirs, the domain is yours.

DKIM survives forwarding, which SPF does not. When someone auto-forwards your message to another inbox, the forwarding server is not on your SPF list, so SPF fails. The DKIM signature travels inside the message and still verifies. This is why serious senders always configure both.

DMARC answers: and what should you do about it?

SPF and DKIM produce verdicts. DMARC is the policy that tells receivers what to do with those verdicts, and it adds the one check the other two skip: alignment. Alignment means the domain that passed SPF or DKIM must match the domain in the From header the human actually sees.

Without alignment, a spammer can pass SPF for their own throwaway domain while displaying your domain in the From line. DMARC closes that gap, which is why Gmail and Yahoo now require it from bulk senders.

_dmarc.yourapp.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourapp.com"

The p= value is your instruction to receivers. none means just report, quarantine means send failures to spam, reject means refuse them outright. Start at none, watch the reports that arrive at your rua address for a couple of weeks, then tighten. Jumping straight to reject before you know every legitimate sender on your domain is how companies block their own invoices.

MX answers: where does mail for this domain go?

MX records are about receiving, so it surprises people that senders need them too. Two reasons. First, many receivers treat a domain with no MX record as not a real mail domain and score messages from it accordingly. Second, bounce messages have to go somewhere: when a send fails, the receiving server mails the failure notice back, and without an MX record that notice has nowhere to land, so you never learn the address was bad.

mail.yourapp.com.  MX 10  feedback-smtp.eu-west-1.amazonses.com.

Transactional providers usually ask for an MX record on a subdomain like mail.yourapp.com rather than the root. That subdomain is the return path for bounces, and keeping it separate means your bounce plumbing never interferes with the MX records that route your team’s actual inbox.

How they fail together

• SPF passes but DMARC fails. The classic alignment trap: your provider’s domain passed SPF, but your From header shows your domain. Fix: DKIM signing with your own domain.

• DKIM passes on the wrong selector. You rotated providers, published the new key, and deleted the old selector while queued mail was still signed with it.

• Two SPF records. Both invalid the moment the second one is published. Merge, never add.

• Everything verifies, mail still goes to spam. Authentication is the entry ticket, not the seat. Reputation, bounce rate, and complaint rate decide the rest.

The checklist

• One SPF record on the sending domain, under ten lookups, ending in ~all or -all.

• DKIM published on the selector your provider gave you, and the signing domain matches your From domain.

• A DMARC record at _dmarc. with a rua address someone actually reads. Start at p=none, tighten deliberately.

• An MX record on your bounce subdomain so failure notices reach your provider and bad addresses get suppressed.

• After any DNS change, verify from the outside with a fresh lookup, not from your registrar’s dashboard.