SPF, DKIM, and DMARC Explained: How They Work Together

Last updated: June 10, 2026

If you have ever wondered why email is so easy to spoof, the answer is older than most internet protocols. SMTP, the protocol that moves email between servers, was designed in 1981 with no built-in sender verification. Anyone can send a message claiming to be from any address. The infrastructure trusts the claim.

SPF, DKIM, and DMARC are three protocols layered on top of SMTP to fix this. They live in DNS, run automatically, and together prove that an email came from the domain it claims. This guide explains each protocol and how they work together. It covers what to set up first, and the 2024 to 2026 enforcement changes that made all three mandatory.

The Three-Layer Problem Email Authentication Solves

SMTP was designed without sender verification, so anyone can claim to send mail from any domain. SPF, DKIM, and DMARC each solve part of this problem. SPF checks the sending server. DKIM verifies the message content. DMARC ties them to the visible From address.

Picture the classic email scam. A message arrives claiming to be from your bank. The visible From address looks legitimate. The branding is right. The link is not. The attacker did not break into your bank’s servers. They just sent a message that lied about who sent it.

That works because SMTP has no concept of sender identity. The protocol accepts whatever the sending server claims. There is no driver’s license check, no notary stamp, no return address verification. Until recently, no receiving server could confirm that mail claiming to be from your-bank.com actually came from your-bank.com.

Each of the three modern authentication protocols closes part of this gap. SPF answers “is the sending server authorized to send for this domain?” DKIM answers “did this message arrive intact and from an authorized signer?” DMARC answers “does the visible From address match the domain that just authenticated?” Together they make spoofing detectable.

SPF: Who’s Allowed to Send Mail for Your Domain

SPF (Sender Policy Framework) is a DNS TXT record listing the IP addresses authorized to send mail for your domain. Receiving servers check this list when a message arrives. If the sending IP is not on the list, the SPF check fails.

SPF is the oldest of the three protocols and the simplest. Defined in RFC 7208, it works as a DNS-published whitelist of authorized sending sources. You publish one TXT record at your domain root. Every receiving mail server can read it.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:mailgun.org ip4:198.51.100.10 -all

Reading it piece by piece. v=spf1 declares the SPF version. The include: mechanisms point to other SPF records (Google Workspace, Mailgun) whose authorized senders should be merged into yours. The ip4: mechanism adds a specific server IP. The -all at the end says reject everything else.

What SPF Actually Checks

When mail arrives, the receiving server reads the Return-Path header (also called MailFrom or envelope-from). It extracts the domain. It looks up that domain’s SPF record. Then it compares the connecting server’s IP against the authorized list. If the IP matches, SPF passes. If not, SPF fails.

The critical detail is that SPF checks the Return-Path domain, not the visible From address. This is the limitation DMARC was built to address. An attacker can pass SPF using their own domain in the Return-Path while displaying your domain in From.

The 10-Lookup Limit

SPF has a hard technical limit. The protocol can perform a maximum of 10 DNS lookups while evaluating a record. Every include:, a:, mx:, ptr:, and exists: mechanism counts. Records that exceed 10 lookups fail with a permerror status, which most receivers treat as an SPF failure.

This is one of the most common operational pitfalls. A domain adds Google Workspace, then Mailgun, then HubSpot, then a CRM, and suddenly hits the limit. The fix is SPF flattening, which resolves nested includes into direct IP entries. Verify your current state with our SPF Record Lookup tool.

DKIM: Did This Message Actually Come from That Domain

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outbound message. Your DNS publishes the matching public key. Receiving servers verify the signature. A valid signature proves the message was not altered and came from an authorized signing server.

DKIM, defined in RFC 6376, uses public-key cryptography. Your mail server holds a private key. The corresponding public key lives in a DNS TXT record. When the mail server sends a message, it computes a cryptographic hash of selected headers and the body. The server then signs that hash with the private key.

The signature travels with the message in a DKIM-Signature header that looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
  h=From:To:Subject:Date;
  bh=base64-encoded-body-hash;
  b=base64-encoded-signature-bytes

The receiving server reads the d= field to find the signing domain. It reads the s= field to find the selector. Then it queries DNS for the public key at selector._domainkey.example.com. It uses that key to verify the signature.

What a Valid Signature Actually Proves

A DKIM pass proves two things. First, the message was not altered between the signing server and the recipient. Second, whoever signed it had access to the private key associated with the published public key. That is strong evidence the message came from infrastructure authorized to sign for the signing domain.

