Microsoft published updated documentation in late March addressing how Outlook handles ARC (Authenticated Received Chain) sealed mail. The update formalizes practices that had been developing through 2025 but had not been documented prescriptively. The trusted ARC sealer concept becomes operationally important. Specific configuration requirements emerge for organizations whose mail passes through intermediaries.
For most senders, the update does not change immediate behavior. For mailing list operators, ESP customers using complex routing, and organizations with email security gateways, the update has operational implications worth understanding.
This post is what changed, what it means for different sender profiles, and what the operational response should look like.
What the update specifies
The Microsoft documentation update covers several specific areas.
Trusted ARC sealer concept
Outlook maintains a list of ARC sealers it explicitly trusts. Mail that passes through a trusted sealer can have authentication credit preserved even when intermediate modifications would otherwise break SPF and DKIM.
The trusted list includes major mailbox providers (Google, Yahoo, Apple), major email security vendors, and other established intermediaries. Smaller or unknown ARC sealers do not get automatic trust.
Microsoft 365 administrators can configure their tenant to trust additional ARC sealers. The configuration is done through PowerShell commands or admin portal. The customization allows organization-specific trust based on legitimate business intermediaries.
Configuration mechanism
The trusted ARC sealer configuration uses the Set-ArcConfig PowerShell command. The command adds sealer domains to the tenant’s trust list. The domains are specified in the format used by ARC seals.
For example, an organization receiving mail through a specific email security gateway might add that gateway’s ARC sealer domain to their trust list. Mail processed by the gateway then maintains ARC credit through the receiver.
The configuration is per-tenant. Different Microsoft 365 tenants can have different trust configurations based on their specific intermediary relationships.
Outbound implications
Microsoft 365 outbound mail can be sealed with ARC if appropriate. Organizations operating as intermediaries (forwarding mail, providing email security, running mailing lists) can be ARC sealers for their own outbound flow.
The outbound ARC sealing requires configuration. The configuration involves DKIM-like key generation, DNS publication, and Microsoft 365 admin portal configuration.
Validation behavior
Outlook’s inbound mail processing now explicitly validates ARC chains for mail that would otherwise fail DMARC. The validation:
Checks the ARC chain’s cryptographic validity. The seals must be cryptographically valid.
Identifies the first trusted sealer in the chain. The earliest trusted sealer provides the authentication credit.
Uses the trusted sealer’s records to determine the original authentication results.
Applies the authentication credit to the DMARC decision.
The validation happens automatically for all inbound mail. The trusted sealer list determines which ARC chains receive credit.
What this means for different sender profiles
The implications vary by sender profile.
Standard senders without intermediaries
Direct senders without intermediate processing are unaffected by the update. Their mail goes from sender to receiver without ARC involvement. Standard SPF, DKIM, DMARC continue to apply.
For these senders, no action is required. The update does not change their operational reality.
Mailing list operators
The most directly affected segment. Mailing list operators who implemented ARC sealing for their forwarding (as recommended in our earlier post on ARC) benefit from the formalization.
For mailing lists whose sealer is on Microsoft’s trusted list, their forwarded mail receives appropriate authentication credit at Outlook recipients. For mailing lists whose sealer is not on the trusted list, the ARC implementation may not produce immediate Outlook benefits.
Mailing list operators should:
Verify whether their ARC sealer domain is on Microsoft’s trusted list. The list is documented in Microsoft’s articles on the topic.
For sealers not on the list, consider whether their recipient base has corporate Microsoft 365 customers who could configure their tenants to trust the sealer.
For sealers with significant recipient impact at Microsoft, work with Microsoft through their established processes to consider inclusion on the standard trusted list.
Email security gateway operators
Email security gateways that process inbound mail before delivery to organizational mailboxes can be ARC sealers for the mail they forward.
For gateway operators, the update formalizes practices that have been operationally important. Organizations choosing email security gateways should consider whether the gateway’s ARC sealing is properly recognized at major receivers.
Forwarding service operators
Services that forward mail (corporate forwarders, university forwarders, similar) face the same considerations as mailing list operators. The ARC implementation enables forwarded mail authentication preservation.
The operational question: is the forwarder’s ARC sealer recognized at the destination receivers?
ESP customers using complex routing
Some ESP customers route mail through multiple intermediate systems for various business reasons (segmentation, analytics, content processing). Each intermediate is a potential ARC sealing point.
The cumulative ARC chain through multiple intermediates can be complex. Microsoft’s documentation provides guidance on how Outlook handles complex chains.
Microsoft 365 administrators
Organizations running Microsoft 365 with specific intermediary relationships (email security vendor, parent company mail filter, etc.) can now formally configure trust for their specific intermediaries.
The configuration is straightforward but requires understanding of which intermediaries are relevant for the organization. The configuration is per-tenant; administrators need to understand their organization’s mail flow.
The technical configuration details
For Microsoft 365 administrators implementing the configuration:
# Get current ARC configuration
Get-ArcConfig
# Add a trusted ARC sealer
Set-ArcConfig -ArcTrustedSealers "intermediate-service.example.com"
# Add multiple trusted sealers
Set-ArcConfig -ArcTrustedSealers @("intermediary1.example.com", "intermediary2.example.com")
# Remove trusted sealers (specifying only the ones to keep)
Set-ArcConfig -ArcTrustedSealers @("intermediary1.example.com")The PowerShell command modifies the tenant’s ARC configuration. The change takes effect within minutes of execution.
Validation that the configuration is active:
# Verify current configuration
Get-ArcConfig | Select-Object ArcTrustedSealersFor administrators using the GUI rather than PowerShell, the configuration is available in the Microsoft 365 Defender portal under Email & Collaboration → Policies & Rules → Threat Policies → Email Authentication Settings → ARC.
What we recommend for affected sender profiles
Based on the update implications:
For mailing list operators
Verify your ARC sealer status with Microsoft. Documented sealers receive proper credit at Outlook recipients. Undocumented sealers may not.
If your sealer is not on Microsoft’s standard list, evaluate whether your recipient base includes significant Microsoft 365 corporate accounts. If yes, consider engagement with Microsoft about sealer recognition.
For mailing lists with primarily personal Outlook recipients (Outlook.com, Hotmail.com), the trust evaluation follows different paths than corporate Microsoft 365. Personal Outlook trust is based on Microsoft’s broader sealer evaluation.
For email security gateway customers
Verify that your security gateway’s ARC sealing is properly configured. The gateway should be sealing outbound mail with ARC, and the seal should be recognized at destination receivers.
For Microsoft 365 destinations, the gateway’s sealer should either be on Microsoft’s standard trusted list or your tenant should be configured to trust it.
For Microsoft 365 administrators
Audit your organization’s mail flow. Identify legitimate intermediaries that process inbound mail before delivery.
For each legitimate intermediary, evaluate whether their ARC sealing is producing proper authentication credit. If not, consider configuring trust for the specific sealer.
Document the trust configuration. Future administrators need to understand the configured trust relationships.
For ESP customers
Verify how your ESP handles ARC for various sending scenarios. Some ESPs are ARC-aware and seal outbound mail with their own ARC. Others do not.
For ESPs that do not currently support ARC, the operational impact depends on whether your mail goes through other intermediaries that would benefit from ARC.
What this update does not change
Several aspects continue as before.
Standard authentication requirements
SPF, DKIM, and DMARC requirements continue. The ARC update is additive rather than replacing the existing requirements.
Bulk sender requirements
Microsoft’s May 2025 bulk sender requirements continue. The 5,000 messages per day threshold, authentication requirements, complaint rate thresholds all apply.
Direct sender practices
For senders without intermediary involvement, the operational practices continue. Authentication setup, sending discipline, complaint rate management all remain critical.
Cross-receiver consistency
The update is Microsoft-specific. Gmail and Yahoo handle ARC similarly but with their own trusted sealer lists. The operational implications transfer broadly but specific configurations differ per receiver.
What we have changed for our customer base
Following the update:
Documentation updates
Our customer documentation for mailing list and forwarding scenarios has been updated to address the new Microsoft specifications. Customers operating mailing lists understand the implications.
ARC implementation review
For customer mailing list operations we manage, we have reviewed the ARC implementations against the new specifications. Configuration improvements identified and implemented.
Trusted sealer status
For our own sealer domains (used in customer-facing infrastructure), we have engaged with Microsoft’s processes for sealer recognition. The engagement is bounded but worthwhile for our customer base.
Customer education
We have communicated with customers running affected scenarios (mailing lists, forwarding services, complex routing). The communication explains the changes and operational implications.
Configuration assistance
For customers running Microsoft 365 with specific intermediary relationships, we provide configuration assistance to ensure trusted sealer configuration matches their operational reality.
The broader pattern this reflects
The Microsoft update fits into a broader pattern of authentication evolution.
Authentication mechanism layering
The basic authentication mechanisms (SPF, DKIM, DMARC) work for direct senders. Additional mechanisms (ARC) address forwarding scenarios. Each layer addresses specific use cases.
The layered architecture continues evolving. New mechanisms may emerge for specific scenarios that current layers do not address.
Trust list mechanics
The trusted sealer concept reflects a broader pattern of trust mechanics in email infrastructure. Major receivers maintain lists of trusted entities (BIMI Mark Verification Authorities, ARC sealers, etc.). The lists determine what authentication credit is given.
The trust list mechanics create asymmetry between established and new entities. Established entities receive automatic trust; new entities face longer paths to recognition.
Configuration complexity
The configuration to operate properly in this ecosystem continues becoming more complex. Tenant-level configuration for trusted sealers, ESP-level configuration for ARC, sender-level configuration for authentication all combine.
The operational discipline required exceeds what casual senders can maintain. Specialist providers (us and similar) become more valuable for sustained operations.
Cross-receiver convergence
The major receivers continue converging on similar practices. ARC handling is now consistent across Gmail, Microsoft, Yahoo (with receiver-specific configurations). The convergence is operationally helpful.
What we expect over coming months
Looking forward from April 2026:
Other receivers may publish similar documentation updates. Yahoo or Apple may formalize their ARC handling specifications more explicitly.
The trusted sealer lists may expand. New intermediaries may be added through Microsoft’s evaluation processes.
ESP support for ARC may improve. ESPs not currently supporting ARC well may add better support as the operational importance becomes clearer.
The configuration mechanisms may simplify. Current PowerShell-based configuration may receive UI improvements in Microsoft 365 admin portals.
Industry tools may emerge for managing ARC across multiple receivers. Currently, each receiver requires its own configuration; tools that abstract this complexity may emerge.
What does not work despite expectations
Several approaches some operators try that do not work as expected.
Self-declaring as trusted sealer
An operator publishing themselves as ARC sealer does not automatically receive trust. The trust is conferred by receivers, not by the sealer.
For Microsoft specifically, self-configured trust by Microsoft 365 tenants works for that tenant only. Broader trust requires Microsoft’s evaluation.
Excessive sealing
Adding multiple ARC seals to mail does not produce additional credit. The first trusted sealer in the chain provides the credit. Additional seals after the first trusted one are unnecessary.
Sealing without proper key management
ARC sealing without proper DKIM key management produces invalid seals. The seals do not provide credit at receivers. The configuration cost without operational benefit.
Sealing for wrong purpose
ARC is for preserving authentication through intermediate modifications. Senders without intermediate modifications do not benefit from ARC. Adding ARC to direct sending flow is unnecessary configuration.
The operational summary
For our customer base, the practical implications:
Most customers are unaffected. Direct senders with proper SPF/DKIM/DMARC continue operating normally.
Customers operating mailing lists or forwarding services should verify their ARC implementation aligns with current receiver expectations. The work is bounded but specific.
Customers running Microsoft 365 with specific intermediary relationships should evaluate trusted sealer configuration. The configuration is straightforward but requires understanding of mail flow.
Customers using ESPs should verify their ESP’s ARC support is appropriate for their sending patterns.
The update is operationally manageable. The changes formalize practices that were developing through 2025. The operational discipline required is bounded.
What we tell new customers about this
For new customers asking about ARC implications:
Direct sending does not require ARC. Standard authentication suffices for direct sender-to-receiver mail.
Intermediate processing requires ARC consideration. Mailing lists, forwarding, security gateways, complex routing all involve ARC implications.
Microsoft 365 with intermediaries can be specifically configured. The configuration is part of operational discipline for organizations with specific intermediary relationships.
The configuration is documented but requires understanding. We provide consultation for customers needing to configure complex scenarios.
The longer-term trajectory
Email authentication continues evolving. The April 2026 Microsoft update is one step in continuing evolution.
The trajectory continues toward more sophisticated authentication handling. Each receiver-side improvement requires sender-side awareness. The cumulative discipline required to operate well across all major receivers continues growing.
For sustained operations, the path is operational discipline rather than reactive crisis response. Senders who treat email infrastructure as ongoing operational practice continue producing good outcomes. Senders who treat it as periodic crisis management see degrading outcomes.
The April 2026 update is operationally manageable. Future updates will be similarly bounded. The cumulative effect of multiple updates over years is significant. Senders who keep current produce sustainable operations. Senders who fall behind face accumulating remediation work.
We continue working with customers across all affected segments. The technical implementations are bounded. The operational discipline is sustained. The customer relationships built through this kind of ongoing operational quality compound over time.
For other operators reading this with mailing list, forwarding, or complex routing scenarios: the update is operationally meaningful. The work to address it is bounded. The benefit of addressing it is sustained deliverability at Microsoft consumer and corporate destinations. The investment is justified for affected operations.
The standard authentication infrastructure remains the foundation. ARC is the additional layer for specific scenarios. Trusted sealer configuration is the operational refinement. Each layer is bounded individually; the cumulative discipline is the operational reality of email infrastructure in 2026.
Email infrastructure continues becoming more sophisticated. The customers we work with who have been investing in operational quality continue to be the ones operating successfully. The path forward continues to be operational discipline rather than shortcut-seeking. The April 2026 update is one more validation of this operational philosophy.