Microsoft Trusted ARC Sealers in 2022: Forwarding Authentication Context

Anil Jalela · Published Jun 28, 2022 · 12 min read

Microsoft announced trusted Authenticated Received Chain sealers for Microsoft Defender for Office 365 on June 2, 2022. The feature addressed a specific mail-flow problem: a legitimate intermediary such as a forwarding service, discussion list or security gateway can change message content or routing, causing SPF, DKIM and therefore DMARC to fail at the final Microsoft 365 receiver. ARC can preserve the earlier authentication assessment in a cryptographically linked chain. A tenant may configure the necessary intermediary’s ARC signing domain as trusted so Microsoft can consider that preserved result. This is a narrow trust decision, not a switch that makes forwarded mail safe or repairs every authentication failure.

The dated mailbox-provider change

SPF evaluates the connecting source, so ordinary forwarding often substitutes an IP that is absent from the original sender’s SPF authorization. DKIM can survive forwarding, but mailing-list footers, subject tags and security transformations may break the signed body or headers.

DMARC passes when an aligned SPF or DKIM result passes. If both are damaged by an intermediary, a legitimate message can fail at the final receiver even though it authenticated at the first hop.

RFC 8617 standardized ARC as a chain of authentication results, message signatures and seals. Trust remains local to the final receiver because a valid chain only proves what a sealer asserted and preserved.

This event is best understood as a change in one layer of the email system. Transport acceptance, authentication, placement, interface presentation and user action remain different states. The article therefore records what Microsoft trusted ARC sealers changed and what it did not change.

How the system worked before the change

Microsoft 365 evaluated the modified message and could see failing SPF and DKIM without enough trustworthy context about the original handoff. The result might be junk, quarantine or rejection depending on policy and other signals.

Administrators sometimes created broad bypass rules for known services. Those rules could suppress useful filtering and were not tied to cryptographic chain validation.

Enhanced Filtering for Connectors helped in connector scenarios by recovering the original source IP, but it did not address every intermediary or content modification pattern.

Before Microsoft trusted ARC sealers, teams often had incomplete evidence because sender logs ended at SMTP acceptance while recipient-side behavior occurred inside Microsoft 365. That boundary matters: an accepted message can still be filtered, presented differently, ignored or acted upon later.

What changed on the provider side

A tenant could list the ARC signing domains of intermediaries it actually used and trusted. Microsoft would validate the ARC chain and could use the preserved authentication results in final evaluation.

The configured value had to match the d= domain in real ARC-Seal and ARC-Message-Signature headers. Adding the sender domain instead of the sealer domain did not model the trust path.

Microsoft recommended narrow use because a compromised trusted intermediary could assert preserved authentication for harmful mail. Chain validity, intermediary identity and continuing business need all mattered.

The implementation of Microsoft trusted ARC sealers created a new operating dependency, not a permanent entitlement. Senders still needed controlled rollout, supported fallbacks, reliable identity and evidence from the actual affected cohort.

Message path before and after

Before

Original sender passes SPF/DKIM/DMARC at first receiver
Intermediary changes IP or content -> SPF and DKIM fail downstream
Microsoft 365 sees DMARC failure -> junk, quarantine or reject risk

After

Original authentication -> intermediary records ARC-Authentication-Results
Intermediary adds ARC-Message-Signature + ARC-Seal with d= domain
Microsoft 365 validates chain + tenant trust entry
Preserved result informs, but does not dictate, final filtering

Who and what the change affected

Effect on delivery, placement and recipient visibility

ARC cannot rescue a message that never authenticated at the trusted hop. Inspect instance order, chain validation and preserved result rather than checking only for the presence of an ARC-Seal header.

For outbound marketers, correct DKIM that survives normal forwarding remains valuable. Do not intentionally rely on recipient tenants to trust every intermediary in the path.

For Microsoft trusted ARC sealers, ARC preserves an authenticated chain of custody through intermediaries that may alter a message. It does not make a failing message authentic by itself. The receiver decides whether the chain is valid and whether the sealer is trusted.

For Microsoft trusted ARC sealers, Trust only the signing domain shown in the intermediary’s ARC-Seal and ARC-Message-Signature d= values, after verifying real samples. Trusting the sender’s own domain or a broad collection of unused vendors expands the attack surface without solving the forwarding path.

