Fix DMARC alignment failures: relaxed vs strict, subdomains, and header mismatch

What DMARC alignment means

DMARC does not simply check whether SPF or DKIM pass. It adds a second requirement called alignment: the domain that passed the SPF or DKIM check must match the domain in the visible From: header (the RFC 5322 address that your recipients see in their email client).

There are two alignment paths, and only one needs to succeed for DMARC to pass:

SPF alignment. The domain in the RFC 5321 MAIL FROM (also called the envelope sender or Return-Path) must match the From: header domain.
DKIM alignment. The d= domain in a valid DKIM signature must match the From: header domain.

If neither path aligns, DMARC fails, even when SPF and DKIM individually pass. This is the single most common source of confusion in DMARC deployment.

RFC 5321 vs RFC 5322: the two "From" addresses

Every email has two sender addresses, and they are often different. You need this distinction to diagnose alignment failures.

RFC 5321 MAIL FROM (envelope sender)

This address is set during the SMTP transaction. Mail servers use it for bounce routing. It appears in the Return-Path header of delivered messages. SPF checks this domain. Your recipients never see it unless they inspect the raw headers.

RFC 5322 From (visible sender)

This is the address displayed in your email client. It is the domain that DMARC alignment checks against. Your DMARC policy protects this domain.

Example: mismatched headers

Here is a simplified view of an email where SPF passes but alignment fails:

Return-Path: <[email protected]>
From: [email protected]
To: [email protected]
Subject: Your weekly report

Authentication-Results: mx.google.com;
  spf=pass (sender IP is 198.51.100.22) smtp.mailfrom=em.mailprovider.com;
  dkim=pass header.d=example.com header.s=selector1;
  dmarc=pass (p=QUARANTINE) header.from=example.com

In this example, SPF passes for em.mailprovider.com but the From: header shows example.com. SPF alignment fails because the domains do not match. However, DKIM alignment succeeds because the DKIM signature has d=example.com, which matches the From: domain. DMARC passes through DKIM alignment alone.

Now consider what happens when DKIM is not configured or fails:

Return-Path: <[email protected]>
From: [email protected]
To: [email protected]
Subject: Your weekly report

Authentication-Results: mx.google.com;
  spf=pass (sender IP is 198.51.100.22) smtp.mailfrom=em.mailprovider.com;
  dkim=none;
  dmarc=fail (p=QUARANTINE) header.from=example.com

SPF passes for em.mailprovider.com, but alignment fails because the Return-Path domain does not match example.com. There is no DKIM signature to provide a second alignment path. DMARC fails.

SPF passes but DMARC fails

This is the most common alignment failure. It happens when a third-party email service provider (ESP) uses its own domain as the envelope sender.

Why it happens

When you send email through a provider like Mailchimp, SendGrid, or HubSpot, they typically set the Return-Path to their own bounce-handling domain, such as bounces.mailchimp.com or em1234.sendgrid.net. SPF checks this domain, finds a valid SPF record, and returns pass. But DMARC then checks whether bounces.mailchimp.com matches your From: domain (example.com). It does not, so SPF alignment fails.

How to fix it

You have two options:

Option 1: configure a custom Return-Path domain. Most ESPs allow you to set up a custom bounce domain like bounce.example.com. This usually involves adding a CNAME record in your DNS that points to the ESP's bounce server. Once active, the Return-Path becomes bounce.example.com, which aligns with example.com under relaxed mode.
Option 2: rely on DKIM alignment. This is often the easier path. Most ESPs let you configure DKIM signing with your own domain by adding one or more CNAME records for the DKIM selector. Once the ESP signs with d=example.com, DKIM alignment passes and DMARC succeeds, even if SPF alignment still fails.

In practice, configure both. DKIM alignment is your primary path, and a custom Return-Path gives you a fallback if the DKIM signature ever fails (for example, due to message modification by a mailing list).

Relaxed vs strict alignment

DMARC supports two alignment modes, controlled by the aspf (SPF alignment) and adkim (DKIM alignment) tags in your DMARC record.

Relaxed alignment (default)

Relaxed mode requires that the organizational domain (the registrable domain) matches. Subdomains are allowed to align with the parent domain.

bounce.example.com aligns with example.com. Pass.
mail.example.com aligns with example.com. Pass.
example.com aligns with example.com. Pass.
example.net does not align with example.com. Fail.

Relaxed mode is the default when aspf and adkim tags are not present. Most organizations should use relaxed alignment.

Strict alignment

Strict mode requires an exact domain match. No subdomain matching is permitted.

example.com aligns with example.com. Pass.
mail.example.com does not align with example.com. Fail.
bounce.example.com does not align with example.com. Fail.

Setting alignment mode

You set alignment mode in your DMARC TXT record on _dmarc.example.com:

v=DMARC1; p=quarantine; aspf=r; adkim=s; rua=mailto:[email protected]

In this example, SPF alignment is relaxed (aspf=r) and DKIM alignment is strict (adkim=s). You can mix and match.

When to use strict alignment

You want to prevent any subdomain from passing DMARC alignment with your organizational domain.
High-security environments where subdomain spoofing is a concern (for example, login.example.com spoofing as example.com).
You control all sending infrastructure and can guarantee exact domain matches.

When to use relaxed alignment

You use subdomains for different services (e.g., marketing.example.com, support.example.com).
Your ESP configures DKIM or Return-Path on a subdomain of your domain.
You are in the early stages of DMARC deployment and want to minimize false failures.

