DMARC's Dirty Secret: Exploiting Relaxed Alignment for Domain Spoofing

You find a target with a DMARC policy of `p=reject`. They look locked down. Most attackers would move on, but you dig deeper. You pull the full record and see it: `aspf=r`. Relaxed alignment. Suddenly, the fortress has a back door wide open, and the key is just controlling any subdomain.

This isn't a theoretical vulnerability. It's a playbook. Business Email Compromise (BEC) attacks rely on trust, and nothing builds trust faster than an email that sails through security filters with a full set of passing authentication checks. A relaxed DMARC policy hands attackers the tools to build that trust.

Most security teams who set up DMARC think the job is done once they reach `p=quarantine` or `p=reject`. They stop looking. But the alignment parameters, `aspf` for SPF and `adkim` for DKIM, are where the real security posture is defined. And the default, relaxed, is dangerously permissive.

Reconnaissance: Finding the Weak Link

The first phase of the attack is simple intelligence gathering. Attackers don't need sophisticated tools; they just need DNS. A single command can reveal a domain's DMARC posture.

dig txt _dmarc.victim.com — Terminal

The response tells the story. We're looking for records that either explicitly state `aspf=r` or omit the `aspf` tag entirely, as relaxed is the default behavior according to RFC 7489. A record like `v=DMARC1; p=reject; rua=mailto:dmarc-rua@victim.com;` is just as vulnerable as one that explicitly states `aspf=r`.

Why do so many domains use relaxed alignment? It's convenient. Organizations use a vast ecosystem of third-party services for marketing, HR, and support, often hosted on subdomains like `marketing.example.com` or `support.example.com`. Relaxed alignment allows emails from these subdomains to authenticate even if the user-visible `From:` address uses the parent domain, like `invoices@example.com`. It solves a legitimate operational problem, but it creates a security nightmare.

The Anatomy of Alignment

DMARC's entire purpose is to connect what the user sees (`From:` header) with what the mail servers check (SPF and DKIM authentication). This connection is called 'alignment'. Without it, SPF and DKIM are just disconnected signals. An email could pass SPF for `evil.com` while claiming to be from `google.com`, and without DMARC, nobody would be the wiser.

Strict vs. Relaxed Alignment

Strict (`s`) alignment is what you think you're getting. The domain in the `From:` header must be an identical match to the domain validated by SPF or signed by DKIM. If the `From:` is `ceo@victim.com`, the SPF-validated domain (`MAIL FROM`) must also be `victim.com`. No exceptions.

Relaxed (`r`) alignment, on the other hand, only requires that the domains share the same 'Organizational Domain.' This means the parent domain must match. Under this rule, an SPF check passing for `newsletters.victim.com` is considered aligned with a `From:` header of `ceo@victim.com`. The logic is that they both belong to the `victim.com` organization. This is the assumption we exploit.

An attacker's goal is to find a way to send mail that passes SPF or DKIM for *any* subdomain of the target organization. If they can achieve that, the relaxed alignment policy gives them a license to spoof any address at the parent domain.

The Attacker's Playbook in Action

Let's walk through a concrete attack against a target, `securecorp.com`, whose CISO thinks their `p=reject` policy has them covered. Their record: `v=DMARC1; p=reject; aspf=r;`.

Step 1: Weaponize a Subdomain

We need control over a `securecorp.com` subdomain's DNS. The easiest path is often subdomain takeover, where we find a CNAME record like `mail.securecorp.com` pointing to a third-party service that has been de-provisioned. By re-registering that account on the third-party service, we gain control. Alternatively, we might find that the company's cloud DNS is sloppily managed, and we can register a new, unused subdomain like `alerts.securecorp.com` ourselves.

Once we control `alerts.securecorp.com`, we create an SPF record for it. It's as simple as adding a TXT record: `v=spf1 ip4:198.51.100.123 -all`. This record authorizes our mail server (at `198.51.100.123`) to send on behalf of `alerts.securecorp.com`. To any receiver, this is a perfectly valid SPF policy.

