SPF vs DKIM vs DMARC: The Developer's Guide to Email Authentication (2026)

The Problem: Your Emails Are Guilty Until Proven Innocent

You've built a SaaS. Users sign up. They don't get the verification email. Support ticket incoming.

You check your email provider's dashboard—emails are "sent." But Gmail, Outlook, and Yahoo are silently dropping them into spam (or the void). Why? Because your domain has no proof of identity.

Email was invented in 1971. Authentication came much later. Without SPF, DKIM, and DMARC, receiving servers have no way to verify you're really you@yourstartup.com and not a phisher in a trenchcoat.

Here's how the three protocols work together—explained without the enterprise jargon.

The Three Layers of Email Authentication

Think of email authentication like entering a venue:

You need all three. Let's break them down.

SPF: The Guest List

Sender Policy Framework is a DNS TXT record that lists which servers are allowed to send email on behalf of your domain.

How It Works

• 1.You publish a TXT record on your domain listing authorized senders
• 2.When someone receives an email claiming to be from yourdomain.com, their server checks the SPF record
• 3.If the sending IP is on the list → PASS. If not → FAIL (or soft fail).

Example SPF Record

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

Breaking it down:

The 10 Lookup Limit

SPF has a hard limit of 10 DNS lookups. Each include: counts as a lookup. Exceed it, and SPF breaks completely—no partial credit.

Common mistake: Adding every service you've ever used. Audit your senders and remove anything not actively sending email.

Pro tip: Use DmarcBeacon's scanner to check your current lookup count instantly.

Softfail vs Hardfail

Start with ~all while auditing. Switch to -all once you're confident all senders are listed.

DKIM: The Wax Seal

DomainKeys Identified Mail adds a cryptographic signature to every email. It proves the message wasn't altered in transit and that it came from someone with access to your domain's private key.

How It Works

• 1.Your email server signs outgoing messages with a private key
• 2.The public key is published in your DNS as a TXT record
• 3.Receiving servers verify the signature against the public key

Example DKIM Record

# DNS Record Name
google._domainkey.yourdomain.com
# DNS Record Value
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Breaking it down:

What's a Selector?

The "selector" (google in the example) allows you to have multiple DKIM keys for different services. Each email provider gives you their own selector.

Common selectors:

Why DKIM Alone Isn't Enough

DKIM proves the email wasn't tampered with. But it doesn't prove the sender was authorized to send on your behalf. A phisher could set up DKIM for phisher.com and send perfect DKIM-signed emails—just not from your domain.

That's where DMARC comes in.

DMARC: The Bouncer

Domain-based Message Authentication, Reporting, and Conformance ties SPF and DKIM together with a policy. It answers the question: "What should receivers do when authentication fails?"

How It Works

• 1.You publish a DMARC policy in DNS
• 2.When email arrives, the receiver checks SPF and DKIM
• 3.If either passes AND aligns with the From domain → PASS
• 4.If both fail → Apply the DMARC policy (none, quarantine, or reject)

Example DMARC Record

# DNS Record Name
_dmarc.yourdomain.com
# DNS Record Value
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100

Breaking it down:

The Three Policies

The p=reject Trap

Do NOT start with p=reject.

If you have misconfigured senders or forgotten services still sending on your behalf, p=reject will block legitimate emails. Always start with p=none, analyze reports for a few weeks, then gradually tighten.

Recommended rollout:

Alignment: The Hidden Requirement

DMARC requires "alignment"—the domain in the From: header must match the domain verified by SPF or DKIM.

Example:

From: hello@yourstartup.com
SPF verified: yourstartup.com ✅ Aligned
DKIM signed: mail.sendgrid.net ❌ Not aligned

If neither SPF nor DKIM aligns with the From domain, DMARC fails—even if both protocols passed individually.

This is why third-party senders (SendGrid, Mailchimp, etc.) need to be configured with custom domains for DKIM, not just their defaults.

Quick Reference: Record Types

Here's what your DNS should look like when properly configured:

Common Mistakes (and How to Avoid Them)

1. Multiple SPF Records

You can only have one SPF record per domain. Multiple records cause SPF to fail.

❌ Wrong:

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

✅ Right:

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

2. Exceeding 10 DNS Lookups

Each include: triggers a lookup. If you exceed 10, SPF breaks. Use an SPF lookup checker to audit.

3. Skipping DKIM for Third-Party Senders

Your email provider (SendGrid, Mailchimp, etc.) sends on your behalf. If they don't sign with your domain's DKIM, alignment fails. Always configure custom domain authentication in their dashboard.

4. Starting with p=reject

We've said it twice, saying it again: don't start with p=reject. Monitor first.

Testing Your Setup

Send a Test Email

After configuring, send an email to a Gmail account. Open it and click the three dots → Show original. Look for:

SPF: PASS
DKIM: PASS
DMARC: PASS

All three should say PASS. If any fails, check your DNS records.

Use DmarcBeacon

Skip the guesswork. DmarcBeacon scans your domain and shows:

• SPF record status and lookup count
• DKIM configuration health
• DMARC policy and alignment
• Overall security score

TL;DR

The order matters:

• 1.Set up SPF (list your senders)
• 2.Set up DKIM (enable in each email provider)
• 3.Set up DMARC with p=none (monitor)
• 4.Analyze reports for 2-4 weeks
• 5.Gradually move to p=reject

Next Steps

• 1.Scan your domain at dmarcbeacon.com to see your current status
• 2.Fix any missing records using your DNS provider
• 3.Monitor DMARC reports to catch rogue senders
• 4.Tighten your policy over time from none → quarantine → reject