SPF, which is short for Sender Policy Framework, is an email authentication protocol that allows Microsoft 365 domain owners to prevent threat actors from succeeding in deceiving recipients by sending phishing and spoofing emails from your domain. With SPF in place, emails sent by only officially authorized IP addresses and servers linked to your domain land in the recipients’ inboxes. This means if someone sends an email from your domain through an unauthorized server or IP address, the email will not reach the recipient’s inbox- it will either sit in their spam folder or get rejected (also called bouncing back).
In simple words, while SPF can’t stop a threat actor or ill-intended person from sending a malicious email using your domain, it can surely prevent it from reaching the inbox of the recipient. This minimizes (in case of the message getting marked as ‘spam’) or nullifies (in case of the message getting rejected outrightly) the chances of recipients falling into the trap and getting duped.
The primary purpose of SPF is to validate email sources for a domain. This is done by creating a TXT type SPF record that gets published in the DNS to help the recipients’ servers identify valid or authorized sources for the incoming emails’ domain. The recipients’ email systems dig into the publicly available SPF TXT record to verify that the MAIL FROM address or 5321.MailFrom address is legitimately authorized by the domain owner.
A general rundown of SPF in Microsoft 365 for different domain types
For Microsoft Online Email Routing Address or MOERA domain users
If you are a MOERA domain user, you don’t have to do anything, as the SPF record is already set up appropriately for your domain. Microsoft owns the .onmicrosoft domain so it is responsible for generating and maintaining DNS records for your domain as well as subdomains.
For one or more custom domain users
During enrollment, there will be a step requiring you to create or modify the SPF TXT record in DNS for your custom domain to identify Microsoft 365 as a valid mail source for your outgoing emails. However, your job won’t end there. Here are a few more things you need to take care of for the holistic protection of your domain against phishing, spoofing, ransomware, and other email-based threats.
Subdomain considerations:
- If you don’t directly control the email services (for example, you have outsourced the email marketing task to an agency), you should use a subdomain dedicated only to the third–party service provider. This way, they would have limited access to your domain, minimizing the effect of issues emerging from the subdomain delegated to them.
- Please ensure each subdomain has its dedicated SPF record. While you can subject your subdomain to inherit the parent domain’s SPF policy, it isn’t recommended because of various potential issues, including exceeding the lookup and character limits.
- If you own parked Microsoft domains (the domains you own but don’t use for sending emails or anything else), then you need to create an SPF record for that, too. Also, use the ‘-all’ mechanism so that no email sent from that domain or subdomain reaches the recipients’ mailboxes at all.
While we are emphasizing configuring SPF records to avert threat actors from exploiting your domains for sending fake emails, we also say that SPF alone is not enough. Unfortunately, sophisticated threat actors can spike SPF records and add their sending sources to label them as officially authorized by the domain owner. This way, emails sent by malicious actors can pass the SPF security check.
So, it’s better if you pair up SPF with DKIM and DMARC. Together, they strengthen the email infrastructure against cyber menace.
Guide on creating and managing SPF records for Microsoft 365 domains
The rest of the article explains common rules and troubleshooting tips for Microsoft 365 domain owners. Please understand that SPF isn’t a one-time job; yes, you have to create the SPF record once, but it requires regular updates, monitoring, and troubleshooting.
1. SPF enforcement rule
The enforcement rule is how you want the recipients’ servers to treat emails from sources not mentioned in your SPF record. Valid sources are-
SPF hard fail
The ‘-all’ mechanism denotes SPF hard fail. If you use this mechanism in your SPF record, the messages sent by unspecified sources will be rejected on the recipients’ end. What exactly happens with such messages depends on the destination email system. However, most of them are usually discarded.
SPF soft fail
The ‘~all’ mechanism denotes SPF soft fail and represents that the source is probably not authorized to send emails from a domain, so it should be allowed to enter the mailbox but must be marked as spam. In some destination email systems, the message is delivered to the junk email folder or placed in the inbox with an identifier added to the subject line or message body.
Points to remember
- Each domain or subdomain in DNS needs its own SPF TXT record, and only one SPF record is allowed per domain or subdomain. For undefined subdomains, DMARC is the best way to handle email authentication.
- The SPF TXT record for the `*.onmicrosoft.com` domain can’t be changed.
- SPF validation fails if the check involves too many DNS lookups.
Troubleshooting the DNS lookup limit error
When an email system checks the SPF record to verify the sender’s IP address, it goes through the listed IPs and ‘include:’ statements until it finds a match. If more than 10 DNS lookups are needed during this process, the email will fail SPF validation with a permanent error, leading to the message being rejected and a bounce message being sent. This might happen due to errors like exceeding the hop count or requiring too many lookups.
Each ‘include:’ statement in the SPF record triggers at least one DNS lookup, and if the statement references nested resources, additional lookups might be required. Even if you have fewer than 10 ‘include:’ statements, you could still exceed the lookup limit.
Email systems evaluate the SPF record from left to right, stopping once they find a valid source, so not all sources are always checked. However, it’s possible for an SPF record to have enough information to cause more than 10 lookups, even if some emails pass without errors.
To avoid exceeding the DNS lookup limit and protect your domain’s reputation, consider using subdomains for email services you don’t control. You can use free online tools to view your SPF record and estimate the number of lookups it requires.
If nothing works, use our automatic SPF flattening tool to condense your SPF record and stay within the lookup limit.
