SPF vs DKIM vs DMARC: What Each One Does and Why You Need All Three

If your newsletters have started landing in spam, or a mailbox provider bounced your campaign with a message about authentication, you’ve met the three acronyms every sender now has to understand: SPF, DKIM and DMARC. They used to be “nice to have”. Since Google and Yahoo’s bulk sender rules in 2024, followed by Microsoft for Outlook.com in 2025, they’re the price of reaching the inbox.

The good news: each one does a simple job. Here’s what they are, how they fit together and the mistakes that trip up most marketing teams.

The short version

Think of sending an email like sending a parcel from your company.

• SPF is the list of couriers allowed to carry parcels for you. If an unknown courier shows up, the recipient gets suspicious.
• DKIM is a tamper-evident seal on the parcel. It proves the contents weren’t changed on the way and that the seal belongs to you.
• DMARC is your instruction to the recipient: “If a parcel claims to be from us but fails these checks, here’s what to do with it, and please send me a report.”

None of them is enough alone. Together, they make it hard for anyone else to send mail that looks like it came from your domain.

SPF: who is allowed to send

Sender Policy Framework is a TXT record on your domain listing the servers and services allowed to send mail for it. A typical record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

When a receiving server gets a message, it checks the sending server’s IP against that list.

What to know:

• One record only. Two SPF records on the same domain make SPF fail entirely. Merge them into one.
• The 10-lookup limit. Every include, a, mx and redirect costs a DNS lookup, and nested includes count too. Go over 10 and SPF returns an error. Adding “just one more” email tool is how most teams hit it.
• ~all vs -all. Soft fail (~all) marks unlisted senders as suspicious. Hard fail (-all) says reject them. Start with ~all until you’re sure every legitimate sender is listed.
• SPF checks the hidden envelope sender, not the From address your readers see. That’s one reason it needs DMARC to be truly useful.
• Forwarding breaks it. When a message is forwarded, it arrives from the forwarder’s server, which isn’t on your list.

DKIM: proof the message is genuine

DomainKeys Identified Mail adds a digital signature to each message. Your sending service signs it with a private key, and receivers check it against a public key published in DNS at selector._domainkey.yourdomain.com.

What to know:

• Every sending service needs its own DKIM setup. Your mailbox provider, newsletter platform, CRM and helpdesk each sign with their own key and selector.
• Use 2048-bit keys where the provider allows it.
• DKIM usually survives forwarding, because the signature travels with the message. That makes it the more reliable half of DMARC.
• Changes to the message break it. Mailing lists that add footers or rewrite subjects can invalidate the signature.

DMARC: the policy and the reports

Domain-based Message Authentication, Reporting and Conformance ties the other two to the From address people actually see. A message passes DMARC when SPF or DKIM passes and the domain it checked matches (aligns with) the visible From domain.

The record lives at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]

• p=none only monitors. p=quarantine sends failing mail to spam. p=reject blocks it.
• rua is where receivers send daily aggregate reports showing who is sending mail as your domain, and whether it passed.

Those reports are DMARC’s hidden superpower. They’re how you discover the forgotten invoicing tool or the old WordPress plugin sending as your domain, before you tighten the policy.

Side by side

Common mistakes marketing teams make

1. Forgetting a sending service. The newsletter tool is set up, but the CRM, the support desk and the e-commerce platform also send as your domain.
2. Going straight to p=reject. Without reading reports first, you’ll block your own legitimate mail.
3. Never moving past p=none. It satisfies the bulk sender rules, but it doesn’t stop anyone spoofing you.
4. Copying records between domains. Each domain and subdomain that sends mail needs its own setup.
5. Changing DNS without checking. A new DNS host or a quick edit can silently drop a TXT record.

How to check your setup

The fastest way to see where you stand is to run your domain through an spf checker that tests all three records at once. A good one parses the SPF record and counts DNS lookups, looks up your DKIM selectors, reads the DMARC policy and flags problems in plain language. Do it now, and again every time you add a new email tool.

Because DNS records can change without anyone noticing, it’s also worth monitoring them. Services such as FastPing grade SPF, DKIM and DMARC and alert you when a record changes or a DKIM key disappears, which is exactly the kind of quiet breakage that shows up weeks later as a drop in open rates.

The bottom line

SPF says who may send. DKIM proves the message is real. DMARC connects both to the address your readers see and tells the world what to do with fakes. Set up all three, read your DMARC reports for a few weeks, then move your policy to quarantine and eventually reject. Your deliverability, and your brand, will thank you.