Step 2: Forge the Email and Bypass Filters

Now, we craft the spearphishing email. The RFC 5322 `From:` header is set to `"The CEO" <ceo@securecorp.com>`. This is what the recipient will see in their email client. The RFC 5321 `MAIL FROM` (the envelope sender) is set to `bounces@alerts.securecorp.com`. This is the domain SPF will check.

When our email hits a modern mail gateway like Google or Microsoft 365, the gateway validates it. The `Authentication-Results` header tells the whole story:

Authentication-Results: mx.google.com; spf=pass (google.com: domain of bounces@alerts.securecorp.com designates 198.51.100.123 as permitted sender) smtp.mailfrom=bounces@alerts.securecorp.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=securecorp.com

Look at that. SPF `pass`. DMARC `pass`. The policy action (`p=REJECT`) is rendered completely impotent because the authentication succeeded. The email doesn't just slip past the gateway; it's practically waved through with honors. It lands in the user's inbox, often without a warning banner, because from a technical standpoint, it is perfectly authentic.

Your Only Real Defense: Strict Alignment

The fix is conceptually simple but operationally demanding: move to strict alignment. Your DMARC policy must evolve to `aspf=s` and `adkim=s`.

With strict alignment, the attack we just ran would fail catastrophically. The DMARC check would compare the `From:` header domain (`securecorp.com`) to the SPF-authenticated domain (`alerts.securecorp.com`). Because they are not an identical match, alignment fails. With a `p=reject` policy, the email is immediately blocked. The back door is slammed shut.

Of course, making this change isn't as simple as flipping a switch. It requires a comprehensive audit of every service that sends email on your behalf. Every third-party marketing platform, every transactional email provider, every support desk. You must ensure that each of these services is configured to achieve a strict alignment pass. This often means configuring custom DKIM signing so they sign with a key from your parent domain, not their own or a subdomain's.

It's tedious work. It involves coordinating with vendors and digging through DNS settings. But the alternative is leaving your domain's reputation and security in the hands of a single permissive tag.

Auditing Your Exposure and Your Supply Chain

You can't defend against a threat you can't see. Auditing for this vulnerability needs to be part of your regular security hygiene, both for your own domains and for the vendors you trust.

Internal Domain Audit

Start by checking every domain you own. Don't forget defensive domains or domains from past acquisitions. If a DMARC record is missing `aspf` and `adkim` tags, assume they are relaxed. Your goal should be a clear inventory of which domains are on strict vs. relaxed alignment.

Next, dive into your DMARC aggregate (RUA) reports. These XML files are a goldmine. Filter for traffic where the `From:` header uses your parent domain but the SPF or DKIM domain is a subdomain. Are all of these sources known and authorized? You might be surprised to find legacy systems or shadow IT sending mail you thought was decommissioned years ago. Each one is a potential takeover target.

Supply Chain Risk

Your security is not an island. Run the same `dig txt _dmarc.vendor.com` check on your critical suppliers, especially those in finance, legal, and logistics. If your primary law firm has a relaxed DMARC policy, an attacker could spoof an urgent wire transfer request from them that would pass authentication and land in your CFO's inbox. Their vulnerability becomes your incident.

Where you find permissive policies, start a conversation. Send them this article. Weak email authentication in your supply chain is a direct threat to your organization. It's a risk that needs to be managed just like any other third-party vulnerability.

The takeaway

Moving from `p=none` to `p=reject` is just the first hill to climb in DMARC deployment. The real summit is achieving strict alignment. Anything less leaves a subtle but devastating flaw in your defenses—a flaw that attackers understand far better than most defenders.

Don't assume your `p=reject` policy is a shield. It's only as strong as your alignment rules. Go check your records right now. And while you're at it, check your top five vendors. The results might force you to rethink what 'secure' really means. You can use your DMARC reporting provider or tools like MailSleuth.AI to analyze aggregate reports and quickly identify sources sending on your behalf that would fail a strict alignment policy.