What is an SPF Record and How to Set it Up?

In the perpetual fight against spam on the web, the SPF record is a standard for defining whether a domain is authorized to send emails. Thus, you are adding an extra layer of authentication by implementing an SPF TXT record for your domain.

A properly configured Sender Policy Framework record protects your domain from email spoofing, phishing, and spam. Furthermore, it helps maintain a proper domain and brand email reputation.

In this article, we will explain what an SPF record is, how it works, its syntax and how to set it for your domain name.

What is an SPF record?

A Sender Policy Framework (SPF) is a DNS record, part of a domain’s DNS zone, that declares which domains and hosts can or cannot send emails on behalf of a domain. Practically, this public record can contain two parts – a list of authorized domains and a list of forbidden senders.

On its own, the standard email-sending protocol (SMTP) does not verify an email’s “From” address. That’s because a valid email address is sufficient for establishing a Simple Mail Transfer Protocol connection to a mail server.

Consequently, anyone can exploit this flaw and impersonate senders. Therefore, additional authentication methods like the SPF, DKIM, and DMARC records were created to fight spam, email spoofing, and phishing attacks.

According to IETF’s RFC-7208, the SPF record must be a single string of text in a single DNS TXT record. Multiple SPF records for the same domain name are not permitted, thus, if there is more than one SPF record – they will not function properly.

What is the Return-Path email address?

Although the email SPF record does not verify the “From” field of a message, it confirms a part of the email header that is not visible at first sight. From the header, Sender Policy Framework validates the Return-Path value to authorize the sender’s email domain address and originating server.

Receiving email servers check whether the Return-Path domain name matches the public list of approved hosts for the particular sender. The Return-Path email domain indicates where your email server should store the bounce message receipts.

Naturally, you wouldn’t need to configure a return-path address if you have only a handful of email recipients. Chances are, you won’t receive that many bounce messages interfering with your day-to-day work. However, if you are running e-commerce, your email marketing campaigns reaching thousands of recipients may result in loads of bounced messages.

Therefore, the standard practice is configuring a return-path address to store these bounce receipts for further sifting and analysis.

SPF record curbs

There are a few curbs to the Sender Policy Framework technology that you should consider, and we’ll list them briefly below.

• The “From” address in the header does not fall under the protection of the SPF record, meaning that hackers can still spoof your display name.
• When an email is forwarded, the SPF record breaks, thus it will not pass a check.
• An SPF record lacks reporting, which challenges maintaining a stable mailing list.
• A domain’s SPF record needs to be regularly updated as you change email service providers to reflect the currently approved senders.

How does an SPF Record Work?

When you send a message, your email client (MacMail, Outlook, or Thunderbird) sends it to the SMTP server, which then initiates the email transaction with a receiving server.

Then the receiving server (POP3/IMAP) extracts the return path defined in the email header of the message. More specifically, it extracts the email domain of the return-path address to initiate a DNS lookup and fetch the SPF record. Once the SPF record lookup is complete, the server verifies the SPF record for the domain name.

The receiving server will complete the check with SPF pass if the domain is authorized as a sender in the DNS SPF record. Since the SPF record is valid, the message will be passed to the recipient’s inbox.

The SPF check will fail if the server does not find the host in the list of approved sending domains. The SPF record checker may consider this suspicious, reject the message, mark it as spam, or place it under quarantine.

What does an SPF look like?

As mentioned above, the SPF record is a single string of text that consists of the SPF protocol version prefix and one or more mechanisms.

Here is an SPF record example: the default SiteGround SPF setup.

v=spf1 +a +mx include:_1c3125358d5b0660b2012471e2c2b23a.spf.dnssmarthost.net include:_spf.mailspamprotection.com ~all

The version prefix (v=spf1) tells the parsers to interpret this TXT record as the SPF record since a domain can have multiple TXT records in its DNS zone.

Then comes the second part, consisting of different prefixed mechanisms letting the receiving server know how to execute the SPF check.

In this example record, the domain’s A and MX records are mechanisms added with the “+” qualifier. This means that upon an SPF check, the matching mechanisms will “Pass.” The following mechanism is “include,” defining the SPF record of the email-sending server that is permitted to send on behalf of the domain name. Then comes the “all” mechanism prefixed with “~,” meaning that if everything in the string so far checked out, the SPF record will result in “SoftFail.”

SPF Syntax components

The core components of an SPF record syntax are called mechanisms and qualifiers. We will shortly describe each of these components in this subsection, so read on.

