DMARC Pass vs. SPF Pass vs. DKIM Pass: Why They Aren’t the Same Thing

A team publishes an SPF record, sets up DKIM signing through their email provider, and runs a quick DNS lookup. Every check comes back green: SPF valid, DKIM present, DMARC published. They ship the configuration, move on, and assume email authentication is handled.

Weeks later, legitimate transactional emails are landing in spam. Aggregate DMARC reports show failures they did not expect. A spoofed message appears in a customer inbox using their visible brand domain, even though SPF and DKIM both “passed” somewhere in the chain. The team is confused because every tool they checked said “pass.”

The problem is that SPF pass, DKIM pass, and DMARC pass are not the same thing. They answer different questions, check different domains, and protect against different attack surfaces. The missing concept that ties them together is alignment— and without it, “pass” in one column does not mean your domain is protected.

If you want to check your own domain right now, the CodeAva DMARC / SPF / DKIM Analyzer inspects your DNS records, flags alignment risks, and parses raw DMARC aggregate reports into plain English — all locally in your browser.

Why these three “passes” are not the same thing

Each protocol answers a fundamentally different question:

• SPF answers: Was this sending IP authorized to send mail for the envelope sender domain?
• DKIM answers: Did the signed headers and body validate against the signing domain’s public key in DNS?
• DMARC answers: Does the domain authenticated by SPF or DKIM align with the visible Fromdomain — and what policy should the receiver apply when it does not?

SPF and DKIM are authentication mechanisms. They prove that a specific domain authorized the sending server or signed the message. DMARC is an alignment and policy layer. It ties those authentication results back to the domain the recipient actually sees, and tells the receiving server what to do when alignment fails.

This distinction is the source of nearly every “but it says pass” debugging headache in email operations.

SPF, DKIM, and DMARC in plain English

SPF — the sending permission check

SPF is a DNS TXT record published on the envelope senderdomain (the Return-Path domain). It lists the IP addresses, netblocks, and included domains authorized to send mail for that domain.

When a receiving server gets a message, it checks the sending IP against the SPF record of the Return-Path domain. If the IP is listed, SPF passes.

What SPF does not do: SPF does not verify the visible From address. The Return-Path and the From header can belong to completely different domains. SPF can pass for one domain while the recipient sees a different domain in their inbox.

DKIM — the message integrity signature

DKIM adds a cryptographic signature to outgoing messages. The sending server signs selected headers and the message body using a private key, then publishes the corresponding public key in DNS under a selector record.

When the receiving server gets the message, it retrieves the public key from DNS and verifies the signature. If the signed content has not been altered, DKIM passes.

What DKIM does not do: DKIM proves message integrity and that a particular domain signed the message. It does not prove the signing domain is the same as the visible From domain. A third-party service can sign with its own domain, pass DKIM, and still not align with the sender the recipient sees.

DMARC — the alignment and policy layer

DMARC is published as a DNS TXT record on the visible From domain (at _dmarc.example.com). It does two things:

1. Alignment check: it requires that the domain validated by SPF (the Return-Path domain) or the domain validated by DKIM (the d= signing domain) matches the visible From domain.
2. Policy instruction:it tells receivers what to do when alignment fails — none (monitor), quarantine (spam folder), or reject (drop the message).

DMARC also directs aggregate and forensic reports back to the domain owner via rua and ruf tags, giving visibility into who is sending mail as the domain and whether those senders are aligned.

The core concept: authentication vs. alignment

This is the highest-value distinction in email authentication, and it is where most teams get tripped up.

There are three domain fields that matter:

• Return-Path(envelope sender / MAIL FROM) — the domain SPF checks.
• DKIM signing domain (d=value) — the domain DKIM checks.
• Visible From header— the address the recipient sees in their inbox. This is the domain DMARC cares about.

Authentication means SPF or DKIM validated successfully for some domain. Alignment means the authenticated domain matches the visible From domain.

A simple header example

Consider a SaaS vendor sending billing notifications on your behalf:

