Microsoft hosted Exchange, part of the Microsoft Office 365 suite, is found to leak the domain name of
bcc addresses to all recipients.
This leak may cause unintended disclosure of recipients of an email message.
Mailhardener was able to reproduce and confirm the leak. In this article we'll perform an in-depth analysis.
On May 3rd 2021, a report was published on Reddit by user 'botje_nl' claiming to have discovered a data leak in Microsoft's Office 365 products where under specific circumstances the domain of a
Bcc receiver may be leaked to all recipients of the email.
In the Reddit thread, it is reported that Microsoft Exchange adds the
Authentication-Results header to all outgoing email messages sent with Office 365.
Authentication-Results header, the domain name of the first receiver's email address is disclosed.
In email messages where no
cc address is used, this results in the domain name of a
bcc address to be disclosed unintentionally in the header.
Mailhardener was able to reproduce, and confirm the reported behaviour within a hosted Exchange instance.
For email messages that exclusively use
bcc recipients (where the
cc addresses are left empty) this results in unintended disclosure of the
bcc domain name to all recipients.
From: email@example.com To: [empty] Cc: [empty] Bcc: firstname.lastname@example.org, email@example.com Subject: Some information you'd be interested in...
As shown in the report, the following
Authentication-Results header is then added to the outbound email, exposing the
Bcc domain (
authentication-results: amnesty.com; dkim=none (message not signed) header.d=none;amnesty.com; dmarc=none action=none header.from=mydomain.com;
If we analyze the header in the example above, we see that the bcc domain (
amnesty.com in the example) actually occurs twice in the header.
header.dvalue. Though the value is malformed as
The result is that the receiver at
firstname.lastname@example.org can see that a copy of this email was also sent to an
The leak appears to only happen in hosted Exchange services (part of the Office 365 suite), Microsoft's other hosted email service live.com and hotmail.com appear unaffected.
At Mailhardener we were successful in reproducing the behaviour as reported on the original Reddit thread.
This header in question is not supposed to be added to outbound email by Exchange, nor is it supposed to contain any information on the receivers (whether it is
In total, we were able to identify four distinct issues:
Authentication-Resultsheader is normally added by the receiving SMTP server on inbound email. It isn't supposed to be added by the sending system to outbound email.
Authentication-Resultsheader reports the authentication results on the sender (
from) address, the receivers addresses (whether it is
bcc) are not supposed to be used in the
Authentication-Resultsheader (optionally) identifies which party performed the authentication, known as the
authserv-id. This should be the name of the email service that added the header. Exchange adds the domain of the
Bccreceiver here, which is also incorrect.
Authentication-Resultsheader is malformed, the
header.d=none;amnesty.comwill cause parsing issues.
Though these are 4 separate issues, they are probably all due to the same bug, that is that the software routine that creates the header is erroneously called on outbound email.
Authentication-Results header is defined in RFC7601.
The RFC uses the term 'producer' for the service that adds the header to the email.
Simply put, a transfer from the producer of the header field to the consumer must occur within a context that permits the consumer to treat assertions by the producer as being reliable and accurate (trustworthy). How this trust is obtained is outside the scope of this document. It is entirely a local matter.
The sender cannot be considered 'trustworthy', as the whole point of the header is to verify the authenticity of the sender.
Exchange is adding
Authentication-Results to outbound email, which should be considered a bug.
The domain that is used in the header (
amnesty.com in the example above) is known as the
authserv-id value in the RFC.
Every Authentication-Results header field has an authentication service identifier field (authserv-id above). Specifically, this is any string intended to identify the authentication service within the ADMD that conducted authentication checks on the message. This identifier is intended to be machine-readable and not necessarily meaningful to users.
The authserv-id should contain the name of the service that performs the authentication within the Administrative Management Domain (ADMD).
As seen in the example above, Exchange uses the (bcc) domain name as authserv-id, which is incorrect.
With correct usage, the receiver should have added the header, and should have used their own identity (for example
mx.google.com for G-suite users) as the authserv-id.
According to the original reporter 'botje_nl' on the Reddit forums, Microsoft responded with the following statement:
Thank you for reporting this issue to the Microsoft Security Response Center (MSRC). Unfortunately we were unable to reproduce your findings following the steps outlined in your report. As such, this email thread has been closed and will no longer be monitored.
Mailhardener has since re-issued a disclosure to Microsoft, we have yet to receive a response.
The following workaround is proposed by the reporter:
As an admin, you should add the following rule to remove such headers on outbound e-mail: 1. Open Exchange Admin Center 2. Go to mail flow, rules 3. Add new rule: Apply to all messages Remove header: Authentication-Results.
When applied to the outbound email this rule should not affect email functionality, as the
Authentication-Results is not supposed to be added to outbound email anyway.
At Mailhardener we have been able to reproduce this bug, and we can confirm that cloud-hosted variant of Microsoft Exchange (part of the Office 365 suite) does indeed leak the domain name of a
bcc address when no other addresses (
cc) are used.
This can result in unintended disclosure of recipients.
Microsoft's hosted Exchange service seems to suffer from 4 separate bugs in production:
Authentication-Resultsheader is erroneously added to outbound email, where it should be added by receivers on inbound email.
Authentication-Resultsheader, where it is intended to verify the authentication of the sending party.
Authentication-Resultsheader, where this should be the identifier of the party that added the header.
Authentication-Resultsheader that is (erroneously) added to outbound email is malformed and likely rejected by any receiver.
Mailhardener advises users of Microsoft hosted Exchange (part of the Office 365 suite) to use
bcc recipients with caution until Microsoft addresses this issue.
If true separation of receivers of an email is desired, consider sending the messages separately with one recipient each.