Email Sender and Domain Reputation

How Microsoft’s filtering changes impact your marketing email.

minute read

Post Image

In January, Microsoft decided to shake up the way their filters look at mail and elevate their anti-spoofing and anti-phishing filters, potentially impacting email marketers’ email campaigns. For those of you who’ve been around long enough will remember Microsoft always tries to push their own way, with initiatives like SenderID rather than supporting industry initiatives like SPF.

After fully supporting SPF, DKIM, and DMARC standards and starting ARC support, Microsoft is now looking at alternative ways to use these solutions to protect their users. However, this may have some unintended consequences for commercial email programs.

Others in the industry are already weighing in on these changes, including Laura Atkins at Word to the Wise, saying “Microsoft is taking authentication protocols and using them in ways that are slightly outside the spec, but are logical extensions of the spec.”

We see benefits of this, surely. Spoofing an email used to be much simpler to accomplish, but since the adoption of email authentication, it is much harder. Yet, there are several issues still tricking users into clicking on these fraudulent emails, so Microsoft is working to address them by adding in “implied authentication,” as if there was an attempt to authenticate the domain. Other service providers such as Gmail also do this with a “best guess record for domain” attempt at authentication when a domain does not publish an explicit record.

If a domain doesn't authenticate, Microsoft will treat it as if it had published email authentication records and treat it accordingly if it doesn't pass.

For example, SPF works on the sender “from” address (5321.MailFrom), which in some cases is set by an email service provider (ESP) or mailbox provider (MBP) to manage bounces and replies on behalf of their clients. The end user would still see the mail from [email protected] in the “email from” (5322.From) in their email client.

DKIM works in a different manner to allow one or more parties to claim the message was sent with their approval. This could be an ESP or MBP claiming it originated from their network, a brand claiming they approved the message, or both signing a separate DKIM key (d= domain) for the message, one as the network and secondly as the brand owner.

DMARC works alongside both SPF and DKIM to allow a domain owner to publish a policy requesting the recipient’s MBP take action, should both forms of authentication fail.

DMARC policies of the Fortune 500 pie chart

Photo via Microsoft

Under the new authentication processes for Outlook domains, you may see a compauth fail if you send email without proper authentication from your ESP, including a shared MailFrom and platform-branded DKIM. This highlights how important it will be to add your branded domain to your email authentication. Here’s the value Outlook will return when your mail fails to authenticate under these new rules.

Compauth header

Via Microsoft

Accompanying the authentication results will be a reason code indicating what triggered the classification decision by the Outlook platform:

Authentication results

Via Microsoft

Understanding your domain’s authentication configuration and these changes to Outlook’s handling of your messages should definitely be on your to-do list. In the 250ok platform, send a new campaign or view your most recent to see how the headers are classifying your messages. Need help with this? Let us know and we’ll help you along.