Return-Path: [email protected]
From: [email protected]
DKIM-Signature: ... d=vendor-example.com; s=sel1; ...

• SPF checks mail.vendor-example.com— the Return-Path domain. If the sending IP is listed in that domain’s SPF record, SPF passes.
• DKIM checks vendor-example.com — the d= signing domain. If the signature validates, DKIM passes.
• DMARC checks alignment against yourcompany.com— the visible From domain. Neither vendor-example.com nor mail.vendor-example.com aligns with yourcompany.com, so DMARC fails.

Relaxed vs. strict alignment

DMARC supports two alignment modes. Relaxed(the default) requires the organizational domains to match — mail.example.com aligns with example.com. Strict requires an exact domain match. Most deployments use relaxed alignment, which is sufficient for the vast majority of configurations. Strict alignment is sometimes used by organizations with complex subdomain structures where tighter control is needed.

Why messages still land in spam even when SPF or DKIM passes

Teams often expect that authentication pass signals guarantee inbox placement. They do not. Here is why messages can still end up in spam even with green checks on some columns:

1. DMARC fails on alignment. SPF or DKIM may pass for a domain that does not align with the visible From. With a DMARC policy of quarantine or reject, the message is downgraded or dropped.
2. DMARC policy is too weak or missing. A policy of p=none tells receivers to take no action on failures. This means unauthenticated messages are delivered normally, and authenticated ones get no enforcement benefit.
3. Forwarding breaks SPF.When a message is forwarded, the forwarding server’s IP is not in the original sender’s SPF record. SPF fails for forwarded messages. If DKIM is not present or also fails, the message has no passing authentication that aligns.
4. Third-party senders are not aligned. Marketing platforms, CRMs, support desks, and transactional services often send using their own envelope and signing domains. Unless configured with a custom MAIL FROM and aligned DKIM, they fail DMARC alignment even though their own SPF and DKIM pass.
5. Reputation and content still matter. Even with perfect authentication and alignment, mailbox providers also evaluate sender reputation, complaint rates, list hygiene, and content signals. Authentication is a prerequisite, not a guarantee.

The DMARC report nightmare

When a domain publishes a DMARC record with a ruatag, mail receivers like Google, Microsoft, Yahoo, and others begin sending aggregate reports. These reports arrive as XML files — often gzip-compressed — to the address specified in the tag.

The raw format is not designed for human consumption:

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>1847</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourcompany.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>mail.vendor-example.com</domain>
      <result>pass</result>
    </spf>
    <dkim>
      <domain>vendor-example.com</domain>
      <result>pass</result>
    </dkim>
  </auth_results>
</record>

This snippet shows a pattern that confuses many teams: SPF result is pass, DKIM result is pass, but DMARC evaluation shows dkim>fail. Why? Because the authenticated domains (mail.vendor-example.com and vendor-example.com) do not align with the header_from domain (yourcompany.com). Authentication passed. Alignment failed.

Multiply this across dozens of sending sources, thousands of messages, and multiple reporting providers, and the XML quickly becomes unreadable.

The CodeAva DMARC / SPF / DKIM Analyzer parses these reports locally in your browser. Drop an .xml or .gz file and the tool decompresses and translates each record into a plain-English summary: which IPs are sending as your domain, whether they pass alignment, and what the DMARC disposition was. Source IPs are grouped with alignment diagnoses and can be exported as CSV.

How to reach p=reject safely

Moving to strict DMARC enforcement protects your domain from spoofing, but premature enforcement breaks legitimate email. Here is a pragmatic rollout path:

1. Publish DMARC with p=none. This enables monitoring without affecting delivery. Include a rua tag so you receive aggregate reports.
2. Collect and review reports for 2–4 weeks. Identify every source IP sending mail as your domain. Legitimate senders include your email provider, marketing platform, CRM, support desk, and transactional services.
3. Fix alignment for legitimate senders.Configure a custom MAIL FROM (custom Return-Path) on each platform so SPF aligns. Set up aligned DKIM signing (using your domain, not the vendor’s) where the platform supports it.
4. Move to p=quarantine. Failed messages will be sent to spam instead of the inbox. Monitor reports for unexpected legitimate failures.
5. Validate again for 2–4 weeks. Confirm all legitimate traffic is consistently aligned and that no new senders have been added without configuration.
6. Move to p=reject. Failed messages are now dropped. This is the target state for spoofing protection.

