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

You've cleaned your email list. Your bounce rate is under 1%. Your content is relevant. But your emails are still landing in spam.

The problem might not be what you're sending — it's that receiving mail servers can't verify who you are.

Email authentication is how you prove to Gmail, Microsoft, Yahoo, and every other inbox provider that your emails are legitimately from you and haven't been tampered with in transit. It's built on three protocols that work together: SPF, DKIM, and DMARC.

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

Why Email Authentication Matters

Email was designed in the 1970s and 80s without any built-in identity verification. The "From" address in an email is trivially easy to forge — anyone can send an email claiming to be from your domain. This is called spoofing, and it's the foundation of most phishing attacks.

Email authentication protocols were developed to solve this. They let receiving mail servers answer three questions:

1. Is this server authorized to send email for this domain? (SPF)
2. Has this email been tampered with in transit? (DKIM)
3. What should I do if an email fails these checks? (DMARC)

Without authentication, receiving servers have no reliable way to distinguish your legitimate marketing email from a phishing email that spoofs your domain. Many will default to the safe choice: spam folder, or outright rejection.

The Numbers

• Gmail and Yahoo required DMARC for bulk senders starting February 2024. Senders without it see deliverability drops of 10-30%.
• Microsoft 365 began enforcing stricter SPF/DKIM checks in late 2024.
• According to Valimail's 2025 Email Authentication Report, domains with full DMARC enforcement (p=reject) see 10% higher inbox placement rates versus domains with no DMARC.

SPF: Sender Policy Framework

What It Does

SPF tells receiving mail servers which IP addresses and servers are authorized to send email on behalf of your domain. Think of it as a guest list — if the sending server isn't on the list, the email is suspect.

How It Works

1. You publish an SPF record in your domain's DNS (a TXT record)
2. When someone receives an email claiming to be from your domain, their mail server looks up your SPF record
3. It checks whether the IP address that sent the email is listed in your SPF record
4. If it matches → SPF passes. If not → SPF fails.

SPF Record Syntax

An SPF record is a DNS TXT record on your root domain. Here's a typical one:

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

Breaking it down:

The -all at the end is important. Options are:

• -all — Hard fail: unauthorized servers are rejected (recommended)
• ~all — Soft fail: unauthorized servers are flagged but not rejected (common during testing)
• ?all — Neutral: no opinion on unauthorized servers (effectively useless)

SPF Limitations

10 DNS lookup limit: SPF records can trigger a maximum of 10 DNS lookups. Each include: directive counts as one. If you use many third-party services (ESP, CRM, helpdesk, transactional email), you can hit this limit fast. Exceeding it causes SPF to fail entirely.

No protection against "display name" spoofing: SPF checks the envelope sender (Return-Path), not the "From" header that users see. An attacker can still make the visible "From" name look like your company.

Breaks with forwarding: When an email is forwarded, the sending IP changes to the forwarding server's IP, which isn't in your SPF record. This is one reason SPF alone isn't sufficient.

Setting Up SPF

Google Workspace:

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

Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Multiple services (Google Workspace + SendGrid + Mailchimp):

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

Add this as a TXT record on your root domain (e.g., emailkit.dev) in your DNS provider.

DKIM: DomainKeys Identified Mail

What It Does

DKIM adds a cryptographic signature to every email you send. The receiving server can verify this signature to confirm two things: the email actually came from your domain, and it hasn't been modified in transit.

How It Works

1. Your mail server generates a public/private key pair
2. The private key stays on your mail server; the public key is published in DNS
3. When sending an email, your server creates a hash of specific email headers and body content, then encrypts the hash with the private key — this is the DKIM signature
4. The receiving server retrieves your public key from DNS, decrypts the signature, and compares the hash
5. If they match → DKIM passes. The email is authentic and unmodified.

DKIM Record

A DKIM record is a DNS TXT record on a subdomain, typically formatted as selector._domainkey.yourdomain.com. For example:

google._domainkey.emailkit.dev  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

DKIM Advantages Over SPF

• Survives forwarding: The signature travels with the email, so it still validates even when forwarded
• Detects tampering: Any modification to the signed headers or body invalidates the signature
• Per-service keys: Different selectors allow different services to sign with different keys

Setting Up DKIM

Google Workspace:

