## TL;DR
Make the secondary path stamp and preserve authentication results like the primary path does: confirm which system is the final internal hop for backup MX mail, enable its Authentication-Results stamping, and stop any downstream hop from stripping it. Mail through a secondary MX often enters through a different gateway or an older server that never learned to add the header your filters and DMARC reporting expect.

```text
"authentication-results" header missing on mail delivered through secondary mx
```

## Use this when
- Mail delivered via the primary MX carries Authentication-Results, mail via the secondary MX does not.
- Filters or reporting tools treat the secondary MX mail as unauthenticated or unknown.
- The secondary MX is a backup gateway, an old server, or a provider store and forward service.

## Not for this skill when
- Authentication-Results is present but shows fail values. Fix the authentication itself, not the stamping.
- You need authentication results for outbound mail. Receivers stamp their own; you cannot add theirs.

## Steps
1. Send controlled tests that arrive through each MX by temporarily preferring the secondary, and save the delivered headers for both. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: a primary copy with the header and a secondary copy without it are captured
2. Identify the final trusted hop for the secondary path and check its stamping settings and its authserv-id value. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the system that should stamp the secondary path is named
3. Enable stamping on that hop, or route secondary MX delivery through the same gateway that stamps primary mail. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the configuration change is saved on the stamping hop
4. Check that no later hop strips or overwrites the header, especially older Exchange servers or hygiene appliances in that path. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the delivered secondary copy retains the header end to end
5. Repeat the secondary MX test and read the delivered message. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the new secondary copy carries Authentication-Results with the expected authserv-id and verdicts

## Why it happens
Authentication-Results is added by the receiving organisation border system so downstream filters can trust the verdicts. Backup MX paths are often built years apart from the primary path, with different products and defaults, and a store and forward provider may deliver through a back door connector that bypasses the stamping gateway entirely. The mail was authenticated; the evidence just never got written onto the copy your tools read.

## Variants and edge cases
### authentication-results header missing secondary mx backup gateway
The path specific phrasing comparing the two MX routes.
### mail through backup mx no authentication results header stamping
The stamping action variant for gateway configuration.
### dmarc reporting wrong secondary mx mail unauthenticated header
The reporting impact variant when DMARC tools misread the mail.

Compatibility: RFC 8601 Authentication-Results, Exchange Online and on premises gateways, backup MX providers.

Edge cases to check:
- Filters should only trust Authentication-Results with your own authserv-id; a missing header and a foreign header need different handling.
- Test the secondary path regularly; it is the path most likely to drift because it carries almost no daily traffic.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fRjuuHh_MvYjY4K2SP6P0A