For SaaS and ecommerce teams, the challenge is that legitimate sending sources multiply quickly. Platforms like Mailchimp, SendGrid, HubSpot, Salesforce, Postmark, and customer support tools each need their own SPF includes and DKIM signing configuration. Inventorying all senders before enforcement is essential.

Common mistakes that create false confidence

• Assuming SPF pass means the visible From domain is protected. SPF checks the Return-Path, not the From header. A passing SPF result tells you nothing about whether the recipient-facing domain is authenticated.
• Assuming DKIM pass means DMARC will also pass. DKIM validates the signing domain, which may belong to a third-party vendor. DMARC requires that signing domain to align with the visible From.
• Publishing DMARC but never reviewing aggregate reports. A DMARC record without active report monitoring is a policy statement with no operational feedback. Failures accumulate silently.
• Adding third-party senders without checking alignment. Every new vendor that sends email as your domain needs a custom MAIL FROM and aligned DKIM. Onboarding a new platform without this step creates alignment failures.
• Trusting one DNS lookup tool without checking real-world headers. DNS lookups confirm record existence and syntax. They do not tell you whether actual messages are aligning. You need to inspect message headers and aggregate reports.
• Moving to strict enforcement before inventorying all legitimate mail sources.Shadow senders — internal tools, monitoring alerts, partner integrations — are commonly missed and break on enforcement day.

How to verify your setup before a spoofing or deliverability incident

1. Confirm the visible From domain used by your application, vendor, or email platform.
2. Check the Return-Path / envelope sender domain. This is the domain SPF will validate. It may differ from the visible From.
3. Check the DKIM signing domain (d= value in the DKIM-Signature header). Confirm it matches or aligns with the visible From domain.
4. Compare those domains for DMARC alignment.At least one — SPF or DKIM — must align with the visible From for DMARC to pass.
5. Inspect live DNS records for SPF, DKIM, and DMARC using a tool like the CodeAva analyzer.
6. Review sample headers from real sent mail. Send a test message and examine the raw headers to confirm Return-Path, DKIM signing domain, and authentication results.
7. Parse aggregate DMARC reports to identify failing sources. Look for legitimate senders that are passing SPF or DKIM but failing alignment.
8. Confirm policy progression before enforcing quarantine or reject. Every legitimate sender should be consistently aligned in reports before you tighten enforcement.

SPF pass vs. DKIM pass vs. DMARC pass — comparison

Conclusion and next steps

SPF and DKIM are necessary building blocks, but they are not sufficient on their own. SPF proves an IP was authorized for an envelope domain. DKIM proves a signature was valid for a signing domain. Neither proves that the domain the recipient actually sees is protected.

DMARC is where alignment and policy make the result meaningful. It connects authentication outcomes to the visible From domain and tells receivers what to do when that connection is missing. “Pass” only matters when you know what actually passed and for which domain.

The operational takeaway: do not trust a green label in a single lookup tool. Verify your actual message headers, inspect your DNS records, and parse your aggregate DMARC reports. Identify every sending source, confirm alignment for each one, and progress your policy toward enforcement only when the data confirms you are ready.

The CodeAva DMARC / SPF / DKIM Analyzer & Report Parser helps you do exactly that: check your SPF, DKIM, and DMARC records, diagnose alignment issues, and turn raw DMARC XML reports into something humans can actually read — without uploading sensitive data to a third-party service.

If email authentication is part of a broader domain trust and security posture review, a CodeAva website audit can surface security header gaps, DNS configuration issues, and other signals that affect how trustworthy your domain appears to both users and automated systems.