Key Points in This Article:
If you’re a business using Office 365, enabling SPF is essential to your cybersecurity. SPF stands for Sender Policy Framework. It’s a protocol that helps validate the emails you send from your domain. It prevents criminals and scammers from sending emails that appear to come from your domain – a technique known as spoofing.
Email spoofing is commonly deployed to trick individuals into providing access credentials, supplying confidential information, or downloading malware. It’s a cybersecurity concern that could result in significant financial loss, reputational damage, and legal liability. Mitigating those risks starts with configuring email authentication methods like SPF to safeguard your email messages.
Using SPF means publishing an SPF record – a TXT entry in your DNS server – that lists the IP addresses from which email servers are authorized to send emails from your domain. When you send an email, the recipient’s email server will automatically look up the SPF record, verify that your email is coming from a matching address, and allow the email through. In practice, an email that appears to come from your domain not on this list will be recognized as potentially suspicious and either automatically send your email to the recipient’s Spam inbox or be rejected entirely.
Criminals and scammers may spoof your email address to trick your employees into handing over their personal financial information or provide access credentials or sensitive information about your business. In some cases, criminals may use spoofed emails to coax your employees into downloading malware onto your network. Or they may use spoofed emails to scam your suppliers, vendors, or customers.
Using SPF, along with other email authentication records, can substantially mitigate the risk they will be successful. Not only does the authentication process help identify criminals and scammers, but the publication of an SPF record makes the sending server a less attractive target to be spoofed.
SPF can also improve your email deliverability rates, as spam filters are less likely to denylist your domain. Without an SPF record, some email servers may flag particular IP addresses as spam generators and send all incoming emails directly to Spam. And while your emails may be completely legitimate, as most people do not regularly check their Spam folders, those emails will go unread.
SPF records contain several different components. In addition to the IP address (both IPv4 and IPv6 versions as necessary), the SPF record provides the recipient’s server instructions in case of an IP address mismatch. Here’s a brief look at an SPF record if you’re hosted in Office 365:
v=spf1 include.spf.protection.outlook -all
Each SPF record begins with v=spf1. The next line include.spf.protection.outlook directs the recipient server to include emails coming from Exchange Online. If you were using a third-party email system, this line would be replaced with include:
You’ll end the SPF record with your enforcement rule, which tells the recipient server what to do in case of a mismatch. The sender can tell the recipient server to flag all mismatching IP addresses to FAIL by setting an -all directive. Or the sender can use ~all to direct the recipient to let the email through with a warning that the email is potentially malicious. Doing so is referred to as a SOFTFAIL.
Using the former directive means you must accept the risk that your legitimate emails may be rejected. When mass emailing to emails from multiple domains, it may be worth sending test messages with a SOFTFAIL policy in place and assessing your results before opting for a hard fail policy. There is also an +all directive that lets all messages through regardless of the mismatch. However, using this directive would not be a good cybersecurity practice.
Office 365 already includes SPF records for Microsoft’s servers in DNS. However, some circumstances, such as operating in a hybrid environment, may require you to revise or reconfigure your SPF records. Further, it’s good practice to check to make sure they are configured correctly, especially if you’ve had to update them in the past.
It’s also critical to note that you must add a new SPF record for each subdomain. Your subdomains do not automatically inherit their top-level domains’ SPF records. Also, attackers have attempted to send emails from nonexistent subdomains. You can create a wildcard SPF record for each domain and subdomain not covered by another DNS record you’ve created to prevent them from doing so. To create a wildcard SPF record, you would add an * to the Name field in the DNS record.
SPF records alone won’t prevent spoofing. But SPF is a good first step. You should also enable DKIM and DMARC email authentication protocols to provide even more protection. DKIM stands for DomainKeys Identified Mail and is an email authentication method designed to ensure that the email hasn’t been tampered with. It does this by including a digital signature to every email message, which the recipient’s system can verify in DNS.
DMARC stands for Domain-based Message, Authentication, Reporting, and Conformance and helps recipient email servers authenticate emails. It does so by adding instructions to recipient email servers about checking the From: field and ensuring that it is aligned with other domain names that have been authenticated. Further, DMARC communicates to recipient email servers that the email messages being sent are covered by SPF and/or DKIM and provides instructions to the recipient about what to do if those authentication methods fail.
Using SPF, DKIM, and DMARC in tandem provides substantially more protection against email spoofing than SPF alone. And all three can be easily configured by Office 365 users.