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

Q: What is the difference between SPF, DKIM, and DMARC?

SPF (Sender Policy Framework) authorizes which IP addresses can send email for your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to emails to prove they were not tampered with. DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together, enforces a policy for emails that fail both checks, and provides reporting so you can monitor your domain's email activity.

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

Yes, ideally. SPF and DKIM each authenticate different aspects of an email, and DMARC requires at least one of them to pass with alignment. Having all three configured correctly provides the strongest protection against spoofing and phishing, and is required by Gmail and Yahoo for bulk senders.

Q: In what order should I set up SPF, DKIM, and DMARC?

Always set up SPF and DKIM first, verify they are passing correctly, and then add DMARC in monitoring mode (p=none). This order ensures your legitimate email is authenticating before you apply any enforcement policy.

Q: Can I have multiple SPF records?

No. You can only have one SPF TXT record per domain. Having multiple SPF records causes SPF to fail with a PermError. If you use multiple sending services, combine them into a single record using multiple 'include:' mechanisms.

Q: Does DKIM survive email forwarding?

Usually yes. DKIM signatures are attached to the message headers, not to the sending IP, so they typically survive forwarding intact. SPF, by contrast, fails when a message is forwarded because the forwarding server's IP is not in the original sender's SPF record. This is one reason DKIM is generally the more reliable authentication signal for DMARC.

The SMTP protocol that moves email across the internet was designed in the 1980s with no concept of authentication. Any server could claim to be sending from any domain. Decades later, three standards were built on top of SMTP to fix this: SPF, DKIM, and DMARC.

Together they form the foundation of modern email authentication — and since 2024, they are a hard requirement from Google and Yahoo for anyone sending more than 5,000 emails per day. This guide explains what each protocol does, how they work together, and how to configure all three correctly from scratch.

How the Three Protocols Fit Together

Think of them as three complementary layers of trust:

SPF

Authorizes who can send

A DNS record that lists the IP addresses and mail servers permitted to send email on behalf of your domain. Checked at the network layer during the SMTP handshake.

DKIM

Proves the message is genuine

A cryptographic signature added to outgoing email headers. Proves the message came from your domain and was not altered in transit. Survives forwarding.

DMARC

Enforces and reports

Ties SPF and DKIM together with an alignment check. Tells receiving servers what to do when authentication fails, and sends you reports on everything sent from your domain.

None of the three works optimally in isolation. SPF alone can be bypassed with header spoofing. DKIM alone does not prevent a spoofed visible From address. DMARC without SPF and DKIM has nothing to evaluate. The power is in all three working together.

Part 1

SPF — Sender Policy Framework

What is SPF?

SPF lets you publish a list of authorized mail servers for your domain as a DNS TXT record. When a receiving server gets an email claiming to be from you@yourdomain.com, it looks up the SPF record for yourdomain.com and checks whether the connecting IP address is on the authorized list. If it is, SPF passes. If it is not, SPF fails.

How SPF Works

SPF checks the envelope sender (also called the Return-Path or MAIL FROM address), which is set during the SMTP transaction and is separate from the visible From: header that recipients see. This distinction is important and is why SPF alone is not sufficient — a spoofed From: address with a legitimate envelope sender will still pass SPF.

SPF Record Syntax

An SPF record is a TXT record published at your root domain. It starts with v=spf1 and ends with an all mechanism that defines what to do with IPs not on the list:

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

The key mechanisms:

include:

Inherit the SPF record of another domain. Use this for ESPs like Google Workspace, SendGrid, Mailchimp, etc.

ip4: / ip6:

Explicitly authorize a specific IPv4 or IPv6 address or CIDR range.

a:

Authorize the IP addresses in the domain's A/AAAA records.

mx:

Authorize the domain's MX servers. Useful for servers that both receive and send mail.

-all

Hard fail — reject mail from IPs not on the list. The recommended ending for strict SPF.

~all

Soft fail — accept but mark mail from unauthorized IPs. A common starting point.

?all

Neutral — no policy. Effectively no SPF protection. Avoid.

SPF Setup: Step by Step

1. List every service that sends email from your domain. Include your own mail server, Google Workspace or Microsoft 365, any marketing platform (Mailchimp, SendGrid, HubSpot), CRM tools, helpdesk software — anything that sends email with your domain in the From address.

2. Build the record. Add an include: for each service that provides one, and an ip4: for any dedicated IP you control directly.

3. Publish as a TXT record at your root domain (not a subdomain).

4. Verify. Use a DNS lookup or an SPF validator to confirm the record resolves correctly and all your sending IPs pass.

# Verify your SPF record
dig TXT yourdomain.com | grep spf

