SPF, DKIM, and DMARC Explained

Email authentication can feel overwhelming. SPF, DKIM, DMARC—what are these acronyms, and why do they matter? This guide explains how these three protocols work together to protect your email and improve deliverability.

The Email Authentication Problem

Email was designed in an era when trust was assumed. The original email protocols had no way to verify that a message actually came from who it claimed to be from. Anyone could send an email that appeared to come from your domain.

This made email spoofing trivially easy. Phishers exploit this constantly, sending fake emails that look like they're from banks, companies, or people you know.

SPF, DKIM, and DMARC were created to solve this problem. Together, they form a system that lets email receivers verify whether messages are legitimate.

SPF: Who Can Send

SPF (Sender Policy Framework) answers a simple question: which servers are allowed to send email for this domain?

You publish an SPF record in your DNS that lists authorized senders:

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

This record says: "Google and SendGrid can send email for my domain. Reject anything from other servers."

When someone receives an email claiming to be from your domain, their server checks your SPF record. If the sending server isn't on the list, the email fails SPF authentication.

SPF's limitation: SPF validates the "envelope sender" (return-path), not the "From" address that recipients see. An attacker could use a different return-path while spoofing your visible From address.

DKIM: Message Integrity

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to emails. It proves two things:

1. The email came from a server with access to your private key
2. The message wasn't modified in transit

Here's how it works:

1. When you send an email, your mail server creates a digital signature using a private key
2. This signature is added to the email headers
3. Your public key is published in DNS
4. Receiving servers use the public key to verify the signature

If the signature checks out, the email is authenticated. If someone modified the message or forged the signature, verification fails.

DKIM's advantage: The signature travels with the message, so it survives forwarding. Unlike SPF, which breaks when emails are forwarded through different servers, DKIM can still authenticate forwarded messages.

Check your DKIM setup with a DKIM tester.

DMARC: The Policy Layer

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and adds two critical features:

1. Alignment — DMARC requires that SPF or DKIM authentication aligns with the visible "From" address. This closes the loophole where attackers use different envelope senders.

2. Policy — DMARC tells receivers what to do when authentication fails: nothing, quarantine, or reject.

A DMARC record looks like:

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

This says: "Reject emails that fail authentication, and send me reports about authentication results."

Check your DMARC configuration with a DMARC checker.

How They Work Together

The three protocols complement each other:

A typical authentication flow:

1. Email arrives at receiving server
2. Server checks SPF — is the sending IP authorized?
3. Server checks DKIM — is the signature valid?
4. Server checks DMARC — do results align with the From address? What policy applies?
5. Based on results, email is delivered, quarantined, or rejected

You need all three for complete protection. SPF alone has gaps. DKIM alone has no policy enforcement. DMARC brings them together.

Setting Up All Three

Step 1: Configure SPF

Add a TXT record to your DNS listing all services that send email for your domain:

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

See our guide on how SPF works for details.

Step 2: Configure DKIM

DKIM setup varies by email provider:

• Google Workspace: Admin console → Apps → Gmail → Authenticate email
• Microsoft 365: Microsoft 365 admin center → Settings → Domains
• SendGrid/Mailchimp: Settings → Sender Authentication

Your provider gives you DNS records to add. These publish your public key.

Step 3: Configure DMARC

Start with a monitoring policy to see what's happening:

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

Add this as a TXT record at _dmarc.yourdomain.com.

After monitoring and fixing issues, gradually increase enforcement:

1. p=none — Monitor only, don't affect delivery
2. p=quarantine — Send failures to spam
3. p=reject — Block failures entirely

Common Authentication Scenarios

Everything passes

spf=pass, dkim=pass, dmarc=pass

The email is legitimate and properly authenticated. Strong positive signal for inbox delivery.

SPF fails, DKIM passes

spf=fail, dkim=pass, dmarc=pass

Common with forwarded emails. SPF fails because the forwarding server isn't in your SPF record, but DKIM still validates. DMARC passes because DKIM aligns.

Both fail

spf=fail, dkim=fail, dmarc=fail

Either a spoofed email (good—your authentication is working) or a misconfiguration (bad—fix it). Check if you've authorized all your legitimate sending services.

DMARC alignment failure

spf=pass, dkim=pass, dmarc=fail

The underlying checks pass, but neither aligns with the visible From address. This often happens with third-party services that aren't properly configured to send on behalf of your domain.

Why You Need All Three

Some people ask: "Can't I just use one?" Here's why you need the complete set:

SPF alone:

• Doesn't prevent From address spoofing
• Breaks on forwarding
• No reporting
• No policy control

DKIM alone:

• No policy control
• Attackers could sign with their own key
• No reporting

DMARC alone:

• Requires SPF or DKIM to function
• Without the underlying protocols, DMARC has nothing to evaluate

The trio works as a system. Each protocol addresses weaknesses in the others.

Impact on Email Deliverability

Major email providers increasingly require authentication:

Gmail announced that bulk senders must have SPF, DKIM, and DMARC configured. Unauthenticated emails face delivery issues.

Yahoo implemented similar requirements for high-volume senders.

Microsoft uses authentication heavily in spam filtering decisions.

Even for low-volume senders, proper authentication:

• Improves inbox placement
• Builds sender reputation
• Protects your brand from spoofing
• Enables monitoring through DMARC reports

Checking Your Authentication

Use these tools to verify your setup:

• SPF: Use the checker above or visit SPF Record Check
• DKIM: Test with DKIM Test
• DMARC: Verify at DMARC Record Checker
• MX Records: Check at MX Record Checker

Or check everything at once with the Email Deliverability Suite.

Common Mistakes to Avoid

Not including all sending services in SPF Every tool that sends email on your behalf—marketing platforms, CRMs, support tools—needs to be in your SPF record.

Exceeding SPF lookup limits SPF allows only 10 DNS lookups. Too many includes causes failures.

Starting DMARC with p=reject Begin with p=none to monitor, then gradually increase enforcement. Starting with reject risks blocking legitimate emails.

Forgetting subdomains If you send from marketing.yourdomain.com, it needs its own SPF record. Consider DMARC subdomain policy (sp=) as well.

Not monitoring DMARC reports DMARC reports reveal authentication issues. Review them regularly or use a service that aggregates and analyzes them.

Monitor Your Email Authentication

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.