SPF, DKIM and DMARC: how email authentication works together

SPF, DKIM and DMARC work together as one system: SPF verifies that a message came from a server authorised by the return-path domain, DKIM verifies a cryptographic signature applied by the signing domain, and DMARC ties both results back to the From address the recipient actually sees, then tells receivers what to do when neither check aligns and reports the results back to you.

Why does email need three separate protocols?

The underlying problem is that Simple Mail Transfer Protocol (SMTP), the protocol that moves email between servers, was designed without any built-in way to verify who sent a message. Any server can connect to any other server and claim to be sending on behalf of any domain. The address shown in the recipient's mail client, the RFC5322.From header, is just a text field.

SPF and DKIM were developed to close parts of that gap, but each validates something slightly different, and crucially, neither of them validates the visible From address on its own. DMARC was introduced (standardised in RFC 7489) to connect the two earlier checks to the From header, add a published policy, and create a feedback loop so domain owners can see what is happening.

A useful way to hold the whole picture in your head:

• SPF answers: is this server allowed to send mail using this return-path domain?
• DKIM answers: was this message signed by a domain, and has it survived transit unmodified?
• DMARC answers: does either of those verified domains match the From address the recipient sees, and if not, what should the receiver do about it?

What does SPF actually check?

Sender Policy Framework (SPF, RFC 7208) is an IP allow list published in DNS. The domain owner publishes a TXT record listing the servers permitted to send mail for the domain, for example:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.25 -all"

When a receiving server accepts a connection, it looks at the domain in the RFC5321.MailFrom address, also called the envelope from or Return-Path, fetches that domain's SPF record, and checks whether the connecting IP address is authorised. The result is pass, fail, softfail, neutral, or one of the error states.

The important subtlety is which address SPF checks. It is the envelope from, not the visible From header. Those two addresses are often different, and legitimately so: bulk mail providers routinely set the envelope from to their own bounce-handling domain. That is exactly the gap DMARC alignment exists to close. For the full detail on mechanisms, qualifiers and the lookup limit, see our guide to SPF.

SPF's main weakness is fragility in transit. When a message is forwarded, the forwarding server becomes the new sending IP, and that IP is almost never in the original domain's SPF record, so SPF fails even though the message is genuine.

What does DKIM actually check?

DomainKeys Identified Mail (DKIM, RFC 6376) takes a different approach: instead of validating the sending server, it validates the message itself. The sending system computes a cryptographic signature over selected headers and a hash of the body, and attaches it in a DKIM-Signature header. The signature names the signing domain in its d= tag and a selector in its s= tag, which together tell the receiver where in DNS to find the public key:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
  h=from:to:subject:date; bh=...; b=...

The receiver fetches the public key from mail2026._domainkey.example.com, verifies the signature, and recomputes the body hash. If everything matches, DKIM passes and the receiver knows two things: the message was signed by someone holding the private key for that domain, and the signed content has not been altered since signing.

Because the signature travels with the message rather than depending on the sending IP, DKIM usually survives forwarding. It breaks instead when content is modified in transit, for example when a mailing list adds a footer or rewrites the subject line. Our DKIM guide covers keys, selectors and signing in more depth.

Like SPF, DKIM has a blind spot: nothing requires the signing domain to have any relationship with the From address. An attacker can send a message with a From header of accounts@example.com, signed perfectly validly by d=attacker-domain.com. DKIM passes. The check is real, but it is verifying the wrong thing from the recipient's point of view.

What does DMARC add on top?

Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) supplies the three pieces SPF and DKIM lack: alignment, policy and reporting. A domain publishes its DMARC record at _dmarc.example.com:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:reports@example.com"

Alignment: tying the checks to the From address

DMARC's core idea is that a raw SPF or DKIM pass is not enough; the domain that passed must match the domain in the visible From header. This is called alignment:

• SPF alignment: the envelope-from domain that produced the SPF pass must match the From header domain.
• DKIM alignment: the d= domain of a passing DKIM signature must match the From header domain.

By default alignment is relaxed, meaning the organisational domains must match, so mail.example.com aligns with example.com. Strict alignment requires an exact match. DMARC passes when at least one of the two checks both passes and aligns; it does not need both. This is why a message can show SPF pass and DKIM pass yet still fail DMARC: both passed for domains unrelated to the From address. The mechanics are covered in detail in our alignment guide.

Policy: what receivers should do on failure

The p= tag states the domain owner's request for messages that fail DMARC: none (deliver normally, monitoring only), quarantine (treat with suspicion, typically the spam folder) or reject (refuse the message). Note that this is a request, not a command; receivers may apply local overrides, for instance for known mailing lists. Choosing between the three is its own decision, covered in our policy comparison.

Reporting: the feedback loop

The rua tag asks receivers to send aggregate reports, XML summaries of every message they saw claiming to be from your domain, with source IPs, message counts and authentication results. This is the only standard mechanism that shows a domain owner what is being sent in their name across the internet, including sources they had forgotten about and spoofing they never knew existed. Reading them well takes some practice; our reports guide walks through the format.

A worked example: one message, evaluated end to end

