Debugging DMARC Alignment Failures in Microsoft 365 Relays

The alert lands in your queue: DMARC failure for an email supposedly from your own CFO. You pull the headers, expecting a sophisticated spoof. But SPF passed. DKIM passed. Yet, the final DMARC verdict is a hard `fail`. Your own domain is being blocked by a partner's mail gateway, and the evidence makes no sense.

This isn't a spoof. It's a self-inflicted wound. This is the classic signature of a DMARC alignment failure, a problem that plagues any organization using a complex mail flow, especially those relaying mail through Microsoft 365 after it's been processed by another gateway.

The root cause isn't a failure of authentication itself, but a breakdown in how that authentication is associated with the domain your recipient sees in the `From:` line. Understanding this distinction is the difference between chasing phantom attackers and fixing a fundamental architectural flaw.

The Relay Problem: Why Your Architecture Breaks `From:` Header Alignment

Email authentication has two personalities. There's the address used in the SMTP conversation for routing and bounce handling—the `5321.MailFrom` or envelope sender. Then there's the address the user actually sees in their mail client—the `5322.From` or header sender. DMARC, as defined in RFC 7489, demands that the domain used for a passing SPF or DKIM check *aligns* with the domain in that visible `5322.From` header.

How SPF Alignment Fails

Imagine your mail flow: an email from an external partner hits your third-party Secure Email Gateway (SEG), which then forwards it to Microsoft 365's Exchange Online Protection (EOP) for final delivery. When the SEG forwards the message, the SMTP session with EOP now originates from the SEG's IP address. EOP performs an SPF check. The check looks up the SPF record for the envelope sender (`5321.MailFrom`) domain and compares it to the SEG's IP. If you've correctly included your SEG in your SPF record, SPF will pass.

But here's the catch. The `5322.From` header still shows the original sender's domain (yourpartner.com). EOP sees a passing SPF check for your SEG's domain but a `From:` header for yourpartner.com. These domains don't align. The result: `spf=pass`, but SPF alignment for DMARC fails.

How DKIM Alignment Fails

DKIM alignment is subtler. DKIM (RFC 6376) uses a cryptographic signature that covers selected headers and a hash of the message body. If an intermediary system, like a cloud security gateway or even M365 itself, adds a compliance footer or alters the message body in any way, the body hash will no longer match. The signature breaks. DKIM fails outright.

Even if DKIM survives, the alignment can fail for the same reason SPF does. The `d=` tag in the DKIM-Signature header specifies the signing domain. If that domain doesn't match the `From:` header's domain, DMARC alignment fails. This is common when mail is sent on your behalf by a third-party service that signs with its own domain (e.g., `d=sendgrid.net`) but uses your domain in the `From:` line.

Reading the `Authentication-Results` Header to Find the Truth

The single most important piece of evidence in a DMARC debug is the `Authentication-Results` header. Don't trust your dashboard; read the raw source. This header is stamped by mail servers to record the results of authentication checks. Microsoft's implementation is particularly verbose and useful.

Authentication-Results: dkim=pass (signature was verified) header.d=yourdomain.com; spf=pass (sender IP is 1.2.3.4) smtp.mailfrom=your-seg.com; dmarc=fail action=quarantine header.from=yourdomain.com; compauth=fail reason=001 — Example Authentication-Results Header

Let's dissect this. `dkim=pass` and `header.d=yourdomain.com` shows a valid signature from our domain. Great. But then, `spf=pass` with `smtp.mailfrom=your-seg.com` shows that the passing SPF check was for the SEG's envelope, not our domain. The final verdict is `dmarc=fail` with `header.from=yourdomain.com`. Why?

Decoding Microsoft's `compauth` Verdict

Microsoft uses a proprietary `compauth` (Composite Authentication) tag to give a summary verdict. A `compauth=fail` means that despite individual passes, the message failed the overall alignment-based evaluation. The `reason=001` code is key. A reason code of `001` specifically means the message failed DMARC because the `5321.MailFrom` domain (your-seg.com) and the `5322.From` domain (yourdomain.com) did not align. A reason code of `002` would indicate a failure due to a lookalike domain.

This header tells the whole story: DKIM passed and aligned, but SPF passed for a different, unaligned domain. If your DMARC policy requires a passing identifier from *either* SPF or DKIM, this should have been enough. But in many relay scenarios, something else can cause DKIM to fail, leaving only the unaligned SPF pass, which is useless for DMARC.

When 'Relaxed' Alignment Is Necessary (And Not Enough)

DMARC allows for two levels of alignment: strict (`s`) and relaxed (`r`). Strict alignment means the domains must be identical. `aspf=s` requires an exact match between the `5321.MailFrom` domain and the `5322.From` domain. `adkim=s` requires an exact match between the DKIM `d=` tag domain and the `5322.From` domain.

