To date, when most people think of anti-spam, they think of blocking inbound spam. Most people don’t think about taking steps to ensure that their domain won’t be spoofed by bad actors, often because they presume that email that spoofs their domain would be blocked by the recipients.
But that’s not true often enough, which is why Office 365 is now deploying “Unverified Sender” flagging for email from domains that don’t take steps to prevent their domains from being a source of spoofed phishing emails. I expect you will see more and more providers do something similar.
You might think it’s hard to spoof another domain right? It’s trivial to spoof another email domain. Last year, I showed a Partner at a prominent law firm (who is a key player in their national technology practice) how easy it was to spoof their domain. With the partner’s permission, I created their domain in Zimbra and then created a mailbox with the same email address as the Partner. I then changed the account’s zimbraMailTransport setting to point to the law firm’s Office 365 SMTP server. Lastly, I sent the Partner a “fake” bill with bogus wiring instructions to pay it. The Partner got the email — which looked exactly like it came from the Partner himself — in his Office 365 mailbox in a few seconds.
Why did this get through? Because the law firm had failed to deploy good SPF and DMARC records in public DNS. Oh, and it took me only about fifteen minutes to set this up (including copying the Partner’s email signature)…
As Microsoft’s “Unverified Sender” flagging becomes deployed more broadly, I expect many email senders to complain bitterly when their outbound emails are essentially flagged as spam by Office 365. But Microsoft is clear on this (and I agree 120% with them):
“As a sender, you should authenticate your message with either SPF or DKIM.”
Unfortunately, in many cases, well-intentioned email admins have big challenges tightening up their SPF/DKIM/DMARC records. Why? Because in most organizations, no one group “owns” who gets to send email on the company’s domain. Think of all the web, CRM, ERP, utility, monitoring, processing, scan-to-email printers and other servers that send emails from your domain. If you don’t have a comprehensive inventory of them, you can’t tighten up SPF/DKIM/DMARC records sufficiently to satisfy Microsoft (and increasingly others) without risking blocking some of your legitimate outbound email.
So that’s Step One: Get an inventory of everything that sends email from your domain.
How do you do that? Sign up for a free trial account at dmarcian and configure DMARC reporting for your domain.
Step Two: After deploying a relaxed DMARC record in public DNS, update your SPF record use the “Soft Fail” flag and to list all of the hosts that send email from your domain. Don’t be lazy! Don’t add whole Class C and larger networks; identify the specific IP addresses that send email from your domain. If you use third party services like Shopify (who don’t support DKIM), get from them what it is that you should be adding to your SPF record. dmarcian has a number of tools and blog posts, in addition to automated DMARC reporting, to help you with this process.
Step Three: Start Using SPF and DMARC to block emails purporting to come from your domain. Zimbra’s most excellent Best Practices wiki article describes this process in detail, and how easy it is to configure Zimbra to sign all of your email with DKIM. It’s a terrific wiki article for newbies and experienced email admins alike.
If you need help with all of those, please just fill out the form to start the conversation.
Hope that helps,
L. Mark Stone
Mission Critical Email
27 January 2020
The information provided in this blog is intended for informational and educational purposes only. The views expressed herein are those of Mr. Stone personally. The contents of this site are not intended as advice for any purpose and are subject to change without notice. Mission Critical Email makes no warranties of any kind regarding the accuracy or completeness of any information on this site, and we make no representations regarding whether such information is up-to-date or applicable to any particular situation. All copyrights are reserved by Mr. Stone. Any portion of the material on this site may be used for personal or educational purposes provided appropriate attribution is given to Mr. Stone and this blog.
