AuthMechanism 10 and AuthAs Internal: How Exchange Classifies Message Submission in the Header

When analyzing spam, spoofing, and mail flow cases in Exchange environments, three headers stamped by Exchange upon receipt are crucial:

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthSource: EX01.example.com
X-MS-Exchange-Organization-AuthMechanism: 10

AuthAs records how the sender presented itself to transport. AuthSource identifies the server that performed the evaluation. AuthMechanism documents the mechanism through which authentication was established. Together, they determine whether Exchange treats a message as internal or external, and this classification has significant consequences.

Why the classification matters

AuthAs has two values in practice: Internal and Anonymous. A message classified as Internal is handled differently from external mail:

• Mail flow rules with the condition “sender is outside the organization” do not apply.
• The message can be delivered to distribution groups and mailboxes that require authenticated senders (RequireSenderAuthenticationEnabled).
• Anti-spam and anti-spoofing checks are less strict or omitted; in hybrid environments, the external disclaimer is not appended and Outlook does not display an “External” indicator.
• The display name is resolved from the address book, making the email appear to recipients as internal mail.

That is precisely why the question “AuthAs Internal or Anonymous?” should be at the start of every header analysis: It helps clarify why an obvious spoofed email passed the spam filter or why a mail flow rule never triggered.

The AuthMechanism values

Microsoft does not fully document the encoding of AuthMechanism publicly. Two values are relevant for troubleshooting and well documented:

Other values appear in headers but have no official reference. In practice, the distinction is sufficient: 04 means genuine Exchange authentication; 10 means trust based on connector configuration.

What Externally Secured really means

The ExternalAuthoritative option on a Receive Connector tells Exchange: Someone else handles securing this connection, such as a firewall, a dedicated network segment, or IPsec. Exchange then performs no further checks and treats every submission through this connector as authenticated and internal, including the right to use any internal sender addresses.

This is intended for only a few scenarios, such as a fully trusted application server in your own data center. It becomes problematic when the connector points to an upstream mail gateway or spam filter in the DMZ through which Internet mail also arrives. Every external email then carries the following after submission:

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 10

The consequences: External emails are considered internal, mail flow rules for external senders do not apply, spoofing protection for the organization’s own domain is ineffective, and anyone who can reach the gateway can deliver using internal sender addresses to recipients that actually require authenticated senders.

Finding affected connectors

The Exchange Management Shell shows which Receive Connectors are configured with ExternalAuthoritative:

Get-ReceiveConnector | Where-Object {
  $_.AuthMechanism -match "ExternalAuthoritative"
} | Format-Table Identity, RemoteIPRanges, AuthMechanism, PermissionGroups

For each result, check which RemoteIPRanges are configured and whether the systems behind them actually need this trust. A gateway that only needs to relay mail does not.

The alternative for relay scenarios

If a system only needs to relay anonymously through Exchange (printers, applications, monitoring), an anonymous relay connector is the cleaner solution: anonymous submission plus the right to deliver to any recipients, but without the Internal classification.

New-ReceiveConnector -Name "Anonymous Relay" -TransportRole FrontendTransport `
  -RemoteIPRanges 192.0.2.10 -Bindings 0.0.0.0:25 -Usage Custom -PermissionGroups AnonymousUsers

Get-ReceiveConnector "EX01\Anonymous Relay" | Add-ADPermission `
  -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

Emails through this connector remain AuthAs: Anonymous, undergo the usual checks, and cannot spoof internal senders. ExternalAuthoritative should be reserved for systems to which you deliberately want to grant the right to use internal sender addresses.

Reading headers in context

The fastest way to determine whether a specific message was classified as internal or external and how it arrived is to examine the complete header: AuthAs, AuthMechanism, and AuthSource together with the Received chain. The Mail Header Analyzer on this website evaluates these fields directly in the browser and highlights the hybrid classification in the delivery path; the header does not leave the browser.

The article Internal or external? Classifying Exchange hybrid emails in the header explains how the classification is retained between Exchange Online and OnPrem in hybrid environments and how to identify an incorrect assignment.