PristineSend
Get started
BlogDeliverability

SPF, DKIM, and DMARC: A no-nonsense guide for marketers

Lucas Lefort·May 18, 2026·5 min read
Deliverability

If you've ever wondered why your emails land in spam, the answer is usually sitting in your DNS records — or more accurately, missing from them.

Three protocols decide whether mailbox providers like Gmail and Outlook trust your emails: SPF, DKIM, and DMARC. They're not optional anymore. As of 2024, Google and Yahoo require all three for bulk senders. Microsoft is following.

This guide explains what each one does in plain English, why marketers need to care, and how to set them up correctly the first time.

Why authentication matters

Email was designed in the 1970s with zero security. Anyone could send a message claiming to be anyone. That's why your inbox is full of "Apple Support" emails that aren't from Apple.

Mailbox providers fight back using three checks:

  • SPF verifies the sending server is allowed to send for your domain
  • DKIM verifies the email wasn't tampered with in transit
  • DMARC tells receivers what to do when SPF or DKIM fails

If you pass all three, your sender reputation goes up and your emails reach inboxes. If you fail, you land in spam — or worse, get blocked entirely.

SPF: who's allowed to send for you

Sender Policy Framework is a TXT record on your domain that lists every server authorized to send email as you.

Here's what an SPF record looks like:

v=spf1 include:_spf.google.com include:amazonses.com -all

Translation: "Emails from this domain are valid if they come from Google's servers or Amazon SES's servers. Reject anything else."

The -all at the end is critical. It means "fail anything not on this list." If you use ~all instead (soft fail), spammers can forge your domain more easily.

Common SPF mistakes

The biggest mistake is having multiple SPF records. You can only have ONE TXT record starting with v=spf1. If you have two, both fail.

When you add a new sending service, you don't create a new SPF record — you add to the existing one:

# Wrong - two separate records
v=spf1 include:_spf.google.com -all
v=spf1 include:amazonses.com -all

# Right - one combined record  
v=spf1 include:_spf.google.com include:amazonses.com -all

Another common mistake: SPF has a 10-DNS-lookup limit. Each include: counts as one lookup. If you exceed 10, SPF silently breaks.

DKIM: digital signatures for your emails

DomainKeys Identified Mail is a cryptographic signature added to every email you send. The signature proves two things:

  1. The email actually came from your domain
  2. The email wasn't modified after you sent it

Setting up DKIM requires adding a TXT record (or sometimes a CNAME) provided by your email service. The record contains a public key. Your email service uses the matching private key to sign every outgoing message.

When Gmail receives your email, it looks up the public key from your DNS, verifies the signature, and decides whether to trust the message.

Why DKIM matters more than SPF

SPF can break the moment someone forwards your email — the forwarding server isn't on your SPF list. DKIM survives forwarding because the signature is embedded in the email itself.

If you can only set up one authentication method, set up DKIM. SPF is easier but less reliable.

DMARC: the policy that ties it all together

Domain-based Message Authentication, Reporting, and Conformance is the most important record of the three. DMARC tells mailbox providers what to do when SPF or DKIM fails.

A DMARC record looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

The p= policy has three options:

  • p=none — monitor only, don't reject anything (start here)
  • p=quarantine — send failures to spam folder
  • p=reject — reject failures entirely (highest protection)

The rua= part sends you weekly reports showing who's trying to send email as you. These reports are gold — they reveal forgotten sending services and impersonation attempts.

The DMARC rollout pattern

Don't jump straight to p=reject. You'll accidentally block legitimate emails from services you forgot about. Roll out gradually:

Week 1-2: Monitoring

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Read the weekly reports. Identify every legitimate sender. Make sure they all pass SPF and DKIM.

Week 3-4: Quarantine 10%

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com

Only 10% of failures go to spam. Watch for complaints.

Month 2: Quarantine 100%

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

All failures go to spam. Monitor for two weeks.

Month 3: Reject

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

Maximum protection. You're now fully authenticated.

How to verify your setup is working

Don't trust that you set things up correctly — verify with these free tools:

MXToolbox SPF lookup: enter your domain at mxtoolbox.com/SuperTool.aspx and check the SPF record syntax

DMARC analyzer: dmarcian.com/dmarc-inspector — paste your domain to see if DMARC is configured correctly

Mail-tester: send a test email to a unique address at mail-tester.com — they grade your authentication and content

Gmail's "Show original": send yourself a test email, open it in Gmail, click the three dots and "Show original". Look for three "PASS" results at the top:

SPF: PASS with IP 1.2.3.4
DKIM: 'PASS' with domain yourdomain.com  
DMARC: 'PASS'

If any show FAIL or NEUTRAL, fix that first.

The bottom line

Email authentication isn't optional anymore. Without SPF, DKIM, and DMARC properly configured:

  • Gmail will throttle your sends
  • Outlook will route you to spam
  • Yahoo will reject bulk mail outright
  • Your domain becomes vulnerable to spoofing
  • Your sender reputation slowly degrades

The good news? Setup is a one-time job. Get all three records right and your deliverability problems are 60% solved.

Want help authenticating your domain? PristineSend walks you through SPF, DKIM, and DMARC setup automatically when you add a new sending domain. We verify each record is correct before letting you send.

Start sending with confidence →

#spf#dkim#dmarc#authentication#dns#deliverability
Share this postShare on XShare on LinkedIn

Continue reading