A Sender Policy Framework (SPF) Primer for Exchange Administrators

Email spam continues to be a huge problem for organizations these days, and it usually falls on the Exchange administrator to do something about it. Aside from the usual anti-spam measures we can put in place to protect our own servers from spam, we also need to consider how to prevent spammers from spoofing (imitating) the domain names for our own organization. After all, it can be very embarrassing or cause serious brand damage to have spam and malware that uses your domain name.

To detect spoofed email many receiving servers, particularly those operated by large email providers such as Microsoft, Yahoo, Google, and AOL, will perform a check of the Sender Policy Framework (SPF) record for the sender’s domain when a sending server is attempting to send an email message.

SPF records allow a domain owner to specify which mail servers are permitted to send email for that domain name. When the sending server issues its “MAIL FROM” command in the SMTP conversation, the receiving server will look up the SPF record in the domain name of the MAIL FROM email address to see if there is a match for the source IP address of the SMTP connection.

If you were reading about SPF records on the internet you may find advice from some websites that it is better to have no SPF record than it is to have an incorrect SPF record. There’s some truth to that, but also some risks. Some mail hosts will reject mail if there is no SPF record for the domain. It tends to be few hosts that do that, but because they are very large mail hosts the impact can be quite noticeable. Ultimately, it is best to have a correctly configured SPF record in DNS for your domain.

An SPF record is simply a TXT record with a certain syntax. The syntax is made up of two parts; mechanisms, and modifiers. Modifiers are optional and are not commonly used except for special circumstances. During management and troubleshooting of transport you’ll most often be dealing with SPF records containing only mechanisms.

The mechanisms for an SPF record define the sets of hosts that can send email from the domain. Mechanisms can be defined by:

• all – matches any host, and is placed at the end of the SPF record as a “catch all” for any senders that did not match other mechanisms listed ahead of it.
• ip4 – matches a single IPv4 address or IPv4 network range.
• ip6 – matches a single IPv6 address of IPv6 network range.
• a – matches a host name or domain name. The IP addresses that the name resolves to in DNS are matched against the sender’s IP address. This mechanism is useful for matching against a web server IP address based on the domain name.
• mx – matches against the MX records for the domain. This mechanism is useful when the outbound mail is handled by the same servers as the MX records resolve to for inbound mail.
• ptr – reverse DNS queries are used to match the sender IP address to the host names that it resolves to. This mechanism is generally not recommended due to the DNS load it causes.
• exists – simply checks that the domain exists in DNS.
• include – matches the sender IP against the SPF record another domain. This is commonly used when your outbound email is routing via a cloud service such as Exchange Online Protection.

Mechanisms are used in combination with a qualifier that tells the server what to do when a match is found. The qualifiers are:

• “+” for pass (this is the default if no qualifier is explicitly provided)
• “–” for fail (email from unauthorized hosts should be rejected)
• “~” for SoftFail (may result in email being accepted but marked as “likely spam”)
• “?” for Neutral (regardless of the result the email should be accepted)

An example of a mechanism paired with a qualifier is “-all” at the end of an SPF record, which means “Fail/reject email from any sender who did not match an earlier mechanism in the SPF record.”

If this all seems very complicated to you, don’t worry, it starts out that way for everyone who has to deal with SPF records. Fortunately, there are many tools available to help you construct and validate your SPF records. For example, Microsoft provides the Sender ID Framework SPF Record Wizard, which has an awkwardly long name but is nonetheless very useful.

After entering your domain name the wizard will step you through a series of questions to determine the most likely SPF record that you will need. In this example I answered the questions as follows:

• Domain’s inbound servers may send mail (in other words, the servers listed as MX records also handle outbound email)
• An additional domain name whose A record is a valid outbound email server (a common example of this is an externally hosted website that uses its own SMTP service to send notifications and other emails)
• This domain sends mail only from the IP addresses identified above (in other words, anything else trying to send email from my domain name should be considered unauthorized)

The resulting SPF record looks like this.

By adding that string as a TXT record in the public DNS zone for the domain name I will have prevented unauthorized email servers from spoofing my domain name. At least, they won’t be able to do it when sending to any receiving server that checks SPF records. Anyone who is not checking SPF records can still receive the spoofed email, but may reject it for other reasons such as spam content or malware.

Apart from tools to generate your own SPF record, many email services will provide you with the exact strings to add to your SPF record. When you add a domain name to Office 365 Microsoft advises you of the SPF record they suggest, which is appropriate for organizations sending their outbound email using Exchange Online Protection. Similarly, email marketing services and SMTP hosting services will also have documented solutions to adjust your SPF record so that you can successfully use their services without your email being rejected.

After you have your SPF record in place you should validate it. And in fact, you should repeat this validation test any time you suspect an external organization may be rejecting your email because of your SPF record. MXToolbox has an SPF record validator that takes a domain name and IP address as input and lets you know what the result will be if that IP address sends email for your domain.

Aside from the result for that specific IP address, the MXToolbox SPF record lookup tool will also validate the general health of your SPF record for problems such as excessive DNS lookups or syntax problems.

Despite the importance of SPF records for internet email delivery, your internal mail flow between Exchange servers in your own organization is not dependent on SPF records. The Exchange servers in your organization already understand that other Exchange servers in the same organization are authoritative for your domains.