For Microsoft trusted ARC sealers, ARC is most useful when a required service changes the source IP, body or headers and thereby breaks SPF, DKIM or DMARC. If the intermediary can avoid destructive modification, preserve DKIM, or use Enhanced Filtering for Connectors to recover the original source, those controls should also be evaluated.

Interpret Microsoft trusted ARC sealers at the smallest defensible unit: provider, recipient domain, stream, sending domain, DKIM identity, IP pool, campaign and time window. Portfolio averages can hide both a provider-specific regression and an improvement limited to one eligible surface.

Effect on measurement and diagnosis

Create before-and-after samples through each real intermediary. Record original authentication, modifications, ARC chain result, composite authentication and final location.

Monitor both false positives and false negatives. A fall in quarantine is not sufficient if spoof simulations begin reaching inbox because an overly broad sealer was trusted.

When measuring Microsoft trusted ARC sealers, Capture the complete Authentication-Results and ARC sets before and after the intermediary. A final pass alone cannot show whether Microsoft used preserved results, whether the chain validated or which hop introduced the break.

When measuring Microsoft trusted ARC sealers, Segment by intermediary, ARC sealer, chain validation, composite authentication result and final disposition. A reduction in quarantine after trust configuration is useful only if spoof detection and false-negative review remain clean.

Create an evidence contract before declaring the impact of Microsoft trusted ARC sealers. Name the event, collection point, population, numerator, denominator, latency, privacy boundary and owner. If any of those are unknown, label the conclusion as directional rather than causal.

Advantages for email marketers

Disadvantages and operational risks

What email teams needed to do at the time

1. Confirm the historical scope. Record the announced provider, date, clients and eligibility.
2. Inventory affected traffic. Map recipient domains, streams, identities and sending platforms.
3. Validate authentication. Check SPF, DKIM, DMARC alignment and TLS independently.
4. Build a safe fallback. Keep the message useful when the new surface is unavailable.
5. Test controlled mailboxes. Capture headers, screenshots, timestamps and outcomes.
6. Define measurement. Name populations, denominators, latency and privacy limits.
7. Stage the rollout. Change one bounded cohort and set stop conditions.
8. Brief support teams. Give them expected behavior and an escalation evidence pack.

What email teams should do now

1. Read the current provider documentation. Do not assume the 2020 to 2022 launch rules are unchanged.
2. Reconfirm eligibility and support. Test the exact clients, accounts and sending identities in use.
3. Keep authentication aligned. Monitor SPF, DKIM, DMARC and TLS as separate controls.
4. Preserve permission evidence. A presentation feature does not repair weak acquisition.
5. Segment provider traffic. Diagnose Microsoft 365 separately before changing global policy.
6. Protect suppressions and transactional streams. Do not let experimentation delay required state changes.
7. Retain raw evidence. Store message IDs, timestamps, headers, configuration and test results.
8. Use outcome metrics. Include clicks, conversions, complaints, opt-outs and support impact.
9. Review security and privacy. Limit data, endpoints, credentials and exceptions.
10. Maintain rollback. Name the owner and the threshold that returns traffic to the known-safe path.

Worked deliverability scenario

A company routes inbound mail through an external security service that rewrites links and then sends the message to Microsoft 365. DKIM breaks, the service becomes the SPF source and legitimate partner mail fails DMARC.

The administrator captures headers, confirms that the service produces a valid ARC chain and extracts its documented d= signing domain. Only that domain is added as a trusted sealer; unrelated vendor domains are excluded.

Test messages show preserved authentication being considered while spoof tests still fail. The entry receives an owner, vendor dependency record and removal procedure for contract termination.

The decisive improvement for Microsoft trusted ARC sealers is operational: the team separates provider evidence from assumptions, changes one controlled variable, records a rollback threshold and waits for a complete observation window. That prevents a visible interface change from becoming an excuse for unrelated domain, volume or creative changes.

Evidence and diagnostics

• Message identity: RFC 5322 From, envelope sender, DKIM domain and selector.
• Transport: connecting IP, TLS result, SMTP response and provider timestamp.
• Authentication: SPF, DKIM, DMARC and ARC results from the received header.
• Eligibility: provider registration, tenant setting, certificate or supported-client state.
• Rendering: raw MIME, fallback, screenshots and client version.
• Recipient scope: provider domain, account type, geography and app surface.
• Behavior: clicks, replies, conversions, complaints and unsubscribes.
• Change record: deployment time, owner, cohort, configuration diff and rollback threshold.
• Comparison: unaffected control cohort with the same purpose and acquisition source.

