DMARC Identifier Alignment: relax, don't do it, when you want to go to it

What it is

A walkthrough by Bencteux (jbencteux) showing that a subdomain takeover can be escalated into DMARC-passing phishing against the organizational domain — not just the taken-over subdomain — when DMARC uses relaxed SPF alignment. Demonstrated against altf8.fr (author-owned) on Microsoft 365.

How it works

Relaxed SPF alignment (aspf=r) requires only that the MAIL FROM domain and the From: header domain share an organizational domain, not an exact match. So the attacker sends MAIL FROM: ceo@takeover.altf8.fr (the subdomain they control via takeover) with a From: header on altf8.fr — both roll up to altf8.fr, so SPF passes and aligns, and DMARC passes.

The takeover chain: takeover.altf8.fr CNAMEs to sub.dangling.com, an unregistered domain the attacker claims. They then set on their own zone an A record, an MX (server.dangling.com), and crucially an SPF TXT record sub IN TXT "v=spf1 mx -all". Because DNS resolves the CNAME through, takeover.altf8.fr inherits that SPF record and MX, so the attacker's server is an authorized sender.

Preconditions

• A subdomain takeover where the dangling target is a domain/DNS zone the attacker can register and control — the post explicitly notes that takeovers pointing to third-party services (GitHub, etc.) do not work, because the attacker needs to set SPF/MX/A records in the resolved zone.
• Target DMARC in relaxed SPF mode. This is the default when aspf is unset. The post shows "v=DMARC1; p=reject; sp=reject" — even with p=reject/sp=reject — is vulnerable, and so is one with explicit aspf=r; adkim=r.

What to do

Set strict alignment. The post gives the non-vulnerable policy verbatim:

"v=DMARC1; p=reject; sp=reject; aspf=s; adkim=s"

Strict mode requires an exact DNS domain match, breaking the subdomain→org-domain trick. (And, as always, remediate dangling DNS records.)

Caveats

• The mechanism defeats SPF alignment only; the post states DKIM cannot be forged for the domain this way, though it teases "a trick" to make mail look more trustworthy — the fetched text cuts off before that trick and before the DMARC-pass confirmation, so those details aren't captured here.
• The included curl/SMTP transcript is truncated mid-upload; it confirms the target accepts the MAIL FROM/RCPT TO but the excerpt doesn't show the final delivery/DMARC result.
• Note p=reject gives no protection here — engineers relying on a strict policy while leaving alignment relaxed are still exposed.