A customer reached out to us today about not getting emails from a particular sender in an organization. In a nutshell, our customer was receiving email from a user, let's call him robert@example.com, but they were not receiving email from an automated address (customerservice@example.com). They searched through the Paubox Quarantine and were unable to find emails from customerservice@example.com. That's when they reached out to us. This post explains how we solved it.
To begin troubleshooting, we took a closer look at the sender's setup.
Their domain name, let's just call it example.com, had the following SPF record: "v=spf1 include:spf.protection.outlook.com -all" In addition, their MX record looked like this: example-com.mail.protection.outlook.com.
In other words, the sender is using Microsoft 365 for their Corporate Email and have a Hard Fail Sender Policy Format (SPF) rule in place.
As per the official SPF website: "The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. More precisely, the current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages." Translation: SPF is an optional DNS record you can and should create for your domain name. A well-crafted SPF record lets the rest of the internet know which mail server(s) are allowed to send email on your behalf.
In the case of our tech support issue today, we focused on the -all section of the sender's SPF record. Here it is again as reference: "v=spf1 include:spf.protection.outlook.com -all" Let's break it down bit by bit: v=spf1: Identifies the DNS TXT record as an SPF record, utilizing SPF Version 1. This is the current version. Nothing to worry about here. include:spf.protection.outlook.com: This signals that all SPF records (and associated IP addresses) belonging to Microsoft are allowed to send email on behalf of the sender. This is a typical setup of an Microsoft 365 customer. -all:
Any other mail servers trying to send email on behalf of example.com are not to be trusted and should be rejected. This is known as a hard fail. As long as you have a complete inventory of your mail servers in your SPF record, this works very well. This was not the case however, for the sender.
When we took a closer look at the email address that was not getting through to our customer, customerservice@example.com, we noticed it was an automated email coming from an IP address of 67.138.237.135. This IP address is not affiliated with Microsoft or Microsoft 365. It's probably a marketing service or website that's been setup by the sender and is not hosted by Microsoft or Microsoft 365.
Since that IP is not affiliated with Microsoft 365, its SPF record check resulted in a Hard Fail.
As expected, Paubox Inbound Email Security rejected the incoming email from customerservice@example.com.
We communicated to our customer today that Paubox obeyed the SPF record that's in place for the sender and bounced the email. As for the sender, the recommended SPF record would be: "v=spf1 ip4:67.138.237.135 include:spf.protection.outlook.com -all"
Note: If the sender has other IP addresses sending email on its behalf that are not part of Microsoft 365, those IPs should also be added accordingly.
See Also: SPF Record Syntax