It’s 2025, and email-based cyberattacks continue to pose as significant financial, reputational, and operational threats to organizations. As per IBM’s recent report, the global average cost of a data breach in 2024 is $4.88 million— a 10% increase over the last year and the highest total ever.

With such numbers surfacing the internet daily, it’s not really a choice but a necessity to implement, monitor, and manage email authentication protocols. The three primary email authentication protocols are SPF, DKIM, and DMARC. Together, these three fortify against fraudulent emails sent illegitimately from your domain. This blog focuses explicitly on SPF and its role in combating phishing and spoofing attacks that misuse your identity.

What is SPF in email authentication?

SPF stands for Sender Policy Framework. It’s an email authentication protocol that allows domain owners to specify which mail servers are officially authorized to send emails on behalf of their domains or brands. When appropriately implemented, SPF lets recipients’ servers verify if the email sent from your domain is legitimate. As a domain owner, you need to create an SPF record (a TXT record published in your domain’s DNS) to list the mail servers allowed to send emails on your behalf and specify how receiving servers should handle unauthorized emails.

How does SPF work?

SPF requires the domain owner (or the person in charge of email authentication) to create an SPF record, enlist all the authorized servers, and mention the preferable failing mechanism (explained later in this blog). When an email is received from your domain, the recipient’s mail server retrieves the SPF record corresponding to your domain to determine if the message is sent from an authorized server.

Let’s break this down-

1.    DNS query during email transmission

When an email is sent, the recipient’s mail server extracts the ‘Envelope From’ domain (the domain in the MAIL FROM command during the SMTP handshake) and performs a DNS lookup to retrieve the SPF record for that domain.

2.    SPF verification process

The recipient’s server compares the sender’s IP address with the authorized IPs listed in the SPF record.

The result of this comparison determines the SPF outcome:

• Pass: The sender’s IP is authorized.
• Fail: The sender’s IP is not authorized.
• Soft fail: The sender’s IP is not authorized, but the email is not outright rejected (often marked as spam).
• Neutral: No specific guidance from the SPF record.
• None: No SPF record was found for the queried domain.
• PermError: There are some configurational issues in the SPF record.
• TempError: A temporary DNS issue occurred during verification.

3.    How emails are handled based on the SPF results

If the SPF check passes, the email is processed normally. If the SPF check fails, the recipient’s mail server may:

• Reject the email outright.
• Mark it as spam or suspicious.
• Quarantine the email for further analysis.

Here’s an example of a standard SPF record-

v=spf1 ip4:192.168.1.0/24 ip6:2001:db8::/32 a mx include:mail.example.com -all

SPF syntax

An SPF record is created using specific mechanisms, qualifiers, and modifiers. Here’s a breakdown of all SPF syntax components.

1.    Version Identifier

• Syntax: v=spf1
• Purpose: Specifies the SPF version and always start the record.

2.    Mechanisms

• ip4: A match is successful if the sender’s IP falls within the IPv4 range specified in the SPF record. The range is defined using a prefix to indicate its size, and if no prefix is given, /32 (a single IP) is used by default.
• ip6: A match is successful if the sender’s IP falls within the IPv6 range specified in the SPF record. The range is defined using a prefix to indicate its size, and if no prefix is given, /128 (a single IP) is used by default.
• a: Authorizes the domain’s A record (or a specific domain’s A record) to send emails.
• mx: Authorizes the domain’s mail exchange (MX) servers.
• include: Authorizes another domain’s SPF record.
• all: Matches any source that isn’t already matched by earlier mechanisms.
• ptr: It’s a deprecated mechanism that matches based on reverse DNS lookups. It’s rarely used now because of the vulnerability it introduces in the SPF record.

3.    Qualifiers

Qualifiers are used to tell how mechanisms are interpreted-

• + (Pass): Explicitly allows.

Example: +ip4:192.168.1.1 (default behavior; often omitted).

• – (Fail): Explicitly denies.

Example: -all denies all non-matching sources.

• ~ (Soft fail): Marks as suspicious but doesn’t outright reject.

