The From domain your reader sees is the anchor DMARC compares everything to
DMARC begins with the domain in the RFC 5322 From field, called the Author Domain. It does not begin with the sending IP, Return-Path or a provider logo. RFC 9989 defines the Author Domain and the authenticated identifiers compared with it. This keeps the test tied to the domain a recipient sees when deciding who appears to have written the message.
Suppose the message displays billing@receipts.example.com. The reference domain is receipts.example.com. SPF may authenticate a MAIL FROM domain, while DKIM may authenticate one or more d= domains. Alignment asks whether any passing one is related closely enough to the reference domain under the published mode.
The reframe is simple: authentication produces identities; alignment compares identities. A pass result without its domain is incomplete evidence. Copy the domains side by side before touching DNS.
The practical takeaway for a non-technical owner is that a passing check is only half the story. When a supplier sends on your behalf, it may authenticate its own domain perfectly while presenting yours to the customer: which is precisely the moment your DMARC setup starts to flag a problem. Knowing the anchor identity lets you ask the right supplier the right question.
For the underlying difference between the two authentication mechanisms, see the practical SPF and DKIM comparison before choosing which identity to repair.
Relaxed alignment follows the organisational boundary
Under relaxed alignment, the Author Domain and authenticated identifier align when they share the same organisational domain. Under strict alignment, the names must be identical. The current specification defines both modes and notes that relaxed alignment is sufficient for nearly all domain owners in practice.
For offers.example.com in From, a passing DKIM signature from mailer.example.com can align in relaxed mode because both sit within example.com. A signature from example.com does not align merely because the labels look similar. Public suffix handling matters, so do not find the organisational boundary by simply taking the last two labels.
Strict mode narrows the match but increases configuration sensitivity. It may suit a controlled design with identical names, yet it can break legitimate subdomain arrangements without adding useful protection for many small organisations. Choose it only from observed routes, not from a belief that stricter always means safer.
SPF alignment uses the validated MAIL FROM domain
SPF can evaluate HELO and MAIL FROM identities, but DMARC relies on the SPF-validated MAIL FROM identity. RFC 9989 states which SPF identity DMARC uses. The visible From address is not substituted into the SPF check.
The SPF result itself is produced by comparing the connecting client with the policy for the SMTP identity. RFC 7208 defines that host-authorisation check. A platform can therefore pass SPF for bounce.vendor.net while showing news@example.com. That is a valid SPF pass but no DMARC alignment.
A custom return-path setting may give the service a subdomain of your organisational domain, such as bounce.example.com. If the platform controls and uses it correctly, relaxed SPF alignment becomes possible. Do not add provider IPs to the root SPF record unless the observed envelope identity and provider instructions show that this is actually the required design.
DKIM alignment uses a signature that really validates
DKIM’s d= value names the signing domain. The selector in s= identifies which public key to query beneath _domainkey. RFC 6376 explains the signing domain, selectors and verification. Only a valid signature supplies a DKIM-authenticated identifier for DMARC.
A message may carry several signatures. DMARC can pass if any valid d= domain aligns with From. A provider signature for vendor.net can pass without helping alignment, while a second signature for example.com provides the aligned path.
If the aligned signature fails because a gateway changed signed content, the unrelated provider signature does not rescue DMARC. Preserve all signature results and reason text. The DNS owner may need to fix a key record, the sender may need to enable custom signing, or an intermediary may need to stop altering signed material.
One small table stops you guessing: write the identities side by side
Create columns for route, visible From domain, SPF result, SPF MAIL FROM domain, SPF aligned, DKIM result, DKIM d=, selector, DKIM aligned and DMARC result. Use one row for each controlled message. If there are several DKIM signatures, add adjacent rows or a clearly separated list rather than hiding them in one cell.
For a fictional example, From orders@shop.example, SPF pass for returns.shop.example and DKIM pass for send.vendor.test gives relaxed SPF alignment but no DKIM alignment. Change From to orders@brand.example and neither authenticated identity aligns. The values are illustrative domains, not configuration instructions.
Mark “not observed” rather than guessing. Alignment is evaluated on real messages, so a DNS record that looks plausible cannot fill a missing message identity.
Separate absence, failure and misalignment
- Absent: there is no usable SPF policy for the observed envelope domain or no DKIM signature for the intended signing domain.
- Failed: SPF does not authorise the connecting host, or DKIM verification cannot validate the signature against the retrieved key and signed content.
- Unaligned: SPF or DKIM passes, but the authenticated domain is outside the required relationship with From.
These classes point to different changes. Absence may require enabling a provider feature. Failure may require repairing authorisation, DNS publication or message handling. Misalignment usually requires a custom return path or custom DKIM signing domain controlled by the business. Random additions to the root domain do not change a provider identity already visible in the header.
Retest after only one targeted change. If both paths are broken, choose the route with the clearest owner and reversible configuration first.
Most alignment failures fall into one of three categories, and each has a different fix. If authentication is absent, you enable a provider feature. If it fails, you repair a DNS record or message handling stage. If it passes but is simply the wrong domain, you configure a custom return path or a supplier DKIM signing domain that actually matches your From address: the fix is almost never a random edit to your root domain.
Strict mode needs an explicit business case
Strict SPF and DKIM modes are selected with aspf=s and adkim=s. Omitting them uses relaxed alignment. Strict matching can make a deliberate identity boundary visible, but it also rejects alignment between legitimate sibling or parent subdomains that relaxed mode accepts.
Before adopting strict mode, list every visible From domain and authenticated domain from each route. Include bounces, forwarded paths, third-party campaigns and low-volume applications. Ask what concrete abuse strict matching would prevent in your design and whether the same goal can be achieved through clearer subdomain ownership.
If the answer depends on unobserved assumptions, retain relaxed mode and improve route ownership. A strict setting that causes authorised mail to fail is not automatically more secure; it can pressure administrators to create broad workarounds elsewhere.
It is tempting to set strict alignment because it sounds more secure, and common advice online endorses it. But in practice relaxed alignment works for nearly every UK small business, and strict mode can quietly reject legitimate mail from sibling subdomains. If you are weighing the two, understanding why SPF can pass while DMARC fails is the best primer for the trade-off you are really making.
Keep the alignment table, not somebody’s inbox
The alignment table should contain domains and results, not the contents of the messages used to produce them. For each route, retain From, MAIL FROM, DKIM d= and selector values, relaxed or strict mode, receiver verdict and UTC time. Link that row to a protected original header held by the mail team. Redact names, local parts, subjects and message IDs from the review copy when they add nothing to the domain relationship.
Be careful with screenshots from provider dashboards. They can expose account names, recipient addresses and tenant identifiers while hiding the raw domain that matters. Prefer a short text extract of the alignment fields and public DNS answers. If a supplier needs a sample, send it through the verified account-support route and include only the signature or envelope fields connected to its service.
The alignment owner should set access and retention for the table and its source headers. Private keys and login details do not belong there. When the organisational-domain boundary or public-suffix treatment is disputed, preserve the observed names and ask the DNS or security owner to decide. Do not widen access to personal mail simply to settle a technical comparison.
Verify the exact domain relationship the receiver used
Send from the precise From address and provider route listed in the alignment table. At the receiving mailbox, copy the Author Domain, SPF-validated MAIL FROM domain and every valid DKIM signing domain. Apply the published relaxed or strict mode to those observed names. A DNS checker cannot perform this proof because it has no received message and therefore no authenticated identifiers to compare.
Record which path produced DMARC pass. For example, a message may pass through returns.example.com under relaxed SPF alignment while a valid vendor.net signature remains unaligned. If strict mode is under review, test each authorised subdomain arrangement, not just mail from the organisational domain. Then repeat one route whose identities should be unchanged.
Keep the before-and-after table rows and the corresponding public queries. If a forwarding or gateway test breaks the aligned signature, capture both the direct and transformed copies and hand the difference to the intermediary owner. Do not disguise that result by recording only the unrelated signature that still passes.
Pause when the domain boundary is uncertain
Stop before changing alignment mode if the organisational domain has been guessed from the last two labels, a delegated subdomain has no known owner, or any critical route is still marked “not observed”. Strict mode should not be used as an experiment on production traffic. If a change causes sibling subdomain mail to fail, restore the approved earlier value and preserve both headers.
Escalate SPF identity questions to the envelope-route owner and DKIM identity questions to the signer. The DMARC or DNS owner should decide policy only after those people confirm the domain design. Supply the alignment table, public records and receiver results. Do not add broad authorisations or weaken the organisation-wide policy merely to make one unexplained row green.
No one should publish a change that cannot be explained against one row of observed identities. Keep the present setting until the missing route, domain boundary or owner is confirmed, and state exactly which comparison remains unresolved.
Sources and further reading
- RFC 9989: Domain-based message authentication, reporting and conformance
- RFC 7208: Sender Policy Framework
- RFC 6376: DomainKeys Identified Mail signatures