Alignment — aspf and adkim

DMARC pass requires that an authenticated identifier aligns with the From: header domain. The DMARC record itself controls how strict that alignment check is, through two tags: aspf for SPF alignment and adkim for DKIM alignment.

Both default to relaxed. You will rarely change them. You still need to know what they do because alignment is the most common reason a message fails DMARC when SPF and DKIM each look fine.

Relaxed alignment (the default)

Relaxed alignment means the organizational domain must match. The organizational domain is the registrable part — isidoregroup.com for any host under it.

Examples for a From: header of ceo@isidoregroup.com:

• SPF envelope MAIL FROM of bounces@mail.isidoregroup.com → relaxed SPF alignment passes. Same organizational domain.
• DKIM signing domain (d=) of marketing.isidoregroup.com → relaxed DKIM alignment passes. Same organizational domain.
• SPF envelope MAIL FROM of bounces@isidore-sends.com → relaxed SPF alignment fails. Different organizational domain.

This is the mode every practical deployment uses, because real mail flow involves subdomains for bounces, marketing, transactional, and so on. Relaxed lets those align with the parent domain.

Strict alignment

Strict alignment requires exact match — the full domain in the authenticated identifier must equal the full domain in the From: header.

For the same From: of ceo@isidoregroup.com:

• SPF envelope MAIL FROM of bounces@isidoregroup.com → strict SPF alignment passes.
• SPF envelope MAIL FROM of bounces@mail.isidoregroup.com → strict SPF alignment fails. Subdomain.
• DKIM d=isidoregroup.com → strict DKIM alignment passes.
• DKIM d=marketing.isidoregroup.com → strict DKIM alignment fails.

Strict alignment is rare. It is occasionally used by financial institutions and government domains where the security posture justifies forbidding any subdomain to authenticate for the apex. For an MSP-managed business domain, relaxed is correct.

How the tags appear in a DMARC record

v=DMARC1; p=reject; aspf=r; adkim=r; rua=mailto:dmarc@isidoregroup.com

aspf=r is relaxed SPF alignment. aspf=s is strict. Same for adkim. When the tags are absent, both default to relaxed. You will see most records omit the tags entirely.

Why From: header alignment is the keystone

The whole point of DMARC is that the receiver enforces a check on the identifier the user sees. That identifier is the From: header. Every alignment rule in DMARC compares some other authenticated thing against the From: header domain.

If a message has a perfectly valid SPF pass for one domain and a perfectly valid DKIM signature for a second domain, and the From: header shows a third domain — DMARC fails. Two authenticated identifiers and zero alignment.

This is the situation a spammer engineers. They control their own sending infrastructure, so they can produce a perfectly valid SPF and DKIM pass for the domain they actually own. What they cannot do — when DMARC is published with p=reject — is also pass alignment against the From: header for a domain they do not own.

That asymmetry is what makes DMARC work.

The practical failure modes

The two alignment failures that show up in real DMARC reports for MSP clients:

1. Third-party sender uses a different envelope domain.
A marketing tool sends From: ceo@isidoregroup.com but its envelope MAIL FROM is bounces@mailtool.com. SPF passes for mailtool.com. Alignment fails because mailtool.com is not the organizational domain of isidoregroup.com. The fix is DKIM — the tool signs with d=isidoregroup.com using a key it published on a CNAME under the client’s domain. That gives DKIM alignment.

2. CRM or scheduling tool that sends as the user but cannot sign.
The same shape, but the tool offers no DKIM signing-as-domain feature. SPF alignment is impossible because the envelope is the tool’s domain. DKIM alignment is impossible because the tool will not sign with the client’s key. The message will fail DMARC under p=reject. The fix is either to change the tool, or to add the tool’s envelope domain to a subdomain delegation, or to accept that the tool sends from its own address rather than as the user.

These are not theoretical. Most of the noise during a staged DMARC ramp is one of these two patterns being surfaced for the first time.

Where Cathedra sits

DmarcRecordCheck.php parses the DMARC record’s tags and stores them, but does not produce a separate finding on aspf or adkim. Those tags affect outcomes downstream — in the reports — not in the DNS check. Your job is to read the record, recognize relaxed-vs-strict, and predict which third-party senders will or will not align under the policy.

What you should remember

• Relaxed alignment matches at the organizational domain level. Strict requires exact match.
• Both aspf and adkim default to relaxed. Most domains never change them.
• The From: header is the identifier DMARC protects. Every alignment rule compares some authenticated thing against it.
• A message can have SPF pass and DKIM pass and still fail DMARC if neither aligns with the From: domain.
• The common alignment failures involve third-party senders. Surfacing them is what p=none monitoring is for, before you move to quarantine or reject.

---

Cathedra alignment: DmarcRecordCheck.php — the alignment tags parsed but not directly scored; understanding them explains every alignment-related DMARC failure