MX vs SPF vs DKIM - which DNS records control what?
MX routes incoming mail. SPF authorises outgoing senders. DKIM signs the messages. Here's how the three records work together - and what breaks when one is missing.
Three DNS records run your email - and people constantly mix them up. MX is for incoming. SPF and DKIM are for outgoing. They cover different problems, and missing any one of them creates a deliverability hole. Here's what each one does, in plain terms.
MX - where mail comes in
MX (Mail Exchanger) records tell other mail servers where to deliver mail to your domain. Anyone sending email to [email protected] looks up example.com's MX records, then connects to whichever server they list.
Multiple MX records = redundancy. Lower priority is tried first; higher numbers are backups.
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.If you don't have MX records, incoming email to your domain doesn't work. Senders may fall back to your A record (deprecated) or just bounce.
Run the MX Lookup to see who handles your incoming mail.
SPF - who's allowed to send as your domain
SPF (Sender Policy Framework) is a TXT record listing the IPs and domains authorised to send email claiming to be from your domain. A receiving server checks: "this message claims to be from example.com - does its source IP appear in example.com's SPF record?"
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"include:incorporates another sender's SPF (e.g. Google Workspace authorises Google's mail IPs).-allat the end means "anything not listed should be rejected".
Without SPF, anyone can send mail claiming to be from your domain. Receivers downgrade unauthenticated mail.
Run the SPF Checker - it'll count your DNS lookups (max 10 - see the SPF lookup limit guide).
DKIM - does the message itself prove it's authentic
DKIM (DomainKeys Identified Mail) signs each outgoing message with a cryptographic signature. The receiver fetches your DKIM public key from DNS and verifies the signature.
SPF authorises the sending IP; DKIM authenticates the specific message. The difference matters when mail is forwarded - SPF can break (the forwarder's IP isn't authorised), but DKIM survives because the message body and signed headers are unchanged.
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."The selector lets you rotate keys without disrupting older messages.
Run the DKIM Checker with your selector to verify the public key is published.
How they interact (and why DMARC is the glue)
SPF and DKIM each tell receivers this message looks authentic. DMARC tells receivers what to do when both SPF and DKIM fail (and how strictly to align them with the From: header). Without DMARC, even fully-authenticated mail provides no clear policy signal - receivers fall back to their own heuristics.
The full email-auth stack:
- SPF: who can send
- DKIM: prove the message wasn't tampered with
- DMARC: what to do if SPF or DKIM fail
Plus optionally:
- BIMI: show your logo in the inbox (requires DMARC at
p=quarantineorp=reject) - MTA-STS: force TLS for incoming mail
- TLS-RPT: get reports when TLS fails
What breaks when each is missing
| Missing | Symptom |
|---|---|
| MX | Incoming mail bounces or never arrives. |
| SPF | Outgoing mail scored as suspicious. Spammers can spoof you. |
| DKIM | Forwarded mail breaks. Receivers can't verify message integrity. Spam folder more often. |
| DMARC | No policy signal - receivers may apply their own (often hostile) heuristics. No reports. |
| PTR | Mail server treated as unknown sender - see the PTR records guide. |
Audit all five in 5 minutes: MX, SPF, DKIM, DMARC, PTR. If any return a problem, fix that one before touching the next.
To see MX, SPF and DMARC for a real domain on one page, open /d/google.com, then run your own domain from the home page and compare. DKIM needs a selector, so it stays in the DKIM Checker.