# Test a specific IP against your SPF record
# (many online tools do this — search "SPF check")

The 10-Lookup Limit

SPF allows a maximum of 10 DNS lookups per evaluation. Each include:, a:, and mx: counts toward this limit. Exceeding it causes a permanent SPF failure (PermError) regardless of whether the sending IP is authorized. If you use many services, use an SPF flattening tool to stay within the limit.

Warning

You can only have one SPF TXT record per domain. Multiple records cause a PermError. If you have more than one, merge them into a single record.

Part 2

DKIM — DomainKeys Identified Mail

What is DKIM?

DKIM adds a cryptographic digital signature to the headers of every outgoing email. The signature is generated with a private key held by your mail server. The corresponding public key is published in DNS. Any receiving server can fetch the public key and verify that the signature is valid — proving two things:

The email was sent by a server that controls the signing domain.
The email was not modified after it left the signing server.

How DKIM Works

When your mail server sends a message, it computes a hash of selected headers and the message body, then encrypts that hash with your private key. The result is embedded in a DKIM-Signature: header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourdomain.com; s=mail; t=1743119400;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  h=From:To:Subject:Date;
  b=Base64EncodedSignatureHere...

The receiving server extracts the d= (domain) and s= (selector) values, fetches the public key from DNS at mail._domainkey.yourdomain.com, and verifies the signature. If it matches, DKIM passes.

DKIM DNS Record

The public key is published as a TXT record at selector._domainkey.yourdomain.com. The selector is a label that identifies which key pair is in use — useful when rotating keys or when multiple services sign with different keys:

mail._domainkey.yourdomain.com  IN  TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

DKIM Setup: Step by Step

Most email service providers (Google Workspace, Microsoft 365, SendGrid, etc.) handle key generation for you and provide a DNS record to publish. The process is:

Enable DKIM signing in your ESP or mail server settings.
Copy the TXT record value provided by the service.
Publish it in DNS at the selector._domainkey.yourdomain.com hostname they specify.
Wait for DNS propagation (minutes to hours), then verify using your provider's validation tool or a DKIM lookup.
Repeat for every service that sends email on your behalf.

Tip

Unlike SPF, you can have multiple DKIM records — one per selector, one per sending service. Each service signs with its own key, and you publish all of them in DNS simultaneously.

DKIM vs SPF: Key Differences

What it checksSPFSending IP addressDKIMMessage signature (header + body)

Survives forwardingSPFNo — forwarded IP breaks SPFDKIMUsually yes — signature travels with the message

DNS record locationSPFRoot domain TXT recordDKIMselector._domainkey subdomain TXT

Multiple records allowedSPFNo — only one per domainDKIMYes — one per selector/service

What it provesSPFAuthorized sending infrastructureDKIMMessage integrity and domain control

Part 3

DMARC — Domain-based Message Authentication, Reporting, and Conformance

What is DMARC?

DMARC is the policy layer that sits on top of SPF and DKIM. It answers two questions that neither protocol addresses on its own:

Alignment: Even if SPF and DKIM pass, does the authenticated domain match the visible From: address that recipients see? If not, the message is spoofed regardless of whether the underlying checks passed.
Policy: What should receiving servers do with messages that fail the alignment check — deliver, quarantine, or reject?

DMARC also introduces a reporting mechanism: aggregate XML reports that show every IP sending email that claims to be from your domain, along with SPF and DKIM pass/fail rates. These reports are invaluable for discovering unauthorized senders and missing authentication coverage.

For a full deep dive, see our dedicated article: What is DMARC? A Complete Guide to Configure It.

DMARC Record Syntax

Published as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

DMARC Policy Ladder

Always roll out DMARC in stages. Never jump straight to p=reject:

p=noneMonitor

Collect reports with zero impact on delivery. Start here, always.

p=quarantineEnforce (soft)

Failing messages go to spam. Use pct=10 to test on a percentage first.

p=rejectEnforce (full)

Failing messages are blocked. The goal state for every domain.

How SPF, DKIM, and DMARC Work Together

Here is what happens when a receiving mail server processes an inbound message from sender@yourdomain.com:

SPF check

The server looks up the SPF record for the envelope sender domain (Return-Path). It checks whether the connecting IP is authorized. Result: pass or fail.

DKIM check

The server finds the DKIM-Signature header, fetches the public key from DNS, and verifies the signature. Result: pass or fail.

DMARC alignment

The server checks the DMARC record. For DMARC to pass, at least one of SPF or DKIM must have passed AND the authenticated domain must align with the visible From: domain.

Policy applied