1. Admin Console → Apps → Gmail → Authenticate email
2. Generate a new DKIM key (2048-bit recommended)
3. Add the TXT record Google provides to your DNS
4. Return to Admin Console and click "Start authentication"

Microsoft 365:

1. Microsoft 365 Defender → Email & Collaboration → Policies → DKIM
2. Select your domain and enable DKIM signing
3. Add the two CNAME records Microsoft provides to your DNS

Third-party ESPs (SendGrid, Mailchimp, etc.): Each provides their own DKIM setup instructions, typically involving adding CNAME records to your DNS.

DMARC: Domain-based Message Authentication, Reporting & Conformance

What It Does

DMARC ties SPF and DKIM together and tells receiving servers what to do when an email fails authentication. It also provides reporting, so you can see who's sending email using your domain — both legitimate and fraudulent.

How It Works

1. You publish a DMARC record in DNS
2. When a receiving server gets an email from your domain, it checks SPF and DKIM
3. It then checks alignment: does the domain in SPF/DKIM match the "From" domain the user sees?
4. If either SPF or DKIM passes and aligns → DMARC passes
5. If both fail or neither aligns → DMARC fails, and the receiving server follows your policy

DMARC Record

A DMARC record is a DNS TXT record on _dmarc.yourdomain.com:

_dmarc.emailkit.dev  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

DMARC Policies

The Recommended DMARC Rollout

Don't jump straight to p=reject. Follow this path:

Phase 1 (2-4 weeks): Monitor

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

Collect reports. Identify all legitimate services sending email as your domain. Make sure each one passes SPF or DKIM.

Phase 2 (2-4 weeks): Quarantine

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

Start quarantining 25% of failures. Monitor for legitimate emails hitting spam. Increase pct gradually to 100%.

Phase 3: Enforce

v=DMARC1; p=reject; rua=mailto:[email protected]

Full protection. Emails that fail authentication are rejected outright.

How SPF, DKIM, and DMARC Work Together

Each protocol covers a different gap:

DMARC is what makes SPF and DKIM actionable. Without DMARC, a mail server knows that SPF or DKIM failed but has no policy guidance on what to do about it.

Testing Your Setup

Check SPF

dig TXT yourdomain.com | grep spf

Or use online tools like MXToolbox SPF Lookup.

Check DKIM

dig TXT selector._domainkey.yourdomain.com

Replace selector with your DKIM selector (e.g., google for Google Workspace).

Check DMARC

dig TXT _dmarc.yourdomain.com

Send a Test Email

Send an email to a Gmail address and click "Show original" to see the authentication results:

Authentication-Results: mx.google.com;
       dkim=pass [email protected]
       spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender)
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

All three should show pass.

Common Mistakes

1. Multiple SPF Records

You can only have one SPF record per domain. If you have two (common when adding a new service), SPF fails for all emails. Combine them into a single record.

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 the SPF 10-Lookup Limit

Each include: triggers DNS lookups, and nested includes count too. Google's _spf.google.com alone uses 3-4 lookups. If you exceed 10 total, SPF fails completely — a "permerror."

Solutions: Remove services you no longer use, use IP addresses (ip4:) instead of include: where possible, or use an SPF flattening service.

3. Forgetting Third-Party Services

Your marketing team signed up for a new ESP and started sending emails. Those emails fail SPF because the ESP's servers aren't in your SPF record. Audit all services that send email as your domain: transactional email, marketing platforms, helpdesk software, CRM systems, billing/invoicing tools.

4. DMARC Without SPF or DKIM

DMARC requires at least one of SPF or DKIM to pass and align. Setting up DMARC without either is like installing a security camera with no lock on the door.

5. Jumping to p=reject

Going straight to p=reject without monitoring will block legitimate emails from services you forgot about. Always start with p=none, review reports, then gradually enforce.

Email Authentication and Deliverability

Authentication is one half of the deliverability equation. The other half is list quality.

A perfectly authenticated email sent to an invalid address still generates a bounce. A perfectly authenticated email sent to a spam trap still damages your reputation.

Authentication proves who you are. Email verification proves you're sending to real people. Both are necessary. Neither is sufficient alone.

If you're working on improving your deliverability, start by verifying your authentication setup with the steps above, then move to cleaning your email list to address the list quality side.

Next up: Learn about Email Verification for SaaS — how to protect your platform from fake signups and reduce churn.