通过

Chasing the (very) long tail of unauthenticated domains

  • 项目

One of the requests that frequently crosses my desk (computer screen) is a vulnerability claim that a certain domain that is owned by Microsoft is prone to spoofing because it does not have email authentication records - neither SPF, DKIM, nor DMARC. Because this can be used to spoof, it is a vulnerability.

Microsoft Corporation owns many domains, from microsoft.com to skype.com to xbox.com to live.com. Some of these domains have strong auth records (DMARC reject or quarantine) and some have nothing published at all (e.g., microsoftstore.com).

We used to go and chase down the most commonly spoofed domains and published SPF, DKIM, and DMARC records for them; monitor the domains; and then move to a DMARC quarantine/reject record. That would lock down the domains.

However, that is no longer our strategy because it doesn't scale.

  • Within Office 365 Advanced Threat Protection [1], we stopped relying upon SPF and DMARC records exclusively as a means to stop spoofing. For our ATP customers, they have antispoof protection available to them, see https://aka.ms/LearnAboutSpoofing. We also added some additional protection in the event the From domain has "microsoft" anywhere in it to ensure it gets marked as spam/phish (I call this "substring spoofing", or sometimes "brand impersonation" which by itself has multiple categories which includes putting the brand name into the Display Name, rather than the domain).
    .
  • The simple addition of a hard fail to the SPF record to any of Microsoft's domains does not solve the spoofing problem for all variants of Microsoft properties – outlook.com, Hotmail.com, Hotmail.ca, msn.fr, etc., so we’d have to protect those as well. That is, we could protect one domain, but unless we went and protected everything we own, another claim could come up that yet another domain isn't protected. The locking down of all these domains is time consuming.
    .
  • Furthermore, and most importantly due to the way attacks are sent these days, it doesn’t solve the spoofing problem of variants that Microsoft does not own like msn.com.com, my-msn.com, etc. Those are also damaging to our brand and can be used to spoof, but since we don't own them, we can't update those DNS records. We'd have to buy them, or figure out their current owner and shut them down. But we can't stop any and all variants, it's a nearly infinite long tail, especially as Email Address Internationalization ramps up.

Our approach to solving the problem of spoofing is to on-board customers to ATP/E5  [2] where they can get antispoofing protection regardless of the sending domain; if/when we expand Antispoofing to the rest of the customer base, those variants of the Microsoft brand will also be covered. We are also looking to expand the way we protect Top Brands like MSN by checking to see if the domain name contains a Top Brand, or a variant of it, and using other heuristics to detect it as a spoof.

In the diagram below, the green part represents authenticated email (SPF, DKIM, DMARC), the blue represents unauthenticated email that is not marked as spam, and the red is everything else.

Thus, we won't need to publish any auth records because we are flipping the model on its head - rather than relying upon a domain to publish auth records and defaulting back to assuming something is good, we instead default back to assuming something is bad. We do this because we try super hard to implicitly authenticate a message. Despite our best efforts, this can still result in false positives; but all false positives can be resolved by either publishing auth records by the domain owner, or our customer creating their own local overrides.

Publishing an SPF hard fail has its drawbacks – especially when email is forwarded. As I say above, we are looking to move protection away from the SPF/MailFrom domain to the From domain, and then use better heuristics built upon the principles of DMARC rely upon that instead. We think the industry is better served by treating unauthenticated email as suspicious regardless of whether or not it publishes auth records, and then using signals to rescue it - such as authentication or sender reputation - in the event the message isn’t malicious.

That’s how we are planning to scale up protection of our brands; we still publish auth records opportunistically, but not necessarily for all of our domains [3]. And the ones that do have SPF records may not necessarily have SPF Hard Fail. Instead, we encourage others to add their own intelligence on top of what is published to repudiate the ones that don't auth. That's what we do.

It's the only way to make this scale.

[1] And eventually the rest of the Office 365 customer base, and eventually our consumer email platform

[2] Same as [1]

[3] We will do this to improve delivery, such as a new domain is being spun up and wants better delivery because we are treating unauthenticated email as spam/phish/spoof. Adding SPF, DKIM, and DMARC will help in self-identifying that the domain is authorized to send email. It's kind of (?) like a Spamhaus PBL for domains