They're all DNS TXT records, they all relate to email, and they're constantly confused with each other. Here's the one-line version: SPF says which servers may send for you. DKIM signs each message so it can't be altered. DMARC says what receivers should do when a message fails the other two. You need all three, and they work in a specific order.
SPF is a TXT record on your domain that lists the IP addresses and hostnames allowed to send mail as that domain. When a receiver gets mail claiming to be from you, it checks the sending IP against this list. A typical small-business SPF looks like:
v=spf1 include:_spf.google.com ~all
The include pulls in your email provider's own list. The ending matters: -all means "everything not listed is a hard fail", ~all means "soft fail, deliver but mark it". Two practical gotchas: SPF is limited to 10 DNS lookups (each include counts), and a domain can have only one SPF record. If your provider's instructions say "add this SPF", you're probably meant to merge it into the record you already have, not create a second one.
DKIM solves the problem SPF has: the sending IP can be spoofed in the envelope, but a DKIM signature can't be forged without the private key. Your mail server signs each outgoing message with a private key; the matching public key lives in a TXT record at selector._domainkey.yourdomain.com. The receiver fetches that key and verifies the signature. If it matches, the message came from someone holding your private key, and it wasn't altered in transit.
Most email providers set this up for you automatically. The common failure is a domain that was moved between providers: the old DKIM record gets deleted, or the new provider's key is published under a different selector, and mail that used to authenticate now doesn't. Google also requires 2048-bit DKIM keys for bulk senders; 1024-bit keys were deprecated in 2024.
SPF and DKIM each produce a pass or fail, but by themselves they don't tell the receiver what to do. DMARC does: it's the record at _dmarc.yourdomain.com that says "if a message fails SPF or DKIM (and the domains don't align), apply my policy." Start at p=none to collect reports, move to p=quarantine when your legitimate senders all pass, and p=reject when you're confident. The full walkthrough is in our DMARC guide.
No SPF: receivers can't verify the sending server at all. Many will still deliver, but your mail is easier to spoof and you're below the bar that Google and Yahoo now ask of bulk senders.
No DKIM: you have an allow-list but no signature. Mail that routes through a relay or gets forwarded loses its SPF pass (the IP changes), and there's nothing left to prove it's yours.
No DMARC: even with perfect SPF and DKIM, there's no policy telling receivers to act on failures, and no report stream telling you when someone else starts sending as you. This is the most common gap, because it's the record nobody sets up until they hear about it.
1. SPF first. It's one TXT record and it's the foundation.
2. DKIM second. Confirm your provider's selector and key are published.
3. DMARC last. Publishing a policy before the other two work just gives you a way to reject your own mail.
Related: What is DMARC? · p=none vs quarantine vs reject · Why email misses Gmail's inbox · SPF record not working? · SPF, DKIM, DMARC for Google Workspace · DKIM not signing emails? · Email auth for startups
The free audit checks all three (plus MX, TLS, PTR and IP reputation) and shows the exact record to add.
Run the free auditWant this checked automatically every day? Inboxproof Pro monitors your domain around the clock and alerts you the moment a record breaks or an IP gets listed. See pricing →