What is an SPF TXT record and what do you need it for?

Problem:

You would like to get the basic information about the Sender Policy Framework (SPF) TXT record and learn why you need to update it when you intend to use CodeTwo Email Signatures for Office 365 in server-side or combo mode.

Solution:

Each domain on the Internet, including your organization’s one, needs to have several DNS records configured at your hosting or domain provider’s system. The records or the zone files are primarily used to ensure correct routing to your website and email server but can also play different roles.

Sender Policy Framework (SPF) is a DNS text record that lists email servers authorized to send emails originating from email addresses in your domain.

Here’s a sample syntax of an (SPF) TXT record:

v=spf1 ip4:192.168.0.1 include:spf.protection.outlook.com -all

where:

• v=spf1 is an indicator of a valid SPF TXT record.
• 192.168.0.1 is a sample address of your organization’s email server specified in the IPv4 format.
• spf.protection.outlook.com is the address of a third-party server that takes part in your mail flow. Here, it’s the domain of the Exchange Online service. Third-party server addresses should always be introduced with include:.

  Important

  Third party’s domains included in this way must have SPF TXT record configured as well. Otherwise, emails sent from your domain will fail SPF verification, as described in the next section.

• -all means that domains not listed in the SPF TXT record are not authorized to send emails on behalf of your domain.

You need to have your SPF TXT record configured correctly to make sure emails sent by your users reach all the recipients. Otherwise, they might go to spam/junk or get blocked on the way. Such situation might take place if the emails don’t pass the SPF verification – either because you fail to add your email server or a third-party solution’s server (e.g. a Microsoft Azure server our service resides on) to the record. Read on to get more details.

How does the SPF verification work?

The SPF verification happens every time a message tries to reach an incoming email server. It doesn’t necessarily need to be the final recipient’s server – it can be any server receiving the message on its way to the final recipient (a relay server). In other words, a single message can be subject to more than one SPF verification on its way to the final recipient.

For a simplified diagram, refer to Fig. 1. below. If you need more details, have a look at the description and the commentary below the figure.

Fig. 1. A simplified scheme of the SPF verification mechanism.

The SPF verification process proceeds as follows:

1. The sender’s email address (e.g. [email protected]) is found in the return-path message headers.
2. The domain name (example.com) is extracted from the address.
3. The SPF TXT record defined for the extracted domain name is accessed.
4. The list of email servers in the record is checked to confirm that the domain name (or its IP address) is listed here as well.
5. The result of the verification is returned:
   1. If the domain is listed in the record, the message passes the SPF verification.
   2. If the domain is not listed in the record, the message fails the SPF verification.

Based on the verification result and applied security policies, the incoming email server makes a decision what to do with the message:

1. SPF verification successful (spf=pass):
   1. Message reaches recipient’s inbox (final recipient’s server).
   2. Message is successfully sent to another server (relay server).
2. SPF verification unsuccessful (spf=fail):
   1. ​Message is delivered to recipient’s spam/junk folder (final recipient’s server).
   2. Message is blocked by the incoming email server, which results in a Non-Delivery Report (final recipient’s server or relay server).

These are the common scenarios. However, depending on spam or phishing policies applied to a given incoming email server, the result might be different, e.g. the message might still be delivered to recipient’s inbox, even though it has failed the SPF verification.

To summarize, it’s highly recommended that you have your SPF TXT record configured in a correct and exhaustive way to avoid the risk of messages being blocked while in transit between a sender and a recipient. What’s more, even if your users’ messages reach the destination despite negative verification, it might still negatively impact your domain’s reputation.

Why should you add the address of a Microsoft Azure server our service is hosted on to your SPF record?

If you look at the mail flow diagrams in this article, you can see that in server-side mode (and partially in combo mode) messages sent by your users leave your tenant’s email server (without leaving a Microsoft Azure Datacenter) to be processed on a Microsoft Azure server where our service resides on. This fact is recorded in message headers – our service is shown there as one of the outgoing email servers.

Next, an incoming email server checks if all the outgoing email servers found in the message headers are included in your SPF record. If the address of the Microsoft Azure server hosting our service is not added to the record and the SPF verification fails at this point, there’s a risk that an Exchange Online Protection (EOP) server might block or flag a message with a CodeTwo signature. Such message might not reach the final recipient or might land in the spam/junk folder at best. The same applies to automatic replies generated by the Autoresponder feature.

For this reason, you should always expand your SPF TXT record with the address of the Microsoft Azure server where our service is hosted, located in the region you chose when registering your tenant (as described in this article). This way, you can ensure seamless mail flow experience for your end users and take care of your domain’s good reputation.

Learn how to update your SPF TXT record to work with CodeTwo Email Signatures for Office 365

If you prefer not to update your SPF TXT record, you might consider using our software in client-side mode.

See also:

• Problems related to Sender Policy Framework (SPF)
• Emails land in spam/junk folder