Do I need all three — SPF, DKIM, and DMARC?

Yes. As of 2024, Gmail and Yahoo require all three for bulk senders (5,000+ messages/day). Even below that threshold, missing any one protocol weakens your authentication and increases spam placement risk.

What order should I set up email authentication?

SPF first (quickest, tells servers who can send for you), DKIM second (requires ESP-specific setup), DMARC last (depends on SPF and DKIM being correct first). Start DMARC at p=none to monitor, then advance to quarantine, then reject.

How long does email authentication take to work?

DNS changes propagate within 1-48 hours depending on TTL. SPF changes are usually effective within 1-4 hours. DKIM and DMARC similarly. However, the reputation benefit of proper authentication builds over days to weeks.

Can email authentication alone fix my deliverability?

Authentication is necessary but not sufficient. It prevents impersonation and builds trust, which directly improves [deliverability](/email-deliverability/email-deliverability-guide). But if your list is dirty, your reputation is damaged, or your sending patterns are erratic, authentication alone won't fix those issues.

What happens if I set DMARC to reject too quickly?

Legitimate email from services you forgot to authorize will be rejected entirely — users won't receive it at all. This is why you start at p=none (monitor only), review DMARC aggregate reports for 2-4 weeks to identify all legitimate senders, authorize them, then advance to quarantine and finally reject.

SPF, DKIM, DMARC: The Complete Email Authentication Guide

The Authentication Stack

Email authentication exists because SMTP (the protocol email runs on) has zero built-in sender verification. Anyone can claim to send from any domain. Authentication protocols fix this.

You need all three. Here's what each does.

SPF: Who Can Send For Your Domain

SPF (Sender Policy Framework) publishes a DNS TXT record listing every IP address and service authorized to send email using your domain.

SPF Record Format

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

v=spf1 — required version tag
include: — authorizes another domain's SPF record (used for ESPs)
a — authorizes the domain's A record IP
mx — authorizes the domain's MX record IPs
ip4: / ip6: — authorizes specific IP addresses
-all — hard fail everything else (recommended)
~all — soft fail (less strict, used during testing)

SPF Rules You Must Know

10 DNS lookup limit. SPF allows a maximum of 10 DNS lookups (includes, a, mx, exists mechanisms). Exceed this and you get a permerror — authentication fails silently.

One SPF record per domain. Multiple SPF TXT records cause both to fail. Merge everything into one record.

Include your ESP. Every service that sends email for your domain needs to be in your SPF record. Forgot to add your CRM's sending service? Those emails fail SPF.

SPF for Common Setups

Google Workspace: v=spf1 include:_spf.google.com ~all

Microsoft 365: v=spf1 include:spf.protection.outlook.com -all

Google Workspace + SendGrid: v=spf1 include:_spf.google.com include:sendgrid.net -all

DKIM: Proving Message Integrity

DKIM (DomainKeys Identified Mail) adds a digital signature to every outgoing email. The receiving server checks this signature against a public key in your DNS to verify the message hasn't been altered.

How DKIM Works

Your sending server signs the message with a private key
The signature is added as a DKIM-Signature header
The receiving server looks up the public key via DNS (using the selector)
If the signature matches, DKIM passes

DKIM Setup

Each ESP has its own DKIM setup process. Typically:

ESP generates a DKIM key pair
You add a CNAME or TXT record to your DNS pointing to the ESP's key
ESP signs outgoing messages with the private key

The DNS record looks like: selector._domainkey.yourdomain.com

DKIM Key Size

Use 2048-bit keys. 1024-bit keys are still accepted but increasingly flagged as weak. Some DNS providers have character limits on TXT records — use CNAME records to point to your ESP's hosted key instead.

DKIM Alignment

For DMARC to pass via DKIM, the d= domain in the DKIM signature must align with the From: header domain. This can be relaxed (organizational domain match) or strict (exact domain match).

DMARC: The Policy Layer

DMARC (Domain-based Message Authentication, Reporting and Conformance) does two things:

Tells receiving servers what to do when SPF and DKIM both fail
Sends you reports about authentication results

DMARC Record Format

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

p=none — monitor only, take no action on failures
p=quarantine — send failures to spam
p=reject — reject failures entirely
rua= — where to send aggregate reports (daily summaries)
ruf= — where to send forensic reports (individual failures)
pct= — what percentage of messages to apply the policy to

The DMARC Advancement Path

Week 1-2: Set p=none and start collecting aggregate reports. Identify all services sending email for your domain.

Week 3-4: Authorize all legitimate senders in SPF and DKIM. Fix alignment issues.

Week 5-6: Move to p=quarantine; pct=25 — quarantine 25% of failures.

Week 7-8: Increase to pct=50, then pct=100.

Week 9+: Move to p=reject when you're confident all legitimate email is authenticated.

Practitioner note: Don't rush to p=reject. I've seen companies reject their own invoicing system's email because nobody knew the billing platform was sending from their domain. Check the DMARC reports thoroughly.

Practitioner note: Most DMARC aggregate reports are XML and unreadable. Use a parser — dmarcian, Postmark's free tool, or DMARC Analyzer. Trying to read raw XML reports is a waste of time.

Practitioner note: A lot of "DMARC setup guides" tell you to use ruf= for forensic reports. In practice, very few mailbox providers actually send forensic reports. Focus on rua= aggregate reports — that's where the useful data is.

The Authentication Checklist

Run through this for every domain that sends email:

One SPF record with all senders included, under 10 lookups
DKIM configured and signing for every sending service
DMARC record published with at least p=none and an rua address
SPF alignment: envelope sender domain matches From: domain
DKIM alignment: DKIM d= domain matches From: domain
All subdomains that send email have their own authentication
Tested with MXToolbox, Mail-Tester, or similar

Beyond the Basics: BIMI and MTA-STS

BIMI (Brand Indicators for Message Identification) displays your brand logo next to authenticated emails. Requires DMARC at p=quarantine or p=reject, plus a Verified Mark Certificate (VMC) for Gmail.

MTA-STS (Mail Transfer Agent Strict Transport Security) enforces TLS encryption for incoming mail to your domain. Prevents downgrade attacks.

Both are recommended but not required. Get SPF, DKIM, and DMARC right first. For detailed setup instructions, see the individual guides: SPF setup, DKIM setup, DMARC setup.

If you'd rather have authentication configured correctly the first time, schedule an infrastructure audit — I set up authentication for businesses that need it done right, not approximately.

Sources

RFC 7208: Sender Policy Framework (SPF)
RFC 6376: DomainKeys Identified Mail (DKIM)
RFC 7489: Domain-based Message Authentication (DMARC)
RFC 8617: Authenticated Received Chain (ARC)
Google: Email Authentication Requirements

v1.0 · March 2026