Relaxed alignment (`aspf=r` and `adkim=r`) allows a subdomain relationship. For example, if the `From:` header is `marketing@yourcorp.com` and the DKIM signature is from `d=email.yourcorp.com`, relaxed alignment would pass, while strict would fail. Most organizations should be using relaxed alignment by default. Strict policies are brittle and offer little additional security while creating significant delivery problems with legitimate third-party senders who use subdomains.

However, relaxed alignment is not a fix for the relay problem described earlier. If your SEG relays mail using an envelope sender of `bounces.seg-provider.net`, that domain shares no organizational relationship with `yourcorp.com`. Relaxed alignment doesn't help. The domains are fundamentally different, and SPF alignment will always fail. You need a way to preserve the original, valid authentication result from *before* the relay.

The ARC Fix: Re-Sealing Trust Across Hops

This is exactly the problem that the Authenticated Received Chain (ARC), defined in RFC 8617, was created to solve. ARC provides a way for an intermediate mail server (like EOP in our relay scenario) to see the authentication results from a previous, trusted hop (like your SEG) and honor them, even if its own local checks would fail.

ARC works by creating a new chain of cryptographic signatures. When your SEG receives an email and verifies its SPF and DKIM, it creates an `ARC-Authentication-Results` header with those verdicts. It then creates an `ARC-Seal` and `ARC-Message-Signature` to sign those results. When EOP receives the forwarded message, it sees the ARC headers. If it trusts the SEG (as defined in its configuration), it can validate the ARC seal. If the seal is valid, EOP can trust the original authentication results and ignore its own DMARC alignment failure.

Verifying ARC in Action

You'll know ARC is working when you see a series of headers prefixed with `ARC-`. The most important one to look for in the final delivered message is in the `Authentication-Results` header. You'll see something like `dmarc=fail` (because of the local alignment failure) but followed by `arc=pass`. This `arc=pass` tells the receiver that despite the local failure, a trusted chain of custody has been established, and the message should be considered authentic. Both Microsoft 365 and Google Workspace honor ARC seals from trusted forwarders.

This makes ARC essential for any architecture involving forwarding or relaying. It fixes the broken link in the chain of trust caused by MTAs rewriting headers or changing envelope senders. Without it, you are forced to choose between a secure DMARC policy and reliable mail delivery from legitimate, complex sources.

Playbook: Configure Connectors to Preserve Authentication

Knowing the theory is one thing; fixing it in the M365 admin center is another. The key is telling Microsoft to trust the upstream hop—your SEG. This is done via 'Enhanced Filtering for Connectors'.

When you configure an inbound connector for your SEG, enabling Enhanced Filtering tells EOP to treat the source IP of the SEG as an internal, trusted hop. EOP will then correctly identify the *true* source IP of the original email, which is passed along by the SEG in headers like `X-Forwarded-For`. This allows EOP to perform its SPF check against the correct IP, preserving the original SPF result and avoiding the alignment failure.

This configuration is critical. By identifying all the IP addresses of your upstream SEG, you essentially tell EOP, "Trust the authentication verdicts you receive from these systems. They are part of our extended security perimeter." This not only helps with DMARC alignment for inbound mail but also improves the accuracy of Microsoft's own spam filtering and threat detection, as it's now working with the true sender information.

Auditing Your DMARC Policy for Intentionality

Finally, take a look at your own public DMARC record. This TXT record at `_dmarc.yourdomain.com` dictates your policy to the world. Two tags are relevant here: `aspf` and `adkim`.

If these tags are not specified, they default to `r` for relaxed. This is the correct setting for almost everyone. However, if you see `aspf=s` or `adkim=s`, you need to ask why. Was this an intentional decision made to enforce a very strict policy, or was it a misconfiguration? In a complex environment with multiple sending services and potential relays, a strict policy is a recipe for false positives and blocked legitimate email.

Your DMARC record should be a conscious choice. If you're grappling with alignment failures, confirming both `aspf` and `adkim` are set to relaxed (or are absent, thereby defaulting to relaxed) is a necessary sanity check. It ensures you aren't making an already difficult problem impossible to solve.

The takeaway

DMARC alignment failures in a relayed environment are not edge cases; they are the predictable outcome of a complex but common architecture. The solution isn't to weaken your DMARC policy to `p=none` or to create broad SPF includes that dilute your security posture. The solution is to fix the flow of information.

By enabling Enhanced Filtering for Connectors and ensuring your upstream gateways support and apply ARC, you preserve the chain of trust from the original sender to the final mailbox. Instead of fighting your security stack, you make it work together. Analyzing the full header chain in a tool like MailSleuth.AI can make these broken handoffs immediately obvious, but the fix always comes down to trusting your trusted partners correctly.