SPF, DKIM, and DMARC Explained: The Complete Guide to Email Authentication

You've written the perfect cold email. Your subject line is compelling, your copy is clean, and your list is verified. You hit send — and it lands in spam. Not because of your content. Not because of your reputation. Because your domain doesn't have proper email authentication set up.

Email authentication is the set of DNS records that prove to inbox providers that you are who you say you are. Without it, Gmail, Outlook, and Yahoo have no way to distinguish your legitimate emails from a spammer pretending to send from your domain. When in doubt, they filter you.

Since February 2024, Google and Yahoo require SPF, DKIM, and DMARC for any sender pushing more than 5,000 emails per day. But even if you're sending far less, missing authentication directly hurts your inbox placement.

This guide explains what each protocol does, how they work together, and how to set them up correctly.

The Problem Authentication Solves

Email was designed in the 1970s with no concept of identity verification. The SMTP protocol lets anyone send an email claiming to be from any address. You could send an email right now that says it's from ceo@google.com — SMTP doesn't care.

This is called email spoofing, and it's the foundation of phishing attacks, CEO fraud, and domain impersonation. SPF, DKIM, and DMARC were created to fix this by giving domain owners a way to declare: "Only these servers are authorized to send email from my domain."

SPF: Sender Policy Framework

What It Does

SPF tells inbox providers which mail servers are allowed to send email on behalf of your domain. It's a DNS TXT record that lists authorized IP addresses and services.

How It Works

1. You publish an SPF record in your domain's DNS.
2. When someone receives an email "from" your domain, their mail server checks your SPF record.
3. If the sending server's IP is in the SPF record, the check passes. If not, it fails.

Setting It Up

Add a TXT record to your domain's DNS:

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

Breaking this down:

• v=spf1 — This is an SPF record (version 1).
• include:_spf.google.com — Authorize Google Workspace to send from your domain.
• include:sendgrid.net — Authorize SendGrid to send from your domain.
• -all — Reject (hard fail) any server not listed here.

The -all vs ~all distinction matters:

• -all (hard fail): Any email from an unauthorized server should be rejected. Strictest.
• ~all (soft fail): Any email from an unauthorized server is suspicious but shouldn't be outright rejected. More permissive.

Use -all if you're confident your SPF record lists all legitimate sending services. Use ~all during initial setup while you're still identifying all your sending sources.

Common SPF Mistakes

Too many DNS lookups. SPF records are limited to 10 DNS lookups. Each include: typically triggers one lookup, and they can be nested. If your record exceeds 10, it becomes invalid — which is worse than having no SPF record at all. Use tools like mxtoolbox.com to check your lookup count.

Forgetting a sending service. If you send marketing through SendGrid, transactional through Postmark, and internal email through Google Workspace, your SPF record needs all three. Missing one means those emails fail SPF checks.

Multiple SPF records. A domain should have exactly one SPF record. If you add a second one instead of updating the first, SPF breaks entirely.

DKIM: DomainKeys Identified Mail

What It Does

DKIM adds a cryptographic signature to every outgoing email. The recipient's mail server verifies this signature against a public key published in your DNS. If the signature checks out, the email hasn't been tampered with and actually came from your domain.

How It Works

1. Your mail server generates a public/private key pair.
2. The private key signs each outgoing email by creating a hash of specific headers and the body.
3. The signature is added as a DKIM-Signature header on the email.
4. You publish the public key as a DNS TXT record.
5. The recipient's server uses the public key to verify the signature.

Setting It Up

DKIM setup depends on your email provider. Most providers generate the key pair and give you a DNS record to publish.

Google Workspace:

1. Admin console → Apps → Google Workspace → Gmail → Authenticate email
2. Generate a new DKIM key
3. Add the TXT record they provide to your DNS:

selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

SendGrid:

1. Settings → Sender Authentication → Domain Authentication
2. Follow the wizard — they provide three CNAME records to add to your DNS

Amazon SES:

1. Verified Identities → Domain → DKIM
2. Easy DKIM provides three CNAME records

The key is to set up DKIM for every service that sends email from your domain. If you use Google Workspace for internal email and SendGrid for marketing, both need DKIM configured.

Common DKIM Mistakes

Not rotating keys. DKIM keys should be rotated periodically (every 6–12 months). Old keys that get compromised allow attackers to send signed emails from your domain.

Using 1024-bit keys. The minimum recommended key size is now 2048 bits. Google switched to 2048-bit DKIM in 2013. If your key is still 1024 bits, upgrade.

Forgetting about forwarding. When an email is forwarded, the body might change (mailing lists often add footers), which breaks the DKIM signature. This is normal and expected — DMARC's alignment rules handle this (more below).

DMARC: Domain-based Message Authentication, Reporting & Conformance

What It Does

DMARC ties SPF and DKIM together and tells inbox providers what to do when an email fails both checks. It also gives you reporting — you can receive data on who is sending email from your domain and whether it's passing authentication.

How It Works

