A Practical Guide to Email Authentication Protocols (SPF, DKIM, and DMARC)

You’d think in 2025 we wouldn’t be getting tricked by emails pretending to be our banks, bosses, or billing departments. But here we are. Spoofing is still wildly effective. Why? Because email, at its core, runs on trust. And most domains trust way too easily.

Here’s a jarring stat: companies lost $2.7 billion to email scams last year. That’s not just tech-illiterate interns clicking sketchy links. That’s seasoned employees, often doing exactly what they were trained to do. The issue isn’t just human error. It’s that most email systems are misconfigured or under-protected.

Thing is, fixing this isn’t rocket science. It’s more like… filling out a form correctly and being a little paranoid. Three tools exist specifically to deal with this: SPF, DKIM, and DMARC. They’re free. They work. And yet, most companies only implement one or two—if any.

Let’s go through what they are, how they work, and where people keep screwing them up.

SPF: The Party List Your Domain Actually Checks

SPF is a DNS record. That’s it. It lists which servers are allowed to send mail using your domain. If someone tries to send mail from an IP that’s not on the list, the receiving server can reject it.

But here’s where it gets awkward: SPF can be super easy to misconfigure. You can allow too much. Or not realize that forwarding email breaks it. Or forget to include a service like Mailchimp.

Imagine putting a bouncer at your party, but then telling them, “Eh, let in whoever looks like they belong.” That’s what happens when people use ~all instead of -all at the end of their SPF record. That single squiggle can open the door to 30% more spoofed emails, according to APWG.

Also, you only get one SPF record per domain. Multiple ones? DNS just picks one and ignores the rest. And people still do this.

DKIM: The Signature That Says “This Email Hasn’t Been Messed With”

DKIM is like a wax seal on a letter. Except it’s digital, invisible, and nobody notices it until it breaks.

Here’s the gist: when your server sends an email, it uses a private key to sign it. The public key lives in your DNS. The receiving server uses that public key to check the signature. If it checks out, it knows the message hasn’t been tampered with.

What’s wild is how many domains skip DKIM entirely. Or set it up with weak keys from a decade ago. You want at least 1024-bit RSA. Ideally 2048.

And unlike SPF, DKIM survives email forwarding. That’s crucial. Because a forwarded email will often fail SPF, but still pass DKIM, keeping it out of spam. Proofpoint even found that DKIM-signed mail gets flagged as junk 72% less often.

If you use Zoho, Mailchimp, Google, whatever—each one probably has a different DKIM key. You need to add all of them to your DNS. Yes, it’s tedious. But so is explaining to your CFO why the vendor never got that invoice.

DMARC: The Bouncer’s Rulebook

So what happens when an email fails SPF or DKIM? That’s where DMARC comes in. It’s a policy, defined in your DNS, that tells mail servers what to do with suspicious emails: ignore, quarantine, or reject.

p=none does nothing. It just watches and reports. Great for testing.

p=quarantine sends the bad emails to spam.

p=reject blocks them entirely.

Most companies start with none, gather data, then eventually move to reject. But lots never make the leap. They get stuck watching spoofed emails roll in, afraid to break anything by tightening up.

Thing is, companies with p=reject see 92% fewer spoofing incidents. So yeah, it’s worth moving toward.

And those DMARC reports you get? They’re in XML. Ugly but useful. They show which sources are sending mail from your domain, which are passing checks, and which need fixing. It’s not glamorous work, but it’s where you see the weird stuff—like that old vendor still using your domain, or a random server in Frankfurt trying to spoof your payroll emails.

Where It All Lives: DNS

SPF, DKIM, and DMARC all live in your domain’s DNS as TXT records. That means you (or your IT person) need access to your DNS management panel. Cloudflare, GoDaddy, Namecheap—wherever you manage your domain.

Here’s a fun gotcha: long DKIM keys can break if your DNS provider doesn’t handle multiline TXT records well. Some chop them up, others don’t. Check formatting carefully. Otherwise, your signatures just silently fail.

And while you’re in there, double-check your MX records. Those tell the world where to deliver your email in the first place. If they point to nowhere, everything else is moot.

Forwarding Breaks Stuff (But There’s a Fix)

Email forwarding is great for users. Terrible for SPF.

If Alice sends an email to Bob, and Bob forwards it to Carol, Carol’s server sees the message as coming from Bob’s server—which probably isn’t on Alice’s SPF list.

That’s why forwarded emails often fail SPF checks.

Enter SRS (Sender Rewriting Scheme). It rewrites the return-path on forwarded emails to keep SPF intact. Hardly anyone sets this up. But if you run your own mail servers or use fancy forwarding, it matters.

ARC (Authenticated Received Chain) is another patch. It chains authentication results together as emails move through multiple hops. Gmail uses it. Not every provider does.

If that sounds messy, that’s because it is. SPF and DKIM were never designed for forwarding. ARC and SRS are workarounds. Welcome to email.

Avoiding The Dumb Mistakes

A few recurring errors that keep showing up:

• Multiple SPF records. Don’t do this.
• Weak DKIM keys. Use strong ones and rotate them occasionally.
• Jumping straight to p=reject on DMARC without monitoring first.
• Forgetting to include services like Salesforce, HubSpot, etc., in SPF/DKIM.
• Never looking at your DMARC reports. Seriously, look at them.

Good tools exist: MXToolbox, DKIMCore, DMARCian, EasyDMARC. Use them.

Wrapping Up: Security That Feels Boring But Matters

SPF, DKIM, and DMARC don’t make headlines. They’re not flashy. They’re basically bureaucratic forms in DNS format. But when they’re working, it’s like locking all the doors and windows before going on vacation.

Most of the $2.7 billion lost last year could’ve been stopped with proper configuration of these three protocols. That’s wild. And sad.

You don’t need a full security team. You just need someone who understands DNS, a little patience, and a policy of not trusting email by default.

Start with SPF. Then DKIM. Watch your DMARC reports. Move from none to reject over time. That’s it. No need to overthink.

Email doesn’t have to be a liability. But it will be if you ignore this stuff.