After setting up O365 Exchange email, and either dutifully adding all the dns records MSFT requires or allowing MSFT to create them if on the Small Business plan, many people report that they stop receiving messages from web site contact forms or other 3rd party services that use their domain in the from address. The messages don’t go to junk – they just disappear. The usual support response is to whitelist the email address/domain, check with the isp and send ndr’s. That might help if the emails are actually reaching Exchange. But it’s likely they are not – and are getting blocked by an isp because the instructions MSFT provides for creating an SPF dns recordare inaccurate or at best, incomplete. The record may be specifically excluding any server but their own from sending emails. This may be an even more significant problemif you have a Small Business tenant and elect to use MSFT’s nameservers, because the provided spf record can’t be edited.What is an SPF record?
An SPF record helps isp’s and receiving email services detect “spoofed” emails. “Spoofing” is the practice of sending emails using someone else’s domain in the from address in an attempt to beat spam filters and get the recipient to trust the email. Changing a “from” address is easy, but changing the server address the email is sent from is not – so an spf record can be used to let the isp know whether or not a server or ip address is allowed to send email using a particular domain.
That’s a good thing but it has a potential downside. An SPF record can be formatted to EXCLUDE any other email server or ip address – in which case an isp that checks your SPF record will reject emails from servers you haven’t specifically authorized to send email from your domain.
Unfortunately that’s exactly what MSFT’s recommended SPF record does.
“v=spf1 include:outlook.com ~all ” tells an isp: ONLY EMAILS ORIGINATING FROM OUTLOOK.COM ARE ALLOWED TO USE THIS DOMAIN.
The “~all” EXCLUDES any other server or ip so when your web site or other email sending service send emails from their own server, not outlook.com, an isp may reject their messages.
A typical example would be emails generated by a WordPress site contact form. The originating server would be the site hosting server. If its address is not included in the spf record it will get sent but likely end up in a black hole and never received.
The MSFT instructions should tell us to add “include:outlook.com” to an existing SPF record, or make sure to add an SPF record that includes ALL the sending services that may be using a domain. So if you manage your own dns and send emails from services that use your domain, get their ip address or server name and add them to your SPF record. You can only have one SPF, so format it as follows, substituting in your own information:
v=spf1 mx ip4:22.214.171.124/32 ip4:126.96.36.199/32 include:sendgrid.netinclude:zoho.cominclude:outlook.com~all
What that tells an isp is emails sent using my domain from ONLY those 5 locations are legit – which is exactly what you want.
Small Business Tenants Using MSFT’s Nameservers
If you’re not managing your own dns, you won’t be able to edit the spf record MSFT automatically created for you. You can still fix the problem but it will require switching nameservers and manually adding/editing the records MSFT provides.