1. You publish a DMARC record in your DNS.
2. When an inbox provider receives an email from your domain, it checks SPF and DKIM.
3. If both fail (or the domains don't align), the provider follows your DMARC policy: none (do nothing), quarantine (spam folder), or reject (block entirely).
4. The provider sends you aggregate reports showing authentication results.

DMARC Alignment

This is the part most people miss. DMARC doesn't just check that SPF or DKIM passed — it checks that the domain in the From: header matches (aligns with) the domain that passed SPF or DKIM.

Example: You send an email with From: you@yourdomain.com through SendGrid. The SPF check passes for sendgrid.net (SendGrid's servers). But the From: domain is yourdomain.com. Unless SendGrid's sending is properly aligned with your domain (via domain authentication), DMARC alignment fails even though SPF passed.

This is why proper domain authentication with your ESP matters — it's not just about passing SPF/DKIM individually, it's about passing them for your domain specifically.

Setting It Up

Add a TXT record to your DNS at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100

Breaking this down:

• v=DMARC1 — This is a DMARC record.
• p=none — Policy: don't take action on failures (monitoring mode).
• rua=mailto:... — Where to send aggregate reports (daily summaries).
• ruf=mailto:... — Where to send forensic reports (individual failure details).
• pct=100 — Apply the policy to 100% of emails.

The DMARC Rollout Path

Never jump straight to p=reject. Roll out in stages:

Stage 1: Monitor (p=none) — 2–4 weeks

• Don't affect email delivery. Just collect reports.
• Review reports to identify all legitimate sending sources.
• Fix SPF and DKIM for any services that aren't passing.

Stage 2: Quarantine (p=quarantine; pct=10) — 2–4 weeks

• Start quarantining (spam-foldering) 10% of failing emails.
• Monitor for legitimate emails getting caught.
• Gradually increase pct to 25%, 50%, 100%.

Stage 3: Reject (p=reject) — Ongoing

• Full enforcement. Emails that fail DMARC are rejected outright.
• This is the goal — it fully protects your domain from spoofing.
• Continue monitoring reports for new sending services you might add.

How They Work Together

Think of SPF, DKIM, and DMARC as three layers:

Protocol	Question it answers
SPF	Was this email sent from an authorized server?
DKIM	Was this email's content intact and signed by the domain?
DMARC	What should we do if SPF and DKIM fail, and are they aligned with the From domain?

An email needs to pass either SPF or DKIM alignment (not both) to pass DMARC. But best practice is to set up both — some scenarios (forwarding, mailing lists) break one but not the other.

Why This Matters for Deliverability

Even if you're not worried about spoofing, email authentication directly affects whether your emails reach the inbox.

Gmail's Requirements (Since February 2024)

For senders of 5,000+ daily messages:

• SPF and DKIM must be configured
• DMARC must be published (at minimum p=none)
• One-click unsubscribe header required
• Spam complaint rate below 0.3%
• Bounce rate below 2%

For smaller senders, SPF or DKIM (at least one) is required. But setting up all three is strongly recommended regardless of volume.

Microsoft's Requirements (Since May 2025)

Microsoft now requires SPF, DKIM, and DMARC for senders of 5,000+ daily messages to Outlook.com, Hotmail, and Live addresses. Emails failing DMARC from high-volume senders are routed to the Junk folder.

The Deliverability Impact

Properly authenticated emails see measurably better inbox placement. This isn't theoretical — it's because authentication is a weighted signal in every major provider's spam filtering algorithm. Missing authentication doesn't automatically mean spam, but it removes a positive signal that helps you stay in the inbox.

Checking Your Setup

Quick DNS Check

Use dig or nslookup to verify your records:

# Check SPF
dig TXT yourdomain.com | grep spf

# Check DKIM (replace 'selector' with your DKIM selector)
dig TXT selector._domainkey.yourdomain.com

# Check DMARC
dig TXT _dmarc.yourdomain.com

Before Checking Your DNS — Verify Your Emails Are Deliverable

Authentication is only part of the equation. Even with perfect SPF, DKIM, and DMARC, sending to invalid addresses still damages your reputation. Use MailProbe to verify that your email list is clean before sending:

curl -X POST https://mailprobe.dev/api/v1/verify \
  -H "Authorization: Bearer mp_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"emails": ["recipient@example.com"]}'

Authentication ensures your emails are trusted. Verification ensures they're delivered. You need both.

Key Takeaways

1. SPF declares which servers can send from your domain. Set it up for every service that sends email on your behalf.
2. DKIM cryptographically signs your emails. Configure it with 2048-bit keys and rotate regularly.
3. DMARC ties SPF and DKIM together and tells providers what to do with failures. Roll out gradually: none → quarantine → reject.
4. Google and Microsoft now require all three for high-volume senders. Even low-volume senders benefit from full authentication.
5. Authentication and verification work together. Auth ensures trust; verification ensures your list is clean. Use both.

MailProbe handles the verification side — real-time email verification with syntax, DNS, SMTP, and deliverability checks. Pair it with proper authentication for maximum inbox placement.

Get started free →