If DMARC alignment fails, the server applies the p= policy: none (deliver), quarantine (spam), or reject (block).

Report sent

Within 24 hours, the server sends an aggregate report to your rua= address listing this message and its result.

How to Verify SPF, DKIM, and DMARC Are Working

After publishing your DNS records, verify each protocol independently before enabling DMARC enforcement.

Verify SPF

# Lookup your SPF record
dig TXT yourdomain.com | grep spf

# Expected output (abbreviated)
yourdomain.com. TXT "v=spf1 include:_spf.google.com -all"

Verify DKIM

# Replace 'mail' with your selector
dig TXT mail._domainkey.yourdomain.com

# Expected output (abbreviated)
mail._domainkey.yourdomain.com. TXT "v=DKIM1; k=rsa; p=MIIBIj..."

To confirm signing is active end-to-end, send a test email to a Gmail address and view the original message. In the headers, look for Authentication-Results: — it will show whether SPF, DKIM, and DMARC passed or failed.

Verify DMARC

# Lookup your DMARC record
dig TXT _dmarc.yourdomain.com

# Expected output
_dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

Tip

The fastest all-in-one check is to send a test email to check-auth@verifier.port25.com — it replies with a full authentication report showing SPF, DKIM, and DMARC results for your message.

Common Mistakes Across All Three Protocols

Setting up DMARC before SPF and DKIM are passing — DMARC has nothing to align against and every message fails.
Publishing multiple SPF records — only one is allowed; multiple records cause a PermError.
Exceeding 10 DNS lookups in SPF — use SPF flattening for domains with many sending services.
Using strict DKIM or SPF alignment in DMARC (adkim=s or aspf=s) without verifying exact domain matching — breaks legitimate mail from subdomains.
Jumping to p=reject without analyzing p=none reports first — likely to block your own email.
Forgetting to add DKIM for third-party senders — each ESP needs its own DKIM selector published.
Not setting a rua= address in DMARC — you cannot monitor what you are not reporting on.
Using only SPF and skipping DKIM — SPF breaks on forwarded messages, leaving DMARC with no passing signal.

Google and Yahoo Sender Requirements

Since February 2024, Google and Yahoo have enforced authentication requirements for bulk senders (those sending more than 5,000 emails per day to Gmail or Yahoo addresses):

SPF or DKIM: At least one must be configured and passing. Both is strongly recommended.

DMARC: A DMARC record must be present. p=none is sufficient to satisfy the requirement, but p=reject is the long-term goal.

Valid From: domain: The From: domain must match the DKIM signing domain or SPF-authenticated domain.

One-click unsubscribe: List-Unsubscribe and List-Unsubscribe-Post headers must be present in marketing email.

Spam rate < 0.3%: Google Postmaster Tools must not show your domain's spam rate above 0.3% for sustained periods.

Note

These requirements apply to bulk senders (>5,000 emails/day). For lower-volume senders, authentication is still strongly recommended — it directly impacts inbox placement and sender reputation regardless of volume.

Frequently Asked Questions

What is the difference between SPF, DKIM, and DMARC?

SPF authorizes which IPs can send for your domain. DKIM adds a cryptographic signature to prove message integrity. DMARC enforces alignment between SPF/DKIM and the visible From address, applies a policy for failures, and provides reporting.

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

Yes, ideally. All three working together provide complete authentication coverage. SPF and DKIM each cover weaknesses in the other, and DMARC is what prevents domain spoofing and provides visibility.

In what order should I set up SPF, DKIM, and DMARC?

SPF first, then DKIM, then DMARC in monitoring mode (p=none). Verify SPF and DKIM are passing before enabling any DMARC enforcement.

Can I have multiple SPF records?

No. Only one SPF TXT record is allowed per domain. Multiple records cause a permanent SPF failure. Combine all your sending services into a single record.

Does DKIM survive email forwarding?

Usually yes. DKIM signatures travel with the message headers and survive most forwarding scenarios. SPF, by contrast, breaks on forwarding because the forwarding server's IP is not in the original SPF record. This is why having both SPF and DKIM is important for DMARC alignment.

Summary

SPF, DKIM, and DMARC are not optional extras — they are the baseline infrastructure of trustworthy email. SPF declares who can send for your domain, DKIM proves each message is genuine, and DMARC enforces alignment between the two while giving you visibility into everything sent under your domain name.

Set them up in order: SPF and DKIM first (verify both pass), then DMARC at p=none to collect reports, then graduate to p=reject once your reports show near-100% pass rates. The goal state — p=reject with both SPF and DKIM passing — is achievable for any domain, and it is the single most effective thing you can do to protect your brand from email-based spoofing and phishing.