Avanan: Uncovering Mystery Email Volume
During the review of your domain’s DMARC data, you may come across something puzzling: large numbers of emails sent on behalf of your domains from IPs that resolve to *.cloud-sec-av.com, most of which typically fail DMARC. More concerning is that all of this data, reported by Microsoft, might state that the emails were rejected.
You may be wondering why there are so many emails from these servers spoofing your domain or if your domain is being spoofed to defraud unsuspecting recipients. Fortunately, there is a reason, and it highlights a unique Microsoft behaviour worth noting.
What is Avanan?
Check Point Avanan is a cloud-based email security service used by organizations on Microsoft 365. In its most common inbound deployment “Protect (Inline) Mode,” Avanan does not change the recipient’s MX record; Microsoft 365 remains the public MX. Instead, Avanan plugs into the Exchange Online mail flow internally via connectors and transport rules inside the recipient’s M365 tenant.
DMARC noise
When you receive an email, it follows this path:
- Your mail server delivers the message to the recipient’s MX, meaning Microsoft 365. M365 will perform all inbound email authentication (DMARC, SPF, DKIM) and email security checks it is configured to do.
- M365 transport rules route the message out of the recipient tenant to Avanan’s scanning infrastructure for malware, phishing, and data loss prevention (DLP) analysis. This process can sometimes rewrite URLs, strip attachments, inject banners, or otherwise modify the body of the original email. This is important in regards to the survivability of any existing DKIM signatures.
- Avanan releases the now-modified message back into the recipient’s M365 tenant from its own IP ranges (*.cloud-sec-av.com).
- M365 receives the message a second time, and re-runs authentication checks (SPF, DKIM, DMARC) against this re-entry. The second authentication check is what you are seeing in your DMARC reports.
Microsoft’s Misleading Reporting
How Microsoft reports DMARC verification checks often leads to confusion among customers. If your domain is enforcing DMARC with a policy of either quarantine or reject, the reports will often state that DMARC failed and the disposition of the email will reflect your published enforcement policy.
That disposition is not what actually happened to your mail.
Your message was delivered to the user!
Avanan’s IPs are whitelisted at the connection level to ensure delivery, but Microsoft not only performs a DMARC check anyway, it also reports what the disposition would be without the whitelist in place. DMARC reports contain a mechanism for reporters to indicate why they may apply a disposition different from your published policy. This is done via the “Override Reason” and “Override Comment” features of the aggregate report, features that Microsoft notably does not use.
What should you do about it?
Nothing.
There is no useful action available to you as the sending domain owner. In particular:
- Don’t add Avanan’s IPs to your SPF record unless you own and use Avanan yourself.
- Don’t change your DMARC policy for indirect mail flow. Despite what it states, there are no actual email failures, and it is highly recommended not to take action. These DMARC failures are caused by the relaying of emails by infrastructures outside of your administrative boundary, also known as emails that are forwarded once they have been delivered successfully to the intended recipient.
- No need to contact the recipient, they are not rejecting your mail.
Want to continue the conversation? Head over to the dmarcian Forum.
