Deliverability

What is DMARC alignment, and why do SPF and DKIM pass but DMARC fail?

The single most common DMARC support question is some form of "SPF passes, DKIM passes, so why does DMARC say fail". The answer is always alignment, and once you have seen the mechanism it stops being surprising.

Note before the details: the specification that most guidance still cites, RFC 7489, is obsolete. DMARC is now RFC 9989, which states plainly that "This document obsoletes RFCs 7489 and 9091." Everything below is the current text.

Why is a passing check not enough?

Because SPF and DKIM each authenticate a domain that your recipient never sees.

SPF is evaluated against the envelope sender, the address a receiving server is given during the SMTP conversation. DKIM is evaluated against the signing domain in the signature's d= tag. Neither of them looks at the From header, which is the only address displayed in a mail client.

A sender who controls evil.example can pass SPF for evil.example and sign perfectly for evil.example, and still put your brand in the From line. Both checks pass. Nothing has been proved about the thing the reader is looking at. Alignment closes that gap by requiring that a passing check be in the name of the From domain.

What counts as aligned?

One of two relationships, and the domain owner chooses which.

RFC 9989 defines both:

When the Author Domain has the same Organizational Domain as an Authenticated Identifier, the two are said to be in relaxed alignment.

and, in the section after it:

When the Author Domain is identical to an Authenticated Identifier, the two are said to be in strict alignment.

The standard's own examples make the difference concrete:

Authenticated identifierFrom domainAlignment
foo.example.comnews.example.comrelaxed, since both sit under example.com
news.example.comnews.example.comstrict, since they are identical
foo.example.netnews.example.comnone, since they share no organizational domain

Relaxed is the default for both mechanisms, set by the adkim and aspf tags in your DMARC record, and the specification is unusually candid about how the choice plays out in practice: "In practice, nearly all Domain Owners have found relaxed alignment sufficient to meet their needs."

Strict is worth reaching for only when you have a specific reason to refuse a sibling subdomain, and it is a reliable way to break your own mail if any part of your sending uses one.

Does DMARC need both to align?

No. One aligned pass carries the message.

DMARC evaluates SPF and DKIM independently, and passes if either one both passes and aligns. That asymmetry is the reason DKIM matters more than SPF in practice.

Consider a forwarded message. The forwarding server is not on your SPF record, so SPF fails at the destination. The DKIM signature travels with the message, so it still verifies, and it is still in your domain's name. DMARC passes on the DKIM leg alone. Had you been relying on SPF only, that same forward would have failed DMARC.

This is also why the fix for a DMARC failure is usually a DKIM fix. How to fix DMARC failures works through the diagnosis.

Why does SPF alignment break when I use a sending platform?

Because the platform owns the envelope sender by default, and the envelope sender is what SPF authenticates.

When a platform sends on your behalf, the bounce address is typically at the platform's own domain, so SPF passes for the platform and aligns with nothing of yours. Adding an include: for that platform to your own SPF record does not fix it, because the check was never evaluated against your domain in the first place.

The fix is a return path under your own domain. Bird does this with a CNAME on your sending domain, so the envelope sender is a subdomain of yours and SPF aligns in relaxed mode with no record at your apex at all. The bounce domain guide has the record, and Where's SPF? explains why the apex stays empty.

What changed when DMARC became a standard?

Two things that affect records people wrote years ago.

The pct tag is gone. It let you apply a stricter policy to a percentage of failing mail, and RFC 9989 removed it, giving the reason in its own appendix:

Operational experience showed that the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.

A record still carrying pct=50 is not doing what its author thinks. A record carrying pct=0 was being read by some intermediaries as an instruction to rewrite the From header, which is very far from a percentage.

The Public Suffix List is no longer how the standard finds the organizational domain. RFC 9989 defines a DNS tree walk instead, querying up the domain hierarchy for a policy record rather than consulting a published list of suffixes. Since relaxed alignment is defined in terms of the organizational domain, this is the mechanism that decides whether two of your subdomains align at all. What the specification cannot tell you is which receivers have implemented it yet, and it is new enough that the answer is worth assuming is mixed.

Neither change asks anything of you today beyond removing a pct tag whose intermediate values never worked reliably. Both are worth knowing before you take a third-party checklist at face value, since a great deal of published DMARC advice describes a specification that has been replaced.

Does an aligned pass mean the mail is good?

No, and the standard says so itself:

A DMARC pass for a message indicates only that the use of the Author Domain has been validated for that message as authorized by the Domain Owner. Such authorization does not carry an explicit or implicit value assertion about that message or the Domain Owner, and Mail Receivers MAY choose to reject or quarantine a message even if it passes the DMARC validation check.

Alignment makes your mail attributable. What that attribution is worth is reputation, and that is earned separately.

Build on the same network.

A test API key is yours immediately. Production unlocks when you add a payment method and verify a sender.

Starten Sie mit einem Kanal.
Fügen Sie die anderen hinzu, wenn Sie bereit sind.

Ein Test-API-Key steht Ihnen sofort zur Verfügung. Der Produktivzugang wird freigeschaltet, sobald Sie eine Zahlungsmethode hinzufügen und einen Absender verifizieren.

Sie nutzen Claude Code, Cursor oder Codex? Kopieren Sie einen Setup-Prompt und Ihr Agent installiert die Bird CLI und Skills für Sie. Wählen Sie Ihren:

Cursor