An important part of Microsoft's anti-spoofing protection technology is the introduction of Composite Authentication. Microsoft created Composite Authentication to help identify spoofed senders and phishing email when senders do not use SPF, DKIM, and DMARC authentication. It is primarily used by Microsoft when sending to Office 365 users, but it may also appear when sending to Outlook.com users. For additional information on Microsoft's anti-spoofing technology, please read:
When Composite Authentication is used on an email, the results are placed in the Authentication-Results email header using the "compauth" and "reason" tags. A compauth=fail result means Microsoft classifies your email as spoofed.
Authentication-Results: compauth=<value> reason=<value>
Authentication-Results: spf=none (sender IP is XX.XX.XXX.X) smtp.mailfrom=example.net; hotmail.com; dkim=none header.d=example.net;hotmail.com; dmarc=none action=none header.from=example.net;compauth=fail reason=001
How to locate the Authentication-Results header in Everest
- Login to Everest
- Navigate to In-Flight>Inbox Placement>Inbox Tests
- Click the subject line of a campaign listed in the Inbox Tests section
- Click the details arrow on the far right side for Hotmail or Office 365. Ensure that they do not have 100% missing seeds. You cannot view headers for missing seeds.
- Click the details arrow on the far right side under the Headers column for any seed address with Inbox or Spam placement.
Composite Authentication Charts
|fail||Message failed explicit authentication (sending domain published records explicitly in DNS) or implicit authentication (sending domain did not publish records in DNS, so Office 365 interpolated the result as if it had published records).|
|pass||Message passed explicit authentication (message passed DMARC, or Best Guess Passed DMARC) or implicit authentication with high confidence (sending domain does not publish email authentication records, but Office 365 has strong backend signals to indicate the message is likely legitimate).|
|softpass||Message passed implicit authentication with low-to-medium confidence (sending domain does not publish email authentication, but Office 365 has backend signals to indicate the message is legitimate but the strength of the signal is weaker).|
|none||Message did not authenticate (or it did authenticate but did not align), but composite authentication not applied due to sender reputation or other factors.|
|0xx||Message failed composite authentication.
000 means the message failed DMARC with an action of reject or quarantine.
001 means the message failed implicit email authentication. This means that the sending domain did not have email authentication records published, or if they did, they had a weaker failure policy (SPF soft fail or neutral, DMARC policy of p=none).
002 means the organization has a policy for the sender/domain pair that is explicitly prohibited from sending spoofed email, this setting is manually set by an administrator.
010 means the message failed DMARC with an action of reject or quarantine, and the sending domain is one of your organization's accepted-domains (this is part of self-to-self, or intra-org, spoofing).
|1xx, 2xx, 3xx, 4xx, and 5xx||Correspond to various internal codes for why a message passed implicit authentication, or had no authentication but no action was applied.|
|6xx||Means the message failed implicit email authentication, and the sending domain is one of your organization's accepted domains (this is part of self-to-self, or intra-org, spoofing).|