How Alignment Decides a DMARC Result
DMARC alignment means the domain that passed SPF or DKIM has to match the domain in the visible From address, either exactly (strict) or at the organizational level (relaxed). A message can pass SPF, pass DKIM, and still fail DMARC if neither passing domain lines up with the From domain. This is for anyone who has stared at a DMARC report that shows green SPF and DKIM columns next to a red DMARC result.
SPF and DKIM Can Pass Without Proving Anything About Your Domain
SPF and DKIM were designed before DMARC, and each one authenticates a domain that the reader never sees. Anyone can publish an SPF record for a domain they own and send mail that passes it. Anyone can sign a message with a valid DKIM key for their own domain. A pass only says the sender controls some domain.
DMARC adds the missing question: is that domain the one in the From header? RFC 9989 puts it plainly. A DMARC pass needs an SPF or DKIM pass and also that the domain behind the pass is aligned with the Author Domain, the one in the From header. Without that second condition, a phishing message could carry a perfectly valid signature from the attacker's own domain and a From line reading your company name.
The Three Domains in Every Message
Every message you send has three domains attached, and they are often different.
The first is the From domain, the address people see. The second is the envelope sender, also called MAIL FROM or Return-Path, which receiving servers use for bounces and which SPF checks. The third is the DKIM signing domain, the d= value inside the DKIM-Signature header, covered in our DKIM walkthrough.
When your own mail server sends for your own domain, all three are usually the same and alignment is invisible. When a billing tool or newsletter service sends for you, the envelope sender is often a bounce-handling hostname that belongs to the vendor, and the signature is often made with the vendor's domain. Both can pass. Neither matches your From line.
Relaxed and Strict, with Real Hostnames
The DMARC record sets the mode for each check with two tags. adkim controls DKIM and aspf controls SPF. Both default to r, relaxed, and s means strict. The tags and defaults are in RFC 9989, section 4.7, and were the same in the original RFC 7489.
Relaxed alignment asks for the same organizational domain. Strict asks for an identical hostname. The RFC's own table shows the difference, and a version with sending-style names looks like this.
- DKIM
d=example.com, Fromalerts@news.example.com: aligned in relaxed mode, fails in strict mode. - DKIM
d=news.example.com, Fromalerts@news.example.com: aligned in both modes. - SPF MAIL FROM
bounces.example.com, Frombilling@example.com: aligned in relaxed mode, fails in strict mode. - DKIM
d=mailvendor.net, Frombilling@example.com: not aligned in either mode, however valid the signature is.
RFC 9989 notes that in practice nearly all domain owners have found relaxed alignment sufficient. Leave the tags out and you get relaxed.
One Aligned Pass Is Enough
DMARC does not need both mechanisms to align. A message satisfies DMARC when at least one of SPF or DKIM passes with an aligned domain. If a message carries several DKIM signatures, a single aligned and valid one is enough, according to RFC 9989.
That is why DKIM is the more dependable half. SPF alignment breaks whenever a message is forwarded, because the forwarding server's address is not in your SPF record and the envelope sender is rewritten or fails the check. A DKIM signature on your own domain travels with the message and still verifies afterward, as long as nobody edits the signed headers or body. Google's sender guidelines state the requirement the same way: the From domain must be aligned with either the SPF domain or the DKIM domain.
What RFC 9989 Changed in May 2026
RFC 7489, the 2015 specification most articles still cite, was obsoleted in May 2026 by RFC 9989 and two companion documents (RFC 9990 for aggregate reporting and RFC 9991 for failure reporting). The idea of alignment did not change. Relaxed still means the same organizational domain and strict still means identical.
What changed is how a receiver finds the organizational domain. RFC 7489 relied on a public suffix list. RFC 9989 defines a DNS tree walk, where the receiver climbs the domain name looking for DMARC records. The RFC also dropped the pct tag, which let you apply a policy to a percentage of failing mail, and added a t tag for testing. For most domains the practical effect today is nothing, but it explains why older guides and newer ones disagree on a few tags (checked October 2026).
Finding and Fixing a Misaligned Sender
Most alignment failures come from a handful of sources, and you can identify each one from a DMARC aggregate report in a few minutes. The fix is nearly always a DNS record that makes the vendor sign or bounce with a subdomain of your own domain.
Reading the Failure in an Aggregate Report
Each row of an aggregate report describes one sending IP address. Three parts matter. The policy_evaluated element holds the DMARC verdict for DKIM and SPF. The identifiers element shows the header_from domain and the envelope_from domain. The auth_results element lists the domains that actually passed, including the DKIM d= value and selector. The element names are defined in RFC 9990.
The pattern to look for is a row where auth_results shows a pass for a domain that is not yours, while policy_evaluated shows a fail. That is the misaligned sender. Our guide to reading a DMARC report covers the XML in more detail.
Third-Party Senders and the Two Records They Need
Most email platforms offer a setup step with a name like custom domain, domain authentication, or branded sending. It asks you to publish a few DNS records, usually CNAMEs. They do two jobs. One set lets the platform sign with a DKIM key under your domain, so d= matches your From. The other points a bounce hostname such as bounces.example.com at the vendor, so the envelope sender is also on your domain and SPF aligns.
Skip this step and the default is the vendor's shared domain, which passes SPF and DKIM and aligns with nothing. Do it and either half of DMARC can pass. If the platform only offers one of the two, DKIM is the one to insist on. Check the exact hostnames the vendor gives you, because a DNS panel that appends your domain automatically will happily turn s1._domainkey.example.com into s1._domainkey.example.com.example.com. The SPF syntax guide covers the other half of that setup.
Forwarding, Mailing Lists, and Why Some Failures Are Normal
Not every failing row is a problem you can fix. A message forwarded from an alumni address or a role alias leaves your authorized servers, so SPF fails on the next hop. A mailing list that adds a footer breaks the DKIM body hash. RFC 9989 acknowledges this directly: p=reject can cause trouble for indirect mail flows, and the specification says mailing lists have mostly adopted workarounds that rewrite the From header.
The practical reading is that a small amount of failing mail from forwarders and lists is background noise, while a steady stream from a sending service you recognize is a configuration gap.
When Strict Mode Helps and When It Bites
Strict alignment shrinks the set of hostnames that can pass for your domain, which matters if subdomains are delegated to people you do not control. The cost is that anything signing with the apex domain and sending from a subdomain, or the reverse, now fails.
A common trap: your newsletter tool signs with d=example.com, but the From address is hello@news.example.com. Relaxed alignment passes this. Add adkim=s and every message fails, and if the policy is already quarantine, those messages go to spam. Move to strict only after a report period shows every legitimate sender already signing with the exact From hostname.
Raising the Policy Without Bouncing Your Own Mail
The order is fixed. Publish p=none and collect reports. Fix every legitimate sender so it produces an aligned pass. Move to quarantine, watch the reports again, then reject. RFC 9989 describes the t=y tag as a way to ask receivers to treat a policy one level more gently while you test, so reject with t=y behaves like quarantine.
The step people skip is the first one. Enforcing before alignment is clean is how invoices, password resets, and booking confirmations end up in spam. If you are already seeing that, start with why emails go to spam, since alignment is one of several causes.
Getting Alignment Sorted Out for You
With Email Authentication, we find every service that sends as your domain, sign each sender with DKIM, and publish one clean SPF record. We gather and read the DMARC reports each week and explain alignment problems in plain words, and nothing is enforced before your real mail passes. The DNS service holds the records, the transactional email service covers site-generated mail, and deliverability monitoring watches whether messages arrive. You can see how Email Authentication compares with other DMARC tools on the comparison page.
