Back to Blog

Your Auto-Replies Are Failing DMARC (And You Don't Know It)

May 12, 2026
10 min
email-security dmarc dkim exchange misconfiguration

I spent last week reviewing DMARC failures hitting our inbound mail gateway. Not phishing attempts, but legitimate email from legitimate companies failing authentication. I expected the usual: third-party senders who hadn’t configured SPF or DKIM for the domains they were sending on behalf of. That’s common and well-documented.

What I found instead was a pattern. Almost every DMARC failure was an auto-reply. Out-of-office messages. Mailbox rule responses. Vacation notices. The most boring, invisible, unmonitored message type in enterprise email, and it was failing authentication at a rate that would be alarming if anyone were looking.

The Pattern

I pulled headers from DMARC failures across multiple senders over a few days. Different companies, different industries, different countries, different outbound gateways. The commonality:

  • Every failure was an auto-reply generated by Exchange’s Mailbox Rules Agent
  • Every failure had dkim=none or DKIM signing on a non-aligned domain
  • Every failure had SPF checking against the outbound gateway’s hostname instead of the sender’s domain
  • Every company’s normal, human-sent email from the same mailbox passed DMARC without issue

Same person, same mailbox, same infrastructure. A manual reply passes. An auto-reply fails. And the difference comes down to a single RFC-compliant behavior that almost nobody accounts for.

The Mechanism

When you send an email from Exchange, the envelope sender (MAIL FROM) is your email address. Your outbound gateway’s IP is in your SPF record. SPF passes. The From header domain matches the envelope domain. DMARC alignment passes. Everything works.

When Exchange’s Mailbox Rules Agent generates an auto-reply, it uses a null return path (<>). This is correct behavior per RFC 5321 — automatic responses and notifications should use a null sender to prevent bounce loops. Exchange is doing the right thing.

But a null return path means there’s no MAIL FROM domain for SPF to check. The receiving server falls back to checking SPF against the HELO identity, which is your outbound gateway’s hostname. That hostname belongs to your gateway vendor, not your organization. SPF returns none. No alignment.

With SPF dead, DMARC needs DKIM to save it. If you have a valid DKIM signature aligned with your From domain, DMARC passes on DKIM alignment alone, regardless of what SPF does.

Here’s the problem: almost nobody has that DKIM signature.

Here’s what the failure looks like in headers. This is a composite, sanitized from real examples:

Authentication-Results: inbound.example.com;
    dkim=none;
    dmarc=fail reason="No valid SPF, No valid DKIM"
        header.from=company.com (policy=quarantine);
    spf=none (inbound.example.com: domain of
        outbound-gw.vendor.com has no SPF policy)
        smtp.helo=outbound-gw.vendor.com
Return-Path: <>
X-MS-Exchange-Generated-Message-Source: Mailbox Rules Agent
Auto-Submitted: auto-generated

Return-Path: <> is the null sender. smtp.helo is the gateway, not the sender’s domain. dkim=none. That’s the whole failure in six lines.

It’s worth noting that not every platform handles auto-replies this way. Every failure I observed came from Microsoft Exchange infrastructure, whether M365 cloud or on-premises. Google Workspace, by contrast, preserves the envelope sender on auto-replies rather than nulling it — a design choice that sidesteps the entire problem. Microsoft followed RFC 5321 to the letter. Google diverged from it. Google’s auto-replies authenticate. Microsoft’s don’t.

That isn’t a knock on Microsoft for being standards-compliant. It’s an observation that RFC 5321 was written before DMARC existed. The null sender specification and the email authentication specification were designed in different eras with different assumptions, and they collide on exactly one message type that nobody thinks to test. Microsoft’s implementation is correct. It also creates a DMARC failure at a foundational level that almost no one accounts for, because it only surfaces on an extreme edge case that’s invisible by nature.

If you’re an Exchange shop, DKIM isn’t optional. It’s the only thing standing between your auto-replies and DMARC failure.

Three Flavors of the Same Failure

Looking across the failures I collected, they fell into three variants, all leading to the same result.

Variant 1: No DKIM at all. The most common. The organization deployed an outbound secure email gateway, configured SPF to include the gateway’s IP ranges, set a DMARC policy, saw green checkmarks on test emails, and stopped. DKIM requires additional setup: generating keys, publishing DNS records, configuring the gateway to sign. They never did it. SPF was passing, DMARC was passing, what’s the problem?

The problem is auto-replies.

Variant 2: DKIM signing on the wrong domain. One sender had DKIM, and it validated perfectly. But it was signed with d=companyname.onmicrosoft.com, the default Microsoft 365 tenant domain. Their From header used their actual domain. Under DMARC alignment, even relaxed, onmicrosoft.com doesn’t match company.com. DKIM passes validation and completely fails to help with DMARC.

This happens when someone enables DKIM in Microsoft 365 but never configures custom domain signing keys. The default signing domain is the .onmicrosoft.com tenant name. It proves the message is authentic. It does nothing for DMARC.

Variant 3: DKIM breaks in transit. Some organizations route outbound mail through intermediary services: email signature injection platforms, compliance archiving, DLP scanning. Each hop that modifies headers or body can break a DKIM signature. Even if DKIM was configured at the origin, it may not survive the journey to the recipient.

Why Nobody Notices

Auto-replies are invisible. Nobody reads their own out-of-office messages. Nobody monitors DMARC reports filtered by message type. Most DMARC reporting tools show aggregate pass/fail rates. A handful of failed auto-replies don’t move the needle when thousands of normal messages pass daily.

The failures are also intermittent. They only happen when someone has an active mailbox rule or vacation responder AND receives an email from outside the organization. The conditions aren’t constant, so the failures come and go.

This isn’t a new problem, either. A bit of searching turns up forum posts and support threads about Exchange auto-reply DMARC failures going back at least eight years. The issue has been known, discussed, and apparently forgotten — repeatedly — for nearly a decade. That alone tells you how invisible it is.

And the consequences are hidden. If the sender’s DMARC policy is quarantine, the auto-reply lands in the recipient’s spam folder. If it’s none, it passes through unaffected (the policy says to take no action on failures). If it’s reject… the auto-reply vanishes. The person who set up the vacation responder has no idea their out-of-office message is being silently dropped by half the internet.

The Irony

The companies I observed this in aren’t negligent. They’re running enterprise email stacks with dedicated outbound security gateways. They’ve set DMARC policies. They have SPF records. They’re doing more than most organizations do for email authentication.

They’re also paying for products whose job is to handle exactly this: outbound signing, policy enforcement, authentication. The gateway is right there in the mail path. It sees every message. It just isn’t signing them.

How to Check If You’re Affected

If you’re on Exchange (Microsoft 365) with an outbound gateway:

  1. Set up a mailbox rule that auto-replies to incoming messages (not a vacation responder — a mailbox rule, which uses the Mailbox Rules Agent)
  2. Send a test email from an external account
  3. Check the headers on the auto-reply

Look for:

  • Return-Path: <> — if the envelope sender is null, you’re in the risk zone
  • dkim=none or dkim=pass with a header.d that doesn’t match your domain
  • dmarc=fail

If your normal replies pass DMARC but your auto-replies fail, you have this misconfiguration.

If you’re on Google Workspace:

Google made a different design choice, and it’s worth understanding why it matters. I tested both auto-reply types against my own infrastructure:

  • Vacation responder: Return-Path: <user@domain.com> — envelope sender preserved. SPF aligns. DMARC passes.
  • Filter-based template reply: Return-Path: <user+canned.response@domain.com> — envelope sender preserved with a plus-address tag. SPF still aligns (plus-addressing doesn’t change the domain). DMARC passes.

Google tags the auto-reply type in the envelope sender instead of nulling it. The +canned.response suffix identifies the message as automated without destroying authentication. Same intent as a null return path (signal that this is a generated message), but implemented in a way that preserves DMARC alignment.

If you also have DKIM configured (through your outbound gateway or through Google directly), you have redundant authentication on both SPF and DKIM. You’re likely fine, but test anyway — trust and verify.

How to Fix It

The fix is straightforward: configure DKIM signing on your outbound email gateway for your domain.

If your outbound gateway is your SEG (Proofpoint, Mimecast, Barracuda, etc.):

  1. Generate DKIM signing keys in the gateway’s admin console
  2. Publish the public key as a DNS TXT record under your domain (e.g., selector._domainkey.yourdomain.com)
  3. Enable outbound DKIM signing for your domain
  4. Test with both normal emails and auto-replies

If you don’t have an outbound gateway and send directly from Exchange Online:

  1. Configure DKIM in the Microsoft 365 admin center with your custom domain
  2. Ensure the signing domain matches your From domain, not the .onmicrosoft.com default
  3. Publish the CNAME records Microsoft provides

If you route through intermediary services (email signature platforms, compliance tools):

  1. DKIM signing should happen at the last hop before the message leaves your infrastructure
  2. If the intermediary modifies the message body, any DKIM signature applied before it will break
  3. Configure signing after the intermediary, or ensure the intermediary re-signs

The Bigger Picture

This is a quiet failure with compounding consequences. Every auto-reply that fails DMARC is a legitimate message that gets quarantined, junked, or rejected. Your CEO’s out-of-office doesn’t reach the board member who emailed over the weekend. Your sales team’s vacation responders vanish into spam folders. Your support team’s auto-acknowledgments never arrive.

And if you ever move your DMARC policy from quarantine to reject, which is the end goal of any DMARC deployment, every one of those auto-replies stops being delivered entirely. Silently. With no bounce notification, because the return path is null.

Two standards, written years apart, with incompatible assumptions about how auto-generated messages should identify themselves. One platform followed the older standard to the letter. The result is a foundational authentication failure that only manifests on messages nobody monitors, with consequences nobody sees, on infrastructure that’s otherwise correctly configured.

The fix is one configuration change. Check your auto-replies.

If you’re seeing this in your own environment and want to talk through the fix, reach out. This is exactly the kind of invisible misconfiguration that keeps security teams up at night once they find it and that nobody finds until something important doesn’t get delivered.