Alignment is the domain relationship at the centre of DMARC. SPF or DKIM can pass for a domain that has no qualifying relationship with the domain in From. DMARC needs at least one passing path that also aligns.
Strict and relaxed alignment define different trust boundaries. The choice is not simply "more secure" versus "more compatible". It determines which controlled domain relationships can satisfy the assessment.
Identify the domains before comparing them
Protocol references: RFC 9989 §3.2.2, RFC 9989 §4.4.1, RFC 9989 §4.4.2. Operational checklists and decisions below are editorial guidance.
For each representative received message, record:
- Field: Visible From; Domain used for alignment: The Author Domain DMARC evaluates
- Field: SPF; Domain used for alignment: The authenticated envelope domain for the relevant SPF result
- Field: DKIM; Domain used for alignment: The d= domain of each passing signature
Authentication and alignment are separate columns. First establish whether SPF or a DKIM signature passed. Then compare that passing identity with the Author Domain under the configured mode.
A raw pass for an unrelated provider domain remains useful protocol evidence, but it does not become aligned because the organisation has a commercial account with the provider.
Strict alignment requires exact domains
Protocol references: RFC 9989 §3.2.10.2. Operational checklists and decisions below are editorial guidance.
Under strict SPF alignment, the authenticated SPF domain must exactly match the Author Domain. Under strict DKIM alignment, the passing signature's d= domain must exactly match the Author Domain.
For all fixtures below, assume an applicable valid policy, completed checks and example.com as the discovered organizational domain. Consider a synthetic message with From at billing.example.com:
- Path: SPF; Authenticated domain: billing.example.com; Raw result: Pass; Strict alignment: Yes
- Path: DKIM; Authenticated domain: example.com; Raw result: Pass; Strict alignment: No
The message can satisfy DMARC through SPF in this example. The passing DKIM signature does not align strictly because example.com and billing.example.com are not exact matches.
Relaxed alignment uses the organisational-domain relationship
Protocol references: RFC 9989 §3.2.10.1, RFC 9989 §4.10.2. Operational checklists and decisions below are editorial guidance.
Relaxed alignment can accept the applicable organisational-domain relationship defined by DMARC. It is not a last-two-label shortcut and not an arbitrary suffix match.
Using the same fictional Author Domain billing.example.com:
- Authenticated domain: mail.example.com; Raw result: Pass; Relaxed relationship: Same applicable organisational domain; Outcome for that path: Aligned
- Authenticated domain: example.com; Raw result: Pass; Relaxed relationship: Same applicable organisational domain; Outcome for that path: Aligned
- Authenticated domain: example.net; Raw result: Pass; Relaxed relationship: Unrelated domain; Outcome for that path: Not aligned
- Authenticated domain: customer-example.com; Raw result: Pass; Relaxed relationship: Similar text only; Outcome for that path: Not aligned
The exact result depends on correct policy-domain processing. Country-code and privately controlled suffixes are examples of why visual label counting is unsafe.
Treat delegated subdomains as authority
Suppose an organisation controls example.com but delegates campaigns.example.com to a marketing business unit or external platform. Under relaxed alignment, a passing identity within the same applicable organisational-domain relationship may align with another From subdomain.
That can be operationally useful. It also means the organisation must understand who can create signing identities, envelope domains and From addresses beneath the relevant boundary.
The risk is not that relaxed alignment is automatically unsafe. The risk is granting subdomain authority without a maintained ownership model. A forgotten delegation can become an authentication path that remains technically aligned.
Compare two delegation models
Model A: centrally governed subdomains
DNS changes, DKIM selectors and sender onboarding require central approval. In this hypothetical model, technical controls restrict which identities delegated teams can create; an approval policy alone cannot establish that restriction. Relaxed alignment can reduce configuration friction while the governance model constrains who can use the namespace.
Model B: broad independent delegation
Business units or vendors control subdomains and signing keys with limited central inventory. Relaxed alignment can make those independently operated identities relevant to DMARC assessment for related From domains. Strict alignment narrows the relationship, but it does not fix unknown delegations or compromised keys.
Choose alignment only after identifying which model resembles reality.
Use one message to calculate the outcome
Protocol references: RFC 9989 §5.3.5. Operational checklists and decisions below are editorial guidance.
This fictional message has:
- Observation: From; Value: alerts@security.example.com
- Observation: SPF; Value: Pass for bounce.notifications.example.com
- Observation: DKIM 1; Value: Pass with d=notifications.example.com
- Observation: DKIM 2; Value: Pass with d=mailer.example.net
- Observation: aspf; Value: s
- Observation: adkim; Value: r
SPF does not align strictly because bounce.notifications.example.com is not an exact match for security.example.com. DKIM 1 can align under the relaxed organisational-domain relationship. DKIM 2 does not align because example.net is unrelated.
The message therefore has a qualifying DKIM path and can pass DMARC at message level. That conclusion does not require both mechanisms to align, and the unrelated second signature does not cancel the aligned passing one.
Decide with a trust inventory
For each domain family, record:
- the organisational boundary used for policy processing;
- every delegated subdomain and accountable owner;
- systems allowed to select visible From domains;
- systems allowed to create envelope identities;
- DKIM key and selector owners;
- whether strict alignment is technically supported;
- exception and expiry dates;
- evidence from representative received messages.
Do not infer ownership from DNS alone. Confirm the business owner and intended use.
Change alignment without breaking legitimate mail
Before moving from relaxed to strict alignment, test every route that currently passes only through a related but non-identical domain. Common examples include a parent-domain DKIM signature for a From subdomain or a shared bounce subdomain.
A controlled change plan includes the current and proposed tags, affected senders, configuration work, representative tests, approval and rollback. Monitor receiver results after the DNS change and allow for cache timing.
Before moving from strict to relaxed alignment, review subdomain delegations and key ownership. The change can expand which domain relationships qualify, so it deserves the same governance as a technical migration.
Avoid three common mistakes
Protocol references: RFC 9989 §8. Operational checklists and decisions below are editorial guidance.
First, do not compare display names. Alignment compares domains associated with authenticated paths and the Author Domain.
Second, do not assume relaxed means any subdomain that looks similar. Use the applicable organisational-domain method.
Third, do not treat message-level DMARC pass as full programme readiness. Reliable participation also requires maintained authentication, policy, reporting and ownership. A single aligned path proves the result for that message, not the health of every sender.
Review alignment as ownership changes
Reassess alignment when acquiring a company, delegating a subdomain, changing an email platform, rotating DKIM keys or discovering an unknown sender. The DNS tags may remain unchanged while the real trust boundary expands.
The right alignment mode is the one whose accepted domain relationships match an explicit, current ownership model and whose legitimate routes can demonstrate reliable passing paths.
Apply the evidence without overstating it
For the mixed-mode fixture, strict SPF fails the domain comparison, DKIM 1 supplies the relaxed aligned path and DKIM 2 supplies no aligned path. Changing only adkim to s removes that qualifying DKIM path because notifications.example.com is not security.example.com. With the stated completed-check assumptions and unchanged inputs, neither mechanism then supplies a passing aligned path. This is analytical reasoning, not a verifier run.