What DKIM does not check is whether the signing domain matches the visible From address. A spammer can sign a message with their own DKIM key for their own domain. They can then write your domain in the From header. The DKIM check passes because the signature is mathematically valid for the signing domain. But the recipient still sees your domain. This is the gap DMARC closes.

Key Length and Rotation

DKIM keys are RSA by default. The 2026 standard is 2048-bit RSA with rsa-sha256 signing. RFC 8301 still permits 1024-bit keys, but treat them as a legacy fallback only. Keys should be rotated periodically. Many mail providers handle rotation automatically, but on self-hosted infrastructure it is a manual task.

Ed25519 keys (RFC 8463) are shorter and faster than RSA. Receiver support is still incomplete, though. Microsoft 365 and Yahoo do not verify Ed25519 signatures yet. Teams adopting it should dual-sign with both RSA and Ed25519 selectors.

DMARC: What to Do When SPF or DKIM Fails (Plus Reporting)

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers what to do when SPF or DKIM fails. It also requires the authenticated domain to align with the visible From address. DMARC adds policy enforcement and reporting on top of SPF and DKIM.

DMARC first appeared in 2015 as RFC 7489 to address the gaps in SPF and DKIM. It does two things neither of those protocols does individually. It enforces alignment between the authenticated domain and the visible From address. And it provides aggregate reporting so domain owners can see what is happening at the receiver level.

A DMARC record is a DNS TXT record at _dmarc.example.com. A typical one looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; fo=1

Each tag does specific work. v=DMARC1 declares the version. p=quarantine sets the policy. rua= tells receivers where to send aggregate reports. fo=1 requests failure reports for any auth failure. The older pct= tag is deprecated under RFC 9989. Use the new t=y testing flag instead when you need a trial mode.

The Three Policy Values

DMARC defines three policy values. p=none means take no action on failing mail. Just send reports. p=quarantine means send failing mail to the spam folder. p=reject means refuse delivery entirely.

The progression matters. Going straight to p=reject on a new deployment is risky. Legitimate mail can fail authentication for many reasons you have not discovered yet. The sane path is p=none for monitoring. Move to p=quarantine once reports show your mail is consistently passing. Move to p=reject after another clean monitoring window.

Aggregate Reports Are the Operational Value

The rua= tag is the most under-appreciated part of DMARC. It tells receiving mail providers to send daily reports. The reports list every IP that sent mail claiming to be from your domain. The reports come as XML attachments. Receivers like Google, Yahoo, and Microsoft all participate.

These reports show who is sending from your domain. Including the legitimate third parties you forgot about. Your CRM, your marketing automation platform, your help-desk system. They also show spoofing attempts. Reading aggregate reports is what turns DMARC from a checkbox into actual visibility into your sending ecosystem.

How the Three Work Together (Alignment Explained)

SPF and DKIM each authenticate part of the message. Neither checks the visible From address. DMARC adds alignment, requiring the SPF or DKIM domain to match the From domain. Only the combination prevents spoofing where attackers manipulate the visible sender.

The clearest way to see why all three matter is to compare what each one actually validates.

Protocol	What it checks	What it protects against	What it does NOT do
SPF	Whether the sending IP is on the authorized list for the Return-Path domain	Random servers sending mail claiming to be from your Return-Path	Verify the visible From address. Survive forwarding.
DKIM	Whether the message was signed by a server holding the private key for the signing domain	Message tampering in transit. Unauthorized signing.	Verify the visible From address. Detect a spammer signing with their own key.
DMARC	Whether SPF or DKIM passes AND the authenticated domain aligns with the visible From address	Spoofing of your visible From address. Provides reporting visibility.	Anything if SPF and DKIM are not also set up. DMARC depends on both.

Alignment is the load-bearing concept. DMARC defines two alignment modes. Strict alignment requires an exact domain match. Relaxed alignment (the default) requires an organizational domain match, which permits subdomains. Most domains use relaxed alignment because subdomains for marketing, transactional, and other purposes are common.

RFC 9989 also changes how receivers find the organizational domain. They now perform a DNS Tree Walk instead of consulting the Public Suffix List. The change removes a third-party dependency and improves accuracy for complex domain structures.

Without alignment, an attacker could publish their own SPF and DKIM records for attacker.example. They could send a message from a server authorized by those records, but display your-domain.com in the From header. Both SPF and DKIM would pass for the attacker’s domain. DMARC catches this because the attacker’s domain does not align with the From domain.

