Understanding SPF Record And Email Authentication And Security

In a time where email security is a must, understanding SPF (Sender Policy Framework) is crucial for protecting your domain from spoofing and phishing attacks.
What is SPF?
SPF stands for Sender Policy Framework. It is an email authentication protocol designed to help verify which sending infrastructure can relay email on behalf of your domain, consequently preventing email spoofing and protecting your brand.
How does it work?
SPF allows domain owners to define a list of mail servers permitted to send emails on their behalf.
This list is known as ‘SPF record’. It contains:
- the authorized parties to send on behalf of your domain.
- the set of instructions that the receiving email server is to follow.
Let’s look at how that happens. When an email is received, the recipient’s mail server checks the SPF record of the sender’s domain, to verify if the sending server is authorized. This verification is done using SPF mechanisms. These mechanisms are like the special spoken language between servers, and we plan to decipher this syntax in this blog post!
SPF Record Basics
SPF records are published in the Domain Name System (DNS) as TXT records. An SPF record follows a structured format employs a certain syntax, consisted of tags and qualifiers.
A basic SPF record looks like this:
v=spf1 ip4:192.168.1.1 include:example.com -all
Tags:
- a Tag is a specific keyword used to define a component of the SPF policy. The most common tags in an SPF record include:
-
- v= (Version Tag) à This specifies the version of SPF being used. It must always be v=spf1 for SPF records.
- Example: v=spf1
- Mechanism Tags à These define how email validation is performed. Each mechanism is a tag within the SPF record:
- ip4: and ip6: Allow specific IPv4 or IPv6 addresses.
- a: Uses the domain’s A record to validate the sender.
- mx: Uses the domain’s MX records for validation.
- include: References another domain’s SPF record.
- all: Defines the default behavior for non-matching sources.
- v= (Version Tag) à This specifies the version of SPF being used. It must always be v=spf1 for SPF records.
Qualifiers:
- Qualifiers (+, -, ~, ?) – Modify how a mechanism result is interpreted:
-
- + (Pass) → Email is allowed.
- - (Fail) → Email should be rejected.
- ~ (SoftFail) → Email may be accepted but flagged.
- ? (Neutral) → No policy decision is made.
When Tags meet Qualifiers: how to set up your SPF record
In SPF, we use tags and add special qualifiers depending on our needs to construct the list of legitimate senders on our behalf and specify what should be done in case of an illegitimate sender. Below we will go over the most common mechanisms used in SPF.
- ip4 and ip6
These mechanisms specify which IP addresses are allowed to send emails.
- ip4:192.168.1.1 → Allows a specific IPv4 address.
- ip4:192.168.1.0/24 → Allows a range of IPv4 addresses.
- ip6:2001:db8::1 → Allows a specific IPv6 address.
- a
The a mechanism allows emails to be sent from the IP address associated with the domain’s A or AAAA DNS record.
- a → Matches the sending server's IP with the domain’s A record.
- a:mail.example.com → Checks the A record of mail.example.com.
- mx
The mx mechanism authorizes the mail servers listed in the domain’s MX records.
- mx → Allows emails to be sent from the domain’s mail servers.
- mx:example.com → Allows mail servers listed in example.com’s MX records.
- exists
The exists mechanism allows a domain owner to specify a DNS lookup to check if a domain exists.
- exists:check.example.com → If check.example.com resolves to an IP, it passes.
- include
The include mechanism allows the SPF record of another domain to be referenced. It’s useful when a third-party service (e.g., Microsoft 365, Google Workspace) sends emails on behalf of your domain.
- include:_spf.google.com → Allows Google’s SPF record.
- If the referenced domain’s SPF fails, it is considered a failure.
- all
The all mechanism acts as a fallback when no other mechanisms match. It is usually placed at the end of an SPF record and is coupled with qualifiers.
- -all → Hard fail (reject unauthorized emails)
- ~all → Soft fail (mark unauthorized emails as suspicious but still accept them)
- +all → Allow all servers (not recommended)
- ?all → Neutral (no policy enforcement)
Enhancing Email Security: Beyond SPF
Reputation and brand are worth more than ever before, and whilst implementing SPF alone is not enough to garner enough email security in this cyberthreat-filled age, it is a crucial first step for effective email authentication and spoofing prevention.
Lastly, to build a fortress of an email security infrastructure, consider combining SPF with DKIM and DMARC technologies and consolidate your email reputation to the highest degree possible.
To learn more about DMARC and understand its importance check out this article https://rheintec.io/en/it-security-blog/the-importance-of-implementing-a-proper-dmarc-policy