Why is DMARC failing but SPF passes?

The confusion comes from two different domains wearing the same name. When a receiving server logs spf=pass, it is answering a narrow question: was the sending server authorized to send for the domain in the Return-Path (the envelope sender, called RFC5321.MailFrom in the specs)? That domain travels in the SMTP envelope, not in anything your recipient reads. It is often not your domain at all.

DMARC asks a second question on top: does the domain that passed actually match the From address a human sees? RFC 7489 is explicit that DMARC uses the result of SPF authentication of the MAIL FROM identity, and that the pass only counts toward DMARC when that domain aligns with the RFC5322.From domain. No alignment, no DMARC pass, regardless of how cleanly SPF verified.

So spf=pass next to dmarc=fail is not a contradiction; it is the single most common DMARC failure signature, and it is diagnosable from one header. The good news: DMARC only requires one aligned mechanism, so a DKIM signature from your own domain can carry the message even while SPF alignment stays broken. The sections below walk a real header, then the four causes in order of likelihood.

Here is the shape of the headers on a typical marketing send from acme.com through an ESP, trimmed to the three lines that matter. The From address is billing@acme.com. The Return-Path is bounce-77.campaign@mail182.mcsv.net, an ESP bounce domain. The receiver's Authentication-Results line reads spf=pass smtp.mailfrom=mail182.mcsv.net; dkim=pass header.d=mcsv.net; dmarc=fail header.from=acme.com.

Walk it check by check. SPF passed, honestly: the sending server really is authorized to send for mail182.mcsv.net, because the ESP publishes SPF for its own bounce domain. DKIM passed too, but the signature's d= is also the ESP's domain. DMARC then compares both authenticated domains against acme.com, finds neither aligns, and fails the message. Every individual check told the truth; none of them vouched for the domain in the From line.

This is exactly the scenario DMARC was designed to catch, because it is also what spoofing looks like: anyone can pass SPF for a domain they control while displaying yours. The fix is never to loosen DMARC; it is to give the receiver an authenticated identifier that IS your domain, which in practice means enabling custom DKIM signing (so d=acme.com) or a custom bounce domain (so the Return-Path becomes bounce.acme.com), or both.

Alignment comes in two strengths, set by the aspf and adkim tags in your DMARC record. In relaxed mode (the default for both), the two domains only need to share an organizational domain: RFC 7489's own example is a Return-Path of cbg.bounces.example.com aligning with a From of payments@example.com. In strict mode, only an exact domain match counts, so that same pair fails.

Strict mode is a common self-inflicted wound. Plenty of legitimate setups put a subdomain in the Return-Path (bounce.acme.com, em.acme.com) precisely so bounces route to the sending platform. Under aspf=r that aligns; flip to aspf=s and every one of those messages loses SPF alignment overnight, with nothing else changed. If you see DMARC failures only on subdomain-Return-Path mail, check whether someone set strict mode.

Leave both tags relaxed unless you have a specific threat model that requires exact matching, and you have first confirmed in your aggregate reports that every legitimate stream already matches exactly. The glossary entry on adkim and aspf covers the tag syntax; the link is in Related below.

When a recipient auto-forwards your mail (a university address forwarding to Gmail, an old work address forwarding to a new one), the forwarding server re-sends the message from its own infrastructure. Google's Workspace documentation states it plainly: "Even if SPF is correctly set up for your domain, forwarded messages can still fail SPF. This is usually because of the way the forwarding server forwards messages."

Many forwarders rewrite the Return-Path to their own domain (a scheme called SRS) so their server passes SPF, but that pass is on the forwarder's domain and cannot align with your From domain. Nothing in your SPF record can prevent this; the mail is legitimately no longer coming from your servers.

The mitigation is DKIM. A valid DKIM signature travels inside the message and survives a clean forward, so a signature with d= on your domain keeps DMARC passing even after SPF alignment breaks in transit. This is the practical reason to authenticate with both mechanisms: SPF for the direct path, DKIM for everything the message goes through afterward.

Alignment breaks silently. Marketing adds a new tool, the ESP rotates a sending configuration, someone edits DNS, and a stream that aligned last quarter quietly stops counting. At p=none nobody notices until deliverability sags; the reports record the drift, but only if someone reads them.

The end state worth reaching is DMARC at p=reject with every legitimate sender aligned: spoofed mail using your domain gets dropped at the receiver, and any alignment regression in your own streams surfaces immediately instead of festering. Monitoring is how you get there; enforcement is the point.

Alignment failures are the default state of an unmanaged client domain: nearly every tenant runs at least one SaaS tool that sends with its own Return-Path, so "SPF passes but DMARC fails" shows up on almost every onboarding audit. The billable work is the sender inventory: read the client's aggregate reports, list every source, and align or retire each one before touching the policy. Palisade does the ongoing half of that automatically; it hosts the SPF, DKIM, and DMARC records per client domain, watches every source in the aggregate reports, and walks each domain to p=reject, with ConnectWise, HaloPSA, and Autotask integrations so an alignment regression lands as a ticket in your PSA. Your own MSP domain is a free NFR domain to prove the workflow on.