Failure modes and incorrect conclusions

• Equating SMTP acceptance with inbox placement. These are separate receiver decisions.
• Calling a provider UI change a reputation penalty. Verify transport and folder evidence first.
• Removing the fallback. Support and eligibility are never universal.
• Changing IP, domain, creative and cadence together. The test becomes uninterpretable.
• Trusting opens as the only outcome. Collection and privacy controls distort them.
• Ignoring the recipient denominator. Portfolio averages conceal provider-specific effects.
• Keeping permanent exceptions. Unowned allow lists and credentials accumulate risk.
• Using launch documentation as current policy. Recheck the maintained provider page.

Current status and superseding changes

Microsoft continues to document trusted ARC sealer configuration in the Defender portal and Exchange Online PowerShell. Current guidance emphasizes using the feature only when necessary intermediaries modify messages.

Set-ArcConfig operations can replace the existing collection if used carelessly. Automation must read current state, make the intended add or remove operation and verify the complete resulting list.

ARC complements rather than replaces SPF, DKIM and DMARC. Direct mail should still authenticate normally, and intermediary services should minimize destructive changes.

Current behavior for Microsoft trusted ARC sealers must be checked again before a production change because provider documentation, client support and eligibility can evolve. The dated event remains useful as a historical control point, while the linked current documentation governs present operation.

A production runbook for Microsoft trusted ARC sealers should contain more than a setup instruction. Record the business purpose, accountable owner, approved sending identities, affected recipient population, prerequisites, evidence sources, known unsupported paths, rollout cohort, stop threshold and rollback method. Attach a dated configuration export or DNS answer instead of relying on a screenshot with no timestamp. Review the runbook after an ESP, gateway, domain, certificate, mailbox client or provider policy changes.

Incident handling for Microsoft trusted ARC sealers should begin with a narrow comparison. Select one affected message and one known-good message with the same stream and nearby time. Compare SMTP responses, authentication results, raw MIME, provider or tenant eligibility, client presentation and downstream action. Widen the query only after identifying the first state where their paths differ. This is faster and safer than changing sending IPs, From domains and creative together.

Ownership for Microsoft trusted ARC sealers must cross organizational boundaries. Deliverability owns provider evidence and traffic controls; engineering owns MIME, APIs and event integrity; security owns trust and endpoint risk; privacy owns collection and retention; marketing owns permission, promise and cadence; support owns recipient-facing explanations. A launch is incomplete when any team lacks the evidence required to distinguish expected behavior from failure.

Evidence for Microsoft trusted ARC sealers also needs a retention rule. Keep enough raw headers, configuration history and aggregate outcome data to investigate a delayed complaint or regression, but do not retain recipient-level data merely because it was convenient during launch. Limit access by role, document the permitted purpose, remove expired exports and preserve only the minimum artifacts needed to reproduce the operational conclusion.

Finally, retain a negative control for Microsoft trusted ARC sealers. Send a technically valid message that is intentionally outside the feature’s eligible condition, while keeping purpose and audience comparable. The difference shows whether Microsoft 365 is applying the feature where expected. It also prevents teams from interpreting an unrelated seasonal, audience or reputation shift as proof that the feature caused the result.

Operator checklist

• Record the exact historical event date and source.
• Document what changed and what explicitly did not change.
• Map affected providers, domains, clients and account types.
• Validate SPF, DKIM, DMARC alignment and TLS.
• Keep a complete, accessible fallback message.
• Test with raw headers and controlled recipient accounts.
• Separate acceptance, placement, presentation and action metrics.
• Name every numerator, denominator and observation window.
• Monitor complaints, opt-outs and downstream outcomes.
• Set rollout ownership and rollback thresholds.
• Revalidate the current provider requirement before deployment.

Primary and contemporaneous references

• Microsoft Defender Blog: Trusted ARC Sealers: Primary evidence used to verify the dated event or current operating requirement.
• Microsoft Learn: Configure trusted ARC sealers: Primary evidence used to verify the dated event or current operating requirement.
• RFC Editor: RFC 8617 Authenticated Received Chain: Primary evidence used to verify the dated event or current operating requirement.

Related NitWings guides

• Authenticated Received Chain Guide
• Email Header Analysis
• DMARC Reports Analysis