2026-09-22 · IPV4 Scanner
Email was built for a small network of people who trusted each other, so by default anyone can send a message claiming to be from any address. That's not a bug someone forgot to fix. It's the original design, and SPF, DKIM and DMARC are the three DNS records that bolt authentication on after the fact.
They usually get explained as a wall of acronyms. They're really just three answers to three different questions, and once you know which question each one answers, the rest is easy.
SPF answers "is this server allowed to send for this domain?" You publish a list of the servers allowed to send as you, and the receiver checks whether the one that connected is on it.
DKIM answers "did this message really come from the domain, and did anyone change it on the way?" Your server signs each message with a private key, you publish the matching public key in DNS, and the receiver checks the signature.
DMARC answers "what do I do if the first two fail, and who do I tell?" It's also the one that ties the whole thing to the address a human actually reads in the From line.
You need all three because each has a hole the others cover. That's the part most explanations skip.
An SPF record is one TXT record listing who's allowed to send:
v=spf1 include:_spf.google.com include:sendgrid.net ~allThe ~all at the end is a soft fail for anything not listed. -all is a hard fail. Pick one. A record with no all at the end says nothing about the servers it didn't mention, which rather defeats the point.
SPF fails you in two ways. It checks the hidden envelope sender rather than the From address people actually see, so on its own it doesn't stop someone forging the name in your recipients' inbox. And it breaks the moment a message is forwarded, because the forwarding server isn't on your list. Both of those are exactly why DKIM exists.
There's also a limit that catches almost everyone eventually. An SPF record is allowed ten DNS lookups, and every include: drags in whatever that provider's own record uses. Go over ten and the whole record is treated as broken. Nothing warns you. You add one more sending service two years in, quietly cross the line, and a slice of your mail starts failing while the record still looks fine.
DKIM signs the message itself, so the signature travels with it. Forward the message and the signature still checks out, which is the exact case that breaks SPF.
The public key sits at a selector name in your DNS, something like selector1._domainkey.yourdomain.com. Your provider hands you the record to paste in. Use a 2048-bit key if you're offered the choice, since 1024 is considered weak now.
One annoying quirk: you can't list a domain's selectors. You have to already know the name to look one up, which is why a checker that says "no DKIM found" might just be guessing wrong names. Yours is in the DKIM-Signature header of any message you've sent, under s=.
Without DMARC, a server that spots an SPF or DKIM failure has no idea what you want it to do, and you never hear that it happened. DMARC fixes both halves of that.
v=DMARC1; p=reject; rua=mailto:[email protected]The p tag is the one that matters. p=none just watches and reports, blocking nothing. p=quarantine sends failures to spam. p=reject refuses them outright. You start at none. You don't stop there, which a surprising number of domains have been doing for years while thinking they're protected.
The rua address is where the daily reports land, and honestly those reports are the whole reason to sit at none for a while. They show you every service sending as your domain, including the legitimate ones you forgot about, so you can fix them before you turn the policy up and accidentally block your own invoices.
DMARC also checks something neither of the others does: alignment. The domain that passed SPF or DKIM has to match the domain in the visible From address. That match is what actually stops someone waving your brand name around.
Do this in the wrong order and you'll block your own mail. The safe run is: publish SPF listing everything that sends for you, turn on DKIM signing for each of those services, then publish DMARC at p=none with an rua address. Read the reports for a couple of weeks. Fix anything legitimate that's failing. Only then move to quarantine, and later reject.
You can check all three for any domain, lookup count included, with our SPF, DKIM and DMARC checker. It also catches the setups that look fine but aren't, like a record sitting at exactly ten lookups with no room to breathe.
Do I really need all three?
In practice, yes. SPF breaks on forwarding, DKIM survives it, and DMARC is the only one that ties either result to the domain your recipients see. Big providers increasingly demand all three from anyone sending in bulk.
Will this stop my mail going to spam?
It's a big part of it. Authentication is one of the first things a receiver checks. It isn't everything, since reputation and content count too, but missing it is an easy way to get filtered.
What's the difference between p=none and no DMARC at all?
p=none still sends you reports, so you can see who's sending as you. No record gives you nothing. Neither blocks spoofing, so treat none as a monitoring step, not a finish line.
My SPF passes but DMARC still fails. Why?
Usually alignment. SPF passed for a different domain than the one in your From line, and DMARC wants them to match. That's deliberately stricter than SPF by itself.
Is -all safe?
Once you're sure every real sender is on the list, yes, and DMARC reports are how you get sure. Until then, ~all is safer. Never use +all, which tells the whole internet it can send as you.