What is an SPF Record?

In today’s digital age, email has become an indispensable communication tool for individuals and businesses alike. However, the widespread use of email has also led to an increase in email-based threats such as phishing, spoofing, and spam. To combat these threats and ensure the integrity of email communications, various technologies and protocols have been developed, among which the Sender Policy Framework (SPF) plays a crucial role. While SPF offers multiple authentication levels, including Fail and SoftFail, the importance of enforcing a strict SPF Fail policy cannot be overstated.

Understanding SPF

Sender Policy Framework (SPF) is an email authentication protocol that helps prevent unauthorized sources from sending emails on behalf of a domain. It works by allowing domain administrators to specify which IP addresses and servers are authorized to send emails on behalf of their domain. When an email is received, the recipient’s mail server checks the SPF record of the sender’s domain to verify its authenticity.

SPF Fail vs. SoftFail:

SPF provides two main authentication results: Fail and SoftFail. Note, that �Fail� is often referred to as a �Hard Fail� or a �Hardfail�, popularized by large email security companies, including Proofpoint and Mimecast. A “Fail” result means that the email was sent from an unauthorized source, according to the SPF record. A “SoftFail” result, on the other hand, indicates that the email might be unauthorized, but the server is not explicitly rejecting it. Instead, the recipient’s server might consider it a weaker authentication, potentially allowing the email to be delivered to the recipient’s inbox. Where does the industry stand regarding SPF Fail vs Soft Fail? A leading email security company, Proofpoint, states that it will aggressively increase the spam score for emails using an SPF hard fail, and only moderately for emails failing with a soft fail. Of course, admins serious about security should want an aggressive quarantining of mail that could be spoofing their domain. Mimecast, who themselves use a hard fail to secure their domain, consider SPF Soft Fail to be only a temporary measure. Microsoft, also using an SPF hard fail for their own domains, recommend it for new customers.

The Soft Fail result is considered to be a temporary setting, whilst SPF is being configured.

Mimecast

A "softfail" result is a weak statement by the publishing ADMD that the host is probably not authorized. It has not published a stronger, more definitive policy that results in a "fail".

RFC 7208

A "fail" result is an explicit statement that the client is not authorized to use the domain in the given identity.

RFC 7208

The Importance of SPF Fail:

SPF Fail, also called an SPF Hardfail or Hard Fail, is the most authoritative of all 4 types of SPF mechanism.

• Enhanced Email Security: Enforcing a strict SPF Fail policy significantly enhances email security. When an email fails SPF authentication, it sends a clear signal that the sender’s domain has not authorized the source of the email. This helps protect recipients from phishing attacks, spoofed emails, and other malicious activities.

• Reduced False Positives: By implementing an SPF Fail policy, organizations can reduce the chances of legitimate emails being flagged as spam or fraudulent. SoftFail results might lead to email clients flagging emails as potentially suspicious, causing inconvenience to both senders and recipients.

• Deterrence for Attackers: Cybercriminals often exploit the SoftFail result to send emails that appear legitimate. By adopting a strict SPF Fail policy, organizations discourage attackers from attempting to deceive recipients using their domain name.

• Domain Reputation: Consistently failing SPF checks can harm a domain’s reputation. Email servers and filtering systems take domain reputation into account when assessing the legitimacy of incoming emails. A strong SPF Fail policy helps maintain a positive domain reputation.

• Compliance and Standards: Many industry regulations and standards, such as DMARC (Domain-based Message Authentication, Reporting, and Conformance), recommend using a Fail policy for SPF authentication. Adhering to these standards ensures a higher level of email security and compliance.

SPF Soft Fail, Softfail, Hard Fail, or Hardfail?

According to the official SPF standard, RFC 7208, “softfail” should be used over “soft fail”, with the latter not appearing anywhere in the document. Softfail also helps to make it clear that it’s a single word. Although not mentioned in the RFC, major email security companies have been known to use both soft fail and hard fail including Proofpoint, Mimecast, Microsoft, and Google. In other instances yet, it is broken up to terms like soft SPF fail and hard SPF fail. Although Proofpoint and Mimecast use SPF hard fail or hardfail, the term does not appear anywhere in the RFC document, but has become well-adopted in the industry, to make it clear that it’s a more authoritative rejection.

Major SPF Misconfigurations

Sender Policy Framework (SPF) is a highly technical protocol and is prone to many misconfigurations. The most common of which include:

• Missing SPF Record: This is surprisingly common since domains do not come configured with SPF records by default; they must always be created manually. You might find that an automatic integration generated a record when setting up your inbox with a major company, but otherwise, no record will exist.
• Missing SPF Record for Non-Sending Domains: It is crucial to set a record with �v=spf1 -all� for all domains that do not send email. Simply not sending email with that domain is insufficient; you must clearly indicate that no email should be accepted from this sibling domain.
• Incorrect �All� Modifier in SPF Records: By default, an SPF record can end with four types of �all� modifiers: fail (hard fail) �-all,� soft fail �~all,� neutral qualifier �?all�, and the �+all� qualifier. An SPF record should end with at least one of these for correctness.
• Multiple �All� Modifiers: Many admins mistakenly configure SPF records with multiple �all� modifiers, which confuses the SPF interpreter. This error often occurs during modifications to an existing SPF record.
• Duplicate SPF Records: Only one SPF record is permitted per domain. Duplicate SPF records should be moved to a subdomain, where they can authenticate emails when a DMARC policy allows relaxed SPF enforcement. Creating a new record instead of modifying the existing one is not permitted under SPF policy. Duplicate records cause unpredictable behavior, as various email servers interpret them differently.
• Exceeding 10 DNS Lookups: SPF records are limited to 10 DNS lookups. For management ease, they often break down into sub-records. SPF flattening tools can help, or you can specify in your DMARC policy that subdomain authentication is possible, offloading some hops into their own subdomain policy.
• Using �SPF� type Instead of �TXT�: Despite being counterintuitive, SPF records should be listed as type �TXT� and not type �SPF.� Email inboxes may treat them correctly, but following best practices ensures maximum deliverability.
• Incorrect IP Addresses: A common mistake involves misconfiguring SPF entries, such as incorrect subnet masks or missing IP addresses, which can cause occasional email authentication failures. Hosts should have SPF DNS records like �include:spf.protection.outlook.com� that allow users to enter the domain, simplifying management and maintenance.
• Failing to Maintain SPF Records and a Solid Email Inventory: Domain admins should clearly understand what each entry means across all domains and subdomains. A change management process should authorize new senders and de-authorize old services to maintain security.
• Not Monitoring DMARC Aggregate Reports: Monitoring these DMARC reports allows admins to see how their emails authenticate with clients. By reviewing reports from recipient inboxes, admins can identify failed and successful emails and make necessary adjustments to improve delivery rates.
• Bonus SPF Error: Using Only SPF: SPF should be used alongside DKIM and a strong DMARC policy. Microsoft recommends using SPF, DKIM, and DMARC together to provide redundancy and resilience. While forwarding can break the SPF record, and old mail systems may not support DKIM properly, DMARC ties them together, ensuring email deliverability and security.

While Sender Policy Framework (SPF) offers both Fail and SoftFail authentication results, the importance of implementing a strict SPF Fail policy cannot be underestimated. By doing so, organizations can significantly enhance email security, reduce false positives, deter attackers, maintain domain reputation, and adhere to industry standards. As the digital landscape continues to evolve, safeguarding email communications through robust authentication mechanisms like SPF Fail is a critical step in mitigating email-based threats and fostering trust among users.