What are the SPF qualifiers?

The qualifiers instruct the interpreting server on how to read the record and what to do with the SPF check results. The qualifiers are optional, and the available ones are as follows:

• “+” – Pass – This qualifier tells the recipient server that an IP address that matches a mechanism should pass the check.
• “–” – Fail – This one instructs the server to fail an SPF check if an IP address meets the list specifying unauthorized senders.
• “~” – SoftFail – If an IP matches a mechanism, it will soft fail the SPF check, instructing the server to accept the message but label it with an SPF failure.
• “?” – Neutral – This qualifier will cause an undetermined check result – neither fail nor pass.

What are the SPF record mechanisms?

When a mechanism is evaluated during an SPF check, it can return a match, no match, or an exception. If it matches, the process ends, and the value of the qualifier for that mechanism is returned as the result of the check. In case it does not match, the evaluation process continues with the next mechanism. And if the result returns an exception, the process ends by returning the exception’s value.

• “а” – This mechanism defines a host’s A record (IP); if matched, it will pass.
• “mx”- Each domain name’s hosting email service has MX records, and there could be multiple MX records. These DNS records identify the email servers handling the mail service for the domain name. If you add the “mx” mechanism to your SPF record, all your domain MX records are automatically added to the approved sender’s list.
• “include” –  The “include” mechanism serves for cross-company email sending, authorizing external email hosts in the SPF record. In essence, the “include” statement validates an external host to send emails on behalf of your domain name (e.g., Google Workspace)
• “all” – This mechanism means “everything,” and it is always placed at the end of an SPF record. The idea behind it is that everything that got checked until this point of the SPF record string should give the specified result in the qualifier. In the SPF record example we provided above, this mechanism is defined as “~all,” meaning that the result will be a SoftFail.

Should I Set an SPF Record?

If you still wonder whether you should add an SPF record to your domain name, you should know that having it will help improve your email deliverability. There are several key benefits to having an SPF record, and we will outline them below.

• Having a properly configured SPF record increases your domain’s reputation and, therefore, your email deliverability.
• An SPF record fights domain impersonation and email spoofing to preserve your brand’s reputation and trustworthiness.
• The Sender Policy Framework record is one of the essential methods for DMARC compliance. DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. A TXT DNS record lets the receiving server know how to handle a failed authentication message. It tells the recipient’s server to either quarantine, reject or allow the message’s delivery.

In short, adding such a record to your domain’s DNS zone is recommended to stay safe from various email cyber attacks. So, if you are ready to create an SPF record for your domain – keep reading to find out how.

How Can I Set an SPF Record?

As we pointed out above, setting a Sender Policy Framework record for your domain name is highly recommended to ensure your email deliverability and reputation. Here we will outline the two possible options to set up an SPF record for your hosted domain name from your SiteGround Site Tools.

Set an SPF Record From Your DNS Zone Editor

Hosting companies usually provide access to a DNS Zone Editor tool, so you can manage the DNS records of your domain name. Note that you must make these DNS changes from the account where the authoritative DNS zone for the domain is. Regardless of the provider, you are hosting it with, your domain name needs to be pointed by Name servers there. Only this way changes applied to a domain’s DNS zone will actually take effect.

SiteGround clients can set up an SPF record directly from the DNS Zone Editor in their Client Area > Services > Domains > Settings of the desired domain.

For example, if you want to use Google Workspace for your email service, you need to include Google’s SPF (include:_spf.google.com). To do that, select the TXT tab, leave the Name field empty, type the SPF record you want to apply for your domain, and hit Create.

Once you create the SPF record, it will need some time to propagate and take effect. When the propagation period is over, Google Workspace will be a valid sender on behalf of your domain name.

Set an SPF Record From Site Tools’ Email Authentication Tool

At SiteGround, the SPF record is enabled by default for each domain name with a default value. You can manage it from the respective Site Tools for your domain by navigating to the Email section > Authentication.

In this section, you can modify your domain’s default SiteGround SPF record or add more A or MX records. You can use the Approved IP/IP Blocks option to allow IP addresses or IP ranges (blocks of IPs), manage the include SPF list, and the “all” qualifier.

Although an SPF record alone is not enough to entirely prevent email abuse, it is an essential component of your domain’s email authentication. A correctly configured SPF reduces the chances of someone impersonating your email, affecting your email and brand credibility.

With the information you found in this article, you now know what the SPF record is, its syntax and components, and how to set up one for your domain.