Example: ~all marks unauthorized emails but allows delivery (often to spam).

• ? (Neutral): No preference.

Example: ?all neither allows nor denies.

4.    Modifiers

Modifiers are additional directives that are rarely used.

• Redirect: Points to another domain’s SPF record for evaluation.
• Exp: Specifies a domain for a custom error message.

SPF soft fail or SPF hard fail; which one is right for your domain?

SPF has two distinctive failing mechanisms. In simpler words, there are two options that you can choose from regarding how receiving servers should handle illegitimate emails sent from your domain. These two options are SPF soft fail and SPF hard fail. However, domain owners often find it challenging to judge the situation of their SPF journey to determine which failing mechanism they should implement. Let’s first know what each of these does, and then we’ll figure out which one is suitable for which kind of domain.

What does SPF soft fail do?

With the SPF soft fail mechanism, you can instruct the receiving server to consider the unauthorized email as potentially suspicious. This means that emails that are sent from your domain but didn’t pass the SPF checks are placed in the spam folders and not the primary inboxes.

It’s considered a safer and more forgiving option with respect to false positives. By false positives, we mean genuine emails that fail the SPF authentication checks because of technical glitches or misconfigurations in the SPF record. Soft fail ensures that legitimate emails that fail SPF due to errors aren’t blocked while still flagging potential fraud for review. This way, there are still chances that recipients will open your emails if they happen to check the spam folders.

These 3 are the ideal scenarios for using the soft fail mechanism-

• When you have just started with email authentication and are still figuring out how these protocols work. With soft fail, you won’t face any severe email delivery issues.
• You are unsure if you have mentioned all the mail servers in your SPF record.
• The nature of your operations requires you to integrate or decommission mail servers frequently.
• Your IP range is dynamic.

Here’s an example of an SPF record with soft fail-

v=spf1 ip4:192.168.1.0/24 ip6:2001:db8::/32 a mx include:mail.example.com ~all

What does SPF hard fail do?

The SPF hard fail is a strict mechanism. It instructs the receiving servers to outrightly reject the entry of emails that didn’t pass the SPF checks. It’s primarily used by domain owners who have been dealing with email authentication protocols for a while now, and they are sure about their mail servers.

Implementing this mechanism requires vigilance and smartness; otherwise, legitimate emails sent from your domain can also be bounced back. So, if your business nature requires stricter control and protection over emails, then SPF hard fail will do the job.

Here’s an example of an SPF record with hard fail-

v=spf1 ip4:192.168.1.0/24 ip6:2001:db8::/32 a mx include:mail.example.com -all

Which one is right for your domain?

To implement a suitable mechanism for your domain, you need to consider your domain’s needs, email infrastructure, SPF implementation stage, and, most importantly, risk tolerance with respect to missed emails.

Use SPF soft fail to identify the legitimate sending servers. This also works well if you rely on multiple third-party service providers for emailing. With soft fail, your email delivery stays smooth and mostly unaffected, hence making it perfect for the early stages of SPF setup.

Later, when you are sure about the authorized email servers and have a fair understanding of how to deal with the complications that come with the SPF and DMARC implementation, you can proceed to the hard fail mechanism. The confidence to move to the strictest SPF mechanism isn’t easy to come by, so it’s fine if you want to stick to soft fail. However, if your domain belongs to sensitive sectors like government and financial, it needs high security offered by SPF hard fail.

The best approach is to start with soft fail to minimize risks. Once confident in your SPF setup, transition to hard fail for stronger security.

Did you like what you just read?

Hi, I am Daksh Kaur, a seasoned freelance cybersecurity blogger with over 5 years of experience in crafting engaging, insightful, and easy-to-understand content. So, if you liked my blog and need a dedicated professional to enhance your website with impactful, well-researched content, I’d love to collaborate!

Whether you need regular blog updates, in-depth guides, or thought leadership pieces, I’ve got you covered. My USP is that I don’t work with multiple clients at a time, and I am currently open to a new long-term collaboration.

Feel free to contact me at daksh@turtlewords.com, and let’s create content that sets your brand apart. I look forward to hearing from you!