Suppose example.com uses a hosted mailbox provider for day-to-day mail and a marketing platform for newsletters, and publishes:

example.com.         TXT  "v=spf1 include:_spf.mailhost.example include:_spf.marketing.example -all"
mail2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

A newsletter goes out through the marketing platform. A receiving server sees:

• Connecting IP: 198.51.100.40 (the marketing platform's server)
• Envelope from: bounces@em.marketing.example (the platform's bounce domain)
• From header: news@example.com
• A DKIM signature with d=example.com; s=mail2026, added because the platform was set up with a key for the customer's own domain

The receiver now evaluates, step by step:

1. SPF. The envelope-from domain is em.marketing.example, so the receiver fetches that domain's SPF record. The connecting IP is listed, so SPF passes, for em.marketing.example.
2. DKIM. The receiver fetches the public key at mail2026._domainkey.example.com, verifies the signature and body hash. DKIM passes, for d=example.com.
3. DMARC alignment. The From header domain is example.com. SPF passed, but for em.marketing.example, which does not share an organisational domain with example.com, so SPF is not aligned. DKIM passed for d=example.com, which matches exactly, so DKIM is aligned.
4. DMARC result. One aligned pass is enough. DMARC passes, and the p=quarantine policy is never invoked. The message is delivered normally.
5. Reporting. The receiver records the result and, in its next aggregate report to dmarc@example.com, includes a row for IP 198.51.100.40 showing SPF pass (unaligned), DKIM pass (aligned), DMARC pass.

Now run the counterfactual. If the marketing platform had not been configured to sign with the customer's domain and instead signed with d=marketing.example, both SPF and DKIM would still pass in the raw sense, but neither would align with example.com. DMARC would fail, and under p=quarantine the newsletter would likely land in spam. Nothing about the message changed except the one thing DMARC cares about: whether a verified identity matches the From address.

Finally, consider a genuine spoof: an attacker's server sends mail with a From header of finance@example.com. SPF fails or passes only for the attacker's own envelope domain, and the attacker cannot produce a signature with d=example.com because they do not hold the private key. No aligned pass exists, DMARC fails, and the published policy applies.

Why do you need all three?

Each protocol on its own leaves an exploitable or operational gap, and each covers a weakness in the others:

Check	Verifies	Weakness on its own	Covered by
SPF	Sending IP is authorised for the envelope-from domain	Ignores the visible From address; breaks on forwarding	DMARC alignment; DKIM surviving forwards
DKIM	Message signed by a domain and unmodified	Ignores the visible From address; breaks on content modification	DMARC alignment; SPF surviving modification
DMARC	An authenticated domain matches the From header; states policy; reports	Does nothing without SPF or DKIM underneath	SPF and DKIM providing the raw results

The forwarding case shows the redundancy at work: a forwarded message usually fails SPF because the forwarder's IP is not authorised, but the DKIM signature normally survives intact, so DMARC still passes on the aligned DKIM result. Deploying SPF and DKIM together, then binding them with DMARC, is what makes the system resilient rather than brittle.

Where should you start?

The practical deployment order follows the dependency chain. First, make sure SPF and DKIM are correctly configured for every legitimate source of mail for your domain, including third-party platforms, and that at least one of them can align for each source. Then publish a DMARC record at p=none with a rua address, which changes nothing about delivery but starts the flow of aggregate reports.

Spend the monitoring phase identifying every sender in the reports and fixing alignment where it is missing, then tighten the policy to quarantine and eventually reject once the data shows legitimate mail passing consistently. Aggregate reports arrive as XML files, one per receiver per day, which quickly becomes unmanageable to read by hand; a DMARC monitoring service such as DMARCHub turns them into readable dashboards so you can see aligned and failing sources at a glance (see /features).

Frequently asked questions

Does DMARC require both SPF and DKIM to pass?

No. DMARC passes when at least one of the two produces an aligned pass. In practice you should deploy both wherever you can, because they fail in different situations: forwarding tends to break SPF while DKIM survives, and content modification tends to break DKIM while SPF survives. Relying on only one leaves ordinary mail flows exposed to avoidable failures.

Can I use DMARC with only SPF and no DKIM?

Technically yes; DMARC will evaluate whatever results exist. But an SPF-only deployment is fragile, because every forwarded message will fail DMARC outright, and some receivers weight DKIM heavily in their filtering. If your mail platform supports DKIM signing with your own domain, and almost all modern platforms do, enable it before moving beyond a monitoring policy.

In what order are SPF, DKIM and DMARC checked?

SPF can be evaluated as soon as the receiver knows the connecting IP and envelope from, early in the SMTP conversation. DKIM requires the full message, since the signature covers headers and body. DMARC is computed last, because it consumes the SPF and DKIM results and compares their domains against the From header. Receivers then record the outcome for their aggregate reports.

If a message passes SPF, DKIM and DMARC, is it definitely safe?

No. Authentication proves the message genuinely relates to the domain it claims, not that the domain or its content is trustworthy. Attackers register their own domains, authenticate them perfectly, and rely on lookalike domains or display names to deceive. DMARC removes exact-domain spoofing from the attacker's toolkit; spam and phishing filtering remain separate layers.