DMARC strict vs relaxed alignment under RFC 9989
Short answer
Relaxed alignment passes when the domain in your DKIM signature or your bounce address shares the same Organizational Domain as your From address. Strict alignment passes only when they are identical. Relaxed is the default and the right choice for most senders that use sending tools on subdomains. Strict is for a domain where you control every sending subdomain exactly and want no room at all.
What alignment checks
DMARC does not check your From address directly. It checks whether one of two other identifiers lines up with the From domain:
- the d= domain in a DKIM signature that verified, or
- the domain of the MAIL FROM address (the bounce address) when SPF passed.
If either one is aligned, DMARC passes. If neither is, the policy in your record applies. This is why a cold email tool that signs mail as its own domain, or bounces to its own domain, can show "DKIM pass" and "SPF pass" and still fail DMARC for you.
Relaxed vs strict, with an example
Your From address is sales@example.com.
| Identifier the receiver saw | Relaxed | Strict |
|---|---|---|
| DKIM d=example.com | aligned | aligned |
| DKIM d=mail.example.com | aligned (same Organizational Domain) | not aligned |
| Bounce address at bounce.example.com | aligned | not aligned |
| DKIM d=yourtool.com | not aligned | not aligned |
RFC 9989 describes the two modes in Section 4.10.2: identifiers are compared to see whether they are "identical (strict alignment)" or share "the same Organizational Domain (relaxed alignment)". The mode is set per identifier in your record: adkim= for DKIM and aspf= for SPF, each r (relaxed, the default) or s (strict). Both are defined in Section 4.7.
Which one to use
- Use relaxed (the default) if any tool sends for you from a subdomain, or if your bounce domain is a subdomain. That covers most B2B senders and nearly every cold email platform.
- Use strict only when every message in your domain's name is signed with d= exactly equal to your From domain and bounces to exactly that domain, and you want a subdomain you do not control to fail. Strict on a domain that still uses subdomain tools will fail your own mail.
- Before switching to strict, read your aggregate reports for two weeks and confirm no legitimate sender aligns only through a subdomain.
Three things that changed with RFC 9989
- RFC 7489 is no longer the current DMARC specification. RFC 9989's header reads "Obsoletes: 7489, 9091". Pages and checkers that still cite RFC 7489 as current are out of date.
- The pct tag is historic. Table 5 in Section 9.3 lists pct, rf and ri as historic. The tag list in Section 4.7 no longer includes pct, and the same section says "unknown tags MUST be ignored". Do not build a ramp on pct=50. Ramp with the policy itself: p=none with reports, then p=quarantine, then p=reject, and read the reports between steps.
- The Organizational Domain comes from a DNS Tree Walk (Section 4.10), which the RFC introduces with the words "Rather than just using a PSL". A new t= tag (values y or n, default n) marks a policy as being in test mode.
One more rule worth knowing
If a domain publishes more than one DMARC record at the same name, Section 4.10 says that when multiple records are returned for a single target they are all discarded. Two records is the same as no record. Check for this before anything else.
Check your own domain in one command
dig +short TXT _dmarc.example.comRead the adkim= and aspf= tags. If they are absent, both are relaxed. If you see two answers, you have two records. If you see pct=, the tag is historic.
The free audit at audit.humerly.com reads the same record and explains each finding in plain words. No signup.
What this page does not claim
This page describes what RFC 9989 says a validator does. It does not predict how any particular mailbox provider applies the specification today, and it does not promise inbox placement.
Reviewed by Venkat Nookala. Last reviewed: 5 November 2026. Sources: RFC 9989 (Sections 3.2.10, 4.4, 4.7, 4.10, 9.3).