The 2024-2026 Mandatory Enforcement Reality

Since February 2024, Google and Yahoo require SPF, DKIM, and DMARC. The rule applies to any domain sending more than 5,000 messages a day to their addresses. Microsoft added the same requirement in May 2025. Non-compliant mail now faces temporary or permanent rejection.

Email authentication used to be a best practice. It is now a requirement to deliver mail at any meaningful volume.

Google and Yahoo jointly announced bulk sender requirements on October 3, 2023. Enforcement began February 1, 2024, with temporary 4xx error codes on a small percentage of non-compliant traffic. By April 2024, Gmail was permanently rejecting non-compliant mail with 5xx codes. In November 2025, Gmail tightened enforcement further. Non-compliant emails now face temporary or permanent rejections rather than just temporary warnings.

Microsoft followed on April 2, 2025. The original plan was to route non-compliant mail to the junk folder. By April 29, Microsoft hardened the policy to outright SMTP rejection. Enforcement took effect May 5, 2025.

The Specific Requirements

For domains sending more than 5,000 messages a day to Gmail, Yahoo, or Outlook addresses, all three providers now require:

• SPF authentication with the sending IP authorized for the Return-Path domain
• DKIM signing with a key of at least 1024 bits (Yahoo) or 2048 bits (Google strongly recommends)
• DMARC record published with a minimum policy of p=none
• DMARC alignment passing between the SPF or DKIM domain and the visible From address
• Spam complaint rate below 0.10% as the working target — never reaching the 0.30% threshold Google treats as a violation
• RFC 8058 one-click unsubscribe implemented via the List-Unsubscribe header (required for Google and Yahoo, recommended for Microsoft)

The 5,000-per-day threshold is per-domain, including subdomains. It also includes mail sent on your behalf by third-party platforms. Examples are marketing automation, CRMs, and transactional email services. Once a domain exceeds the threshold at Gmail, the bulk-sender classification is permanent. You do not drop back to non-bulk status if your volume falls.

Even below the threshold, all senders are now expected to have at least SPF or DKIM configured. Domains that send any mail to Gmail or Yahoo without either are increasingly filtered.

A Sane Rollout Order (and Timeline)

Roll out in three stages. Set up SPF first, then DKIM, then DMARC at p=none. Monitor aggregate reports for two to four weeks. Move to p=quarantine when reports are clean. Move to p=reject after another clean monitoring window.

The sequence is not arbitrary. DMARC requires SPF or DKIM to be working before it can do anything useful. Rushing to p=reject before SPF and DKIM are solid bounces your own legitimate mail. This is the most common DMARC deployment mistake.

Stage 1: SPF

Start with SPF. Inventory every system that sends mail on behalf of your domain. Your primary mail provider (Google Workspace, Microsoft 365, or self-hosted). Every third-party sender: marketing automation, transactional email, support desk, CRM, monitoring alerts. Build a single SPF record that authorizes all of them.

Watch the 10-lookup limit. If you are already past it, use SPF flattening to consolidate. Verify the record using a tool like our SPF Record Lookup. You can also send a test message and inspect the Authentication-Results header at the recipient.

Stage 2: DKIM

Configure DKIM at every system identified in Stage 1. Each system signs with its own key and selector. Your DNS publishes the public key for each selector. Most managed email providers handle key generation and DNS publication automatically. Self-hosted infrastructure requires manual setup.

Wait one to three days after DKIM is configured. Test by sending mail to a Gmail or Outlook account you control. Look at the message source for the DKIM-Signature header and a dkim=pass result in the Authentication-Results header.

Stage 3: DMARC, Phased

Publish a DMARC record with p=none and a valid rua= address. Use a dedicated mailbox or a DMARC reporting service. Aggregate reports will arrive within 24 hours. Read them.

Run at p=none for two to four weeks. Look for any sending source you did not expect. Confirm every legitimate source is passing SPF or DKIM with alignment. Fix any gaps. Move to p=quarantine only when reports show consistent pass rates above 95%. Move to p=reject after another two to four weeks at quarantine with clean reports. Use our SPF/DMARC Generator to build compliant records for each stage.

Common Mistakes That Break Email

Several common mistakes break legitimate email flow. Going straight to p=reject without monitoring. Forgetting third-party senders like marketing platforms and CRMs. Misaligned domains between Return-Path and From. SPF records that exceed the 10 DNS lookup limit.