For a full reference on DMARC record tags, see the DMARC record tags guide.

Subdomain alignment failures

Subdomains introduce a common class of alignment problems, especially in organizations with multiple teams or services sending email from different subdomains.

The problem

Your marketing team sends from marketing.example.com. Your DMARC record is published on _dmarc.example.com. DKIM is configured with d=example.com. Under relaxed alignment, d=example.com aligns with the From: domain marketing.example.com because they share the organizational domain example.com. No issue.

But switch to strict DKIM alignment (adkim=s), and d=example.com no longer aligns with marketing.example.com. The DKIM signature is valid, but alignment fails because strict mode demands an exact match.

The sp= tag and subdomain policy

When a receiving server processes mail from marketing.example.com, it first looks for a DMARC record at _dmarc.marketing.example.com. If none exists, it falls back to the organizational domain record at _dmarc.example.com and applies the sp= (subdomain policy) tag. If sp= is not present, the subdomain inherits the p= policy.

This means that if your organizational domain has p=reject and no sp= tag, all subdomains also inherit p=reject. If a subdomain sends mail without proper alignment, those messages will be rejected.

Solutions

Use relaxed alignment. This is the simplest approach. Keep adkim=r (or omit it, since relaxed is the default), and subdomains will align with the parent domain automatically.
Publish a DMARC record on the subdomain. Create a TXT record at _dmarc.marketing.example.com with its own policy and alignment settings. This overrides the organizational domain record for that subdomain.
Configure DKIM with the subdomain's exact domain. Set the DKIM d= value to marketing.example.com instead of example.com. This satisfies strict alignment for that subdomain.
Set sp=none during deployment. While you inventory and configure all subdomain senders, use sp=none on the organizational domain to prevent subdomain mail from being quarantined or rejected.

Diagnosing alignment failures in DMARC reports

DMARC aggregate reports (RUA) are the primary tool for diagnosing alignment problems. Every report contains the raw authentication results and the DMARC policy evaluation.

Key sections in the XML report

Look at the <record> elements. Each record represents a group of messages from a particular source IP. Inside each record, two sections matter:

auth_results: raw authentication outcomes

<auth_results>
  <spf>
    <domain>em.mailprovider.com</domain>
    <result>pass</result>
  </spf>
  <dkim>
    <domain>example.com</domain>
    <selector>s1</selector>
    <result>pass</result>
  </dkim>
</auth_results>

This shows the raw results. SPF passed for em.mailprovider.com and DKIM passed for example.com. These results do not yet tell you whether DMARC passed, because alignment has not been evaluated.

policy_evaluated: the DMARC decision

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>

This is where alignment is reflected. The <spf> tag inside <policy_evaluated> shows fail, meaning SPF did not align, even though the raw SPF result was pass. The <dkim> tag shows pass, meaning DKIM aligned. DMARC passed through DKIM alignment.

Spotting the pattern

When you see this combination in your reports:

auth_results/spf/result = pass but policy_evaluated/spf = fail: SPF alignment failure.
auth_results/dkim/result = pass but policy_evaluated/dkim = fail: DKIM alignment failure.
Both policy_evaluated/spf and policy_evaluated/dkim = fail: complete alignment failure, DMARC fails.

Using DMARCTrust to diagnose alignment

Reading raw XML reports is tedious. The DMARCTrust dashboard parses your aggregate reports automatically and shows alignment results per sending source. You can quickly identify which sources have SPF alignment, DKIM alignment, or both, and which ones are failing. The sources view breaks down pass and fail counts by IP address and sending organization, so you know exactly which ESP or server to fix.

Use the DMARC checker for a quick check of your domain's current DMARC, SPF, and DKIM configuration without needing an account.

Prevention

Alignment failures are almost always preventable with proper initial configuration. Follow these practices to avoid them.

Configure custom domains on every ESP

For every third-party service that sends email on your behalf, configure both:

Custom DKIM signing domain. Set the DKIM d= to your domain (or a subdomain of your domain). This is your primary alignment path.
Custom Return-Path/bounce domain. Set the envelope sender to a subdomain of your domain (e.g., bounce.example.com). This provides SPF alignment as a backup.

Both configurations typically involve adding CNAME records in your DNS. Your ESP's documentation will have the specific records to add.

Start with relaxed alignment

Unless you have a specific security reason for strict alignment, keep the defaults. Relaxed alignment (aspf=r, adkim=r) covers the vast majority of legitimate sending configurations. Only tighten to strict after you have confirmed that all sending sources produce exact domain matches.

Inventory all sending sources first

Before moving your DMARC policy to p=quarantine or p=reject, spend at least two to four weeks at p=none collecting aggregate reports. Identify every source that sends mail using your domain. Confirm each one has proper DKIM and/or SPF alignment. Only then should you tighten your policy. See our guide on migrating from p=none to p=reject for a detailed roadmap.

Monitor alignment rates continuously

Alignment can break at any time. An ESP changes its infrastructure. A developer spins up a new transactional email service without DNS configuration. A marketing team starts using a new tool. Set up DMARCTrust monitoring to catch alignment regressions before they cause delivery failures.

For a deeper understanding of how DMARC alignment works at the protocol level, read the DMARC alignment documentation.

To generate or update your DMARC record with the correct alignment settings, use the DMARC generator.

DMARC alignment issues