Most email authentication disasters are predictable. The patterns repeat across organizations.

Going Straight to p=reject

The fastest way to bounce your own legitimate mail is to skip the p=none monitoring window. Without aggregate reports, you do not know which legitimate senders are failing alignment. The first you hear about it is bad news. Sales notices nobody is replying to their cold email. Or marketing notices the open rate cratered.

Forgetting Third-Party Senders

Marketing automation platforms. Transactional email services like Postmark or SendGrid. Help-desk tools. Survey platforms. Webinar systems. Each one sends mail with your From address. Each one needs SPF authorization or its own DKIM signing setup with alignment. Aggregate reports during the p=none window catch these. Skipping the window misses them.

Misalignment Between Return-Path and From

This is the alignment problem playing out in production. A marketing platform sends with Return-Path set to bounce.platform.example while From is marketing@your-domain.com. SPF passes for platform.example. But the domains do not align. DMARC fails.

The fix is usually one of two options. Configure the platform to use a custom Return-Path domain that is a subdomain of yours. Or rely on DKIM, which the platform can sign with your domain instead.

SPF Past the 10-Lookup Limit

A few mature SaaS stacks naturally push past 10 lookups. The symptom is intermittent SPF failures and a permerror result in Authentication-Results. The fix is SPF flattening. This replaces include: mechanisms with their resolved IP addresses. A managed flattening service usually maintains the record and updates as upstream IPs change.

How to Verify Your Setup Is Working

Verify your setup three ways. Send a test message to an account you control and inspect the Authentication-Results header. Use NetworkCheckr’s free Email Auth Checker for a domain-level audit. Review DMARC aggregate reports weekly to catch issues before they become deliverability problems.

Authentication does not declare itself fixed. You confirm it by inspecting actual delivered mail and by monitoring the reports your DMARC record generates.

Reading the Authentication-Results Header

Send a test message from your domain to a Gmail or Outlook account you control. Open the message and view the full source. In Gmail this is the “Show original” option. Look for a line that begins with Authentication-Results:. It looks something like this:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of bounce@example.com designates 198.51.100.10 as permitted sender) smtp.mailfrom=bounce@example.com;
  dkim=pass header.i=@example.com header.s=selector1 header.b=abc123;
  dmarc=pass (p=quarantine sp=quarantine dis=none) header.from=example.com

Three results matter. spf=pass means the sending server was authorized. dkim=pass means the signature verified. dmarc=pass means at least one of those passed AND aligned with the From domain. If any line says fail, the message has an authentication problem. Use our Email Auth Checker to audit your domain’s SPF, DKIM, and DMARC configuration in a single query.

Reading Aggregate Reports

Aggregate reports arrive as XML attachments to the address in your rua= tag. Reading raw XML is painful. Most teams use a free service like dmarcian to parse the reports into dashboards. Paid platforms like Valimail and Red Sift offer richer analysis.

Review reports weekly during rollout. Watch for sending IPs you do not recognize. Investigate any consistent SPF or DKIM failures. Track the percentage of mail passing DMARC. The number should climb toward 100% as you fix gaps.

Related Tools & Resources

NetworkCheckr provides three tools that pair with this article. The Email Auth Checker audits your domain’s SPF, DKIM, and DMARC posture in one query. The SPF/DMARC Generator builds compliant records. The SPF Record Lookup verifies your current SPF deployment in real time.

• Email Auth Checker — check SPF, DKIM, and DMARC for any domain in a single query.
• SPF/DMARC Generator — build compliant SPF and DMARC records for your domain.
• SPF Record Lookup — verify the current SPF record for any domain and count its DNS lookups.
• MX Lookup — check the mail exchange records that route inbound mail.
• TXT Record Lookup — query any TXT record, including DKIM selectors.
• DNS Propagation Checker — track DNS changes after publishing SPF, DKIM, or DMARC updates.
• How Long Does DNS Propagation Take? — understand the timing when changes are not yet visible.
• All NetworkCheckr Tools — the full set of free browser-based networking utilities.

Frequently Asked Questions

Seven questions cover the practical edge cases in SPF, DKIM, and DMARC deployment. Whether you need all three. Which order to deploy. What the DMARC policy values mean. Whether DMARC requires both protocols. Common spam-folder causes. Alignment. And what changed with DMARCbis.