Posts

SPF exists in your domain’s DNS as a TXT record with a bunch of mechanisms and modifiers that stand for specific instructions. The SPF all mechanism is present at the right end of an SPF record, preceded by “-” or “~”. Let’s take a look at what the difference is between the SPF -all and ~all mechanisms to determine when you should configure them.

SPF -all vs ~all

Both the SPF -all and ~all mechanisms signify “NOT PASS” for SPF authentication. In recent times, for a majority of email service providers, there is no difference between the -all and ~all mechanism, and the same result is returned. However, this was not the case a few years ago.

How did the SPF all (Softfail vs Fail) mechanism operate before DMARC?

DMARC was created a long time after SPF had already been in the market as the standard email authentication protocol. At this time the SPF -all softfail mechanism operated in the following way: 

Let’s suppose your SPF record was: 

v=spf1 include:spf.domain.com ~all (where ~all signifies SPF Softfail) 

Your receiver’s email server would have performed a DNS lookup to query the sender’s DNS for their SPF record. If the email’s Return-path domain was not listed in the sender’s record, the receiving server would have returned an SPF “NOT PASS” result but would have delivered the email to the inbox of the receiver. 

Now let’s suppose your SPF record was: 

v=spf1 include:spf.domain.com -all (where -all signifies SPF Fail) 

Your receiver’s email server would have performed a DNS lookup to query the sender’s DNS for their SPF record. If the email’s Return-path domain was not listed in the sender’s record, the receiving server would have returned an SPF “NOT PASS” result, but in this case, the email would have been rejected and not delivered to the inbox of the receiver.

Read more about the history of Sender Policy Framework

How do email service providers handle the SPF -all vs ~all mechanism now?

While you are free to use SPF -all or ~all for most mailbox providers at the current time without having to worry about delivery failures for legitimate emails, there can arise a situation where a server rejects your email in case of the -all attribute

Just to be on the safer side, you can avoid using the SPF hard fail -all mechanism while creating your SPF record. This is how you do it:

  • Open the PowerDMARC SPF record generator to start creating a record for free
  • After including the IP addresses and domains or your email senders scroll down to the last section designated to instruct email server’s how strict they should be while verifying your emails
  • Choose the “Soft-fail” option before hitting the “Generate SPF Record” button

What do we recommend? SPF -all or SPF ~all

The issues with email deliverability pertaining to the SPF -all mechanism might occur on very rare occasions. This is not a recurring problem that you will come across often. To ensure you never run into this problem, you can take the following steps:

  • Configure DMARC for your emails, and enable DMARC reporting
  • Set your DMARC policy to monitoring and closely inspect your SPF authentication results to spot any inconsistencies in email deliverability
  • If all is good, you can use the -all mechanism in your SPF record. We recommend using the hard fail attribute since it affirms that you are confident regarding the authenticity of your emails, which can boost your domain’s reputation

If you are currently unsure about using SPF -all, you can follow these steps:

  • Set up an SPF record using the ~all mechanism
  • Configure DMARC for your emails, and enable DMARC reporting
  • Set your DMARC policy to reject

Troubleshooting other SPF errors

While using online tools you may often come across the “No SPF record found” prompt which is a common error state arising from a null result returned when a server looked up your domain’s SPF record. We have covered an article in detail talking about this issue and helping users resolve it. Click on the linked text to know more! 

If you have DMARC in place for your domain on top of SPF, email servers will check your domain’s DMARC policy to establish how you want emails failing authentication to be treated. This policy for DMARC will determine if your emails are delivered, quarantined, or rejected. 

DMARC reject helps protect your domain against a variety of impersonation attacks like spoofing, phishing, and ransomware.

If your company uses its own domains and domain-handling mails, there are high chances of them running into email issues, and have come across the ” SPF Softfail Domain Does Not Designate IP as Permitted Sender ” error. It is crucial that companies properly designate the IP Addresses used to send out emails on their behalf as a permitted sender in the SPF Record.

What is SPF?

SPF or Sender Policy Framework is an email-authentication standard that protects organizations against impersonation. An attacker may use a company’s domain and brand name to send fake messages to their customers. These phishing emails seem authentic enough to convince the customers and make them fall for an internet scam in the company’s name. This will harm a company’s brand credibility and damage its public image. SPF can be imagined as a safelist of trusted domains of a company from where authentic communication can originate.

How to check if your domain is a permitted sender?

The first step to resolving the “SPF Softfail Domain Does Not Designate IP as Permitted Sender” error is to check your sender authority. To do so: 

Step 1: Log in to the company’s domain’s email account, let’s say, [email protected]

Step 2: Send an email to another email account to which you have access; this can be to an external domain like Gmail, Yahoo, Hotmail, or others. 

Step 3: Log in to the email account where you sent the first mail, and then view the headers of this email. It’ll be marked as “Show original”.  

Then, you’ll see something similar to this. Notice the SPF Softfail message.

–Original Message –

X-Received: …

Sat, 13 March, 2022 11:01:19 IST

Return-Path: [email protected]

Received: from mymy2.spfrecords.com (mymy2.spfrecords.com [60.130.71.223])

by mx.google.com with ESMTPS id 

*id*

For [email protected]

Received SPF: softfail (google.com: domain of transitioning [email protected] does not designate 60.130.71.223 as permitted sender) client-ip=60.130.71.223; 

Authentication results: mx.google.com;

Spf = softfail (google.com: domain of transitioning [email protected] does not designate 60.130.71.223 as permitted sender) client-ip=60.130.71.223; 

*end of header message

Note: If you observed “Received-SPF: pass” in the header, then the domain you are using to send the mails is authenticated and is already added to your SPF record, and you don’t have anything to worry about. However, as shown above, there is a softfail issue. We will now look into how to resolve the same.

What does “SPF Softfail Domain Does Not Designate IP as Permitted Sender” mean?

Your email sender has a host IP that looks something like this:

30.10.323.005

If this IP address for the sending domain is not included on your domain’s SPF record, the email receiving server fails to identify the designated IP as a permitted sender. The server automatically interprets the message to be coming from an unauthorized source. This is a possible reason why SPF failed for the message. It yields a high probability of DMARC failure if the email authentication system is solely reliant on SPF for source verification (and not DKIM). 

Under such circumstances, if your protocol policy is set to reject, your message will never get delivered! Therefore, the domain owner must take quick and actionable measures to fix the “SPF Softfail Domain Does Not Designate IP as Permitted Sender” issue.

How to include an IP as a permitted sender for SPF?

The solution for this can be divided into the following steps: 

1. Create a list of sending sources for your domain. You may use a list of email addresses based on your domain, as well as third-party sending sources for email transactions.

2. Now, identify the host IPs of these sending sources 

How to find IP addresses linked to your email sending sources?

It’s pretty easy! To find the IP address of your sending source, open the email and view your full email header. To do so you need to click on the three dots at the top-right corner of your email to view the drop-down menu, and select “Show original”. 

On the original message, scroll down to the Received line, you will be able to spot the host IP address of the original sender, as shown below:

3. Use our SPF Record Generator to generate a free SPF record for your domain.

  • In the record generator, add all the IP addresses you wish to be authenticated to send emails and communication on behalf of the company.
  • Add any third-party servers or external delivery services as an authorized sending source for your domain. This way, any mails sent via third-party servers will also pass the SPF Authentication.

4. Once you have used the SPF Record Generator to generate the SPF Record for your domain with all the trusted domains and IP Addresses added to it, all that is left to do is implement SPF by publishing it on your DNS. Here is how you can achieve that:

  • Log in to your DNS Management Console
  • Next, navigate to the domain of choice (the domain for which you are trying to add/modify the SPF record)
  • Specify your resource type as ‘TXT’
  • Specify the hostname as “_spf”
  • Paste the value of your generated SPF record 
  • Save changes to configure SPF for your domain

Note: The above names or headers may vary based on the DNS Management Console you are using for your company.

This way, the domain owners can ensure that all their trusted IP addresses and domains they might use to send communications on the company’s behalf are added to the server, and a similar error where the SPF Softfail Domain does not designate IP as the permitted sender will not occur. 

How to effectively use the SPF standard?

The only way to solidify a company’s SPF technology is to incorporate it with DMARC. Here are the benefits of doing this, 

1. DMARC = SPF + DKIM

Email authentication protocols like DMARC are configured by adding a TXT record to your DNS. Apart from configuring a policy for your domain’s emails, you can also leverage DMARC to enable a reporting mechanism to send you a wealth of information about your domains, vendors, and email sources.

DMARC can help you make use of both SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) technologies in tandem to give your domain even better protection against spoofing.

Note: This is recommended, but not mandatory. DMARC can function with either SPF or DKIM identifier alignment.

2. Reporting & Feedback with PowerDMARC

Neither SPF nor DKIM gives the domain owner feedback about emails that fail authentication. DMARC sends detailed reports directly to you, which the PowerDMARC platform converts into easy-to-read charts and tables.

3. Control what happens to unauthenticated emails 

DMARC lets you, the domain owner, decide whether an email that fails validation goes to inbox, spam, or gets rejected. With PowerDMARC, all you have to do is click one button to set your DMARC policy, and it’s that easy.

Unauthorized senders can be a dangerous threat to the security of your clients and your company’s image and brand value. Protect your customers from phishing and scams by incorporating DMARC in your company, and only allows mails from authenticated senders to reach them.

Have you ever seen an email fail SPF? If you have, then I’m going to tell you exactly why SPF authentication fails. Sender Policy Framework, or SPF, is one of the email verification standards we’ve all used for years to stop spam. Even if you weren’t aware of it, I’ll bet if I checked your login account settings for Facebook it would likely show you “opt-in” to “email from friends only”. That is effectively the same thing as SPF.

What is SPF Authentication?

SPF is an email authentication protocol that is used to verify that the email sender matches with their domain name in the From: field of the message. The sending MTA will use DNS to query a preconfigured list of SPF servers to check if the sending IP is authorized to send email for that domain. There may be inconsistencies in how SPF records are set up, which is critical to understanding why emails can fail SPF verification, and what part you can play to ensure issues don’t occur in your own email marketing efforts.

Why SPF Authentication Fails : None, Neutral, Hardfail, Softfail, TempError, and PermError

SPF authentication failures can happen due to the following reasons:

  • The receiving MTA fails to find an SPF record published in your DNS
  • You have multiple SPF records published in your DNS for the same domain
  • Your ESPs have changed or added to their IP addresses which have not been updated on your SPF record
  • If you exceed the 10 DNS lookup limit for SPF
  • If you exceed the maximum number of permitted void lookup limit of 2
  • Your flattened SPF record length exceeds the 255 SPF characters limit

Given above are various scenarios of why SPF authentication fails. You can monitor your domains with our DMARC analyzer to get reports on SPF authentication failures. When you have DMARC reporting enabled, the receiving MTA returns any one of the following SPF authentication failure results for the email depending on the reason for which your email failed SPF. Let’s get to know them better:

Case 1: SPF None result is Returned

In the first case scenario,- if the receiving email server performs a DNS lookup and is unable to find the domain name in the DNS, a none result is returned. None is also returned in case no SPF record is found in the sender’s DNS, which implies that the sender doesn’t have SPF authentication configured for this domain. In this case SPF authentication for your emails fails.

Generate your error-free SPF record now with our free SPF record generator tool to avoid this.

Case 2: SPF Neutral Result is Returned

While configuring SPF for your domain, if you have affixed a ?all mechanism to your SPF record, this means that no matter what the SPF authentication checks for your outbound emails conclude, the receiving MTA returns a neutral result. This happens because when you have your SPF in neutral mode, you are not specifying the IP addresses that are authorized to send emails on your behalf and allowing unauthorized IP addresses to send them as well.

Case 3: SPF Softfail Result

Similar to SPF neutral, SPF softfail is identified by ~all mechanism which implies that the receiving MTA would accept the mail and deliver it into the inbox of the recipient, but it would be marked as spam, in case the IP address is not listed in the SPF record found in the DNS, which can be a reason why SPF authentication fails for your email. Given below is an example of SPF softfail:

 v=spf1 include:spf.google.com ~all

Case 4: SPF Hardfail Result

SPF hardfail, also known as SPF fail is when receiving MTAs would discard emails originating from any sending source that is not listed within your SPF record. We recommend you to configure SPF hardfail in your SPF record, if you want to gain protection against domain impersonation and email spoofing. Given below is an example of SPF hardfail:

v=spf1 include:spf.google.com -all

Case 5: SPF TempError (SPF Temporary Error)

One of the very common and often harmless reasons why SPF authentication fails is SPF TempError (temporary error) which is caused due to a DNS error such as a DNS timeout while an SPF authentication check is being performed by the receiving MTA. It is, therefore, just as the name suggests, usually an interim error returning a 4xx status code that can cause temporary SPF failure, however, yielding an SPF pass result when tried again later.

Case 6: SPF PermError (SPF Permanent Error)

Another common result that domain errors are faced with is SPF PermError. This is why SPF authentication fails in most case scenarios. This happens when your SPF record gets invalidated by the receiving MTA. There are many reasons why SPF might break and be rendered invalid by the MTA while performing DNS lookups:

  • Exceeding the 10 SPF lookup limit
  • Incorrect SPF record syntax
  • More than one SPF record for the same domain
  • Exceeding the SPF record length limit of 255 characters
  • If your SPF record is not up to date with changes made by your ESPs

Note: When an MTA performs an SPF check on an email, it queries the DNS or conducts a DNS lookup to check for the authenticity of the email source. Ideally, in SPF you are allowed a maximum of 10 DNS lookups, exceeding which will fail SPF and return a PermError result.

How Can Dynamic SPF Flattening Resolve SPF PermError?

Unlike the other SPF errors, SPF PermError is much more tricky and complicated to resolve. PowerSPF helps you mitigate it easily with the help of automatic SPF flattening. It helps you:

  • Stay under the SPF hard limit
  • Instantly optimize your SPF record
  • Flatten your record to a single include statement
  • Make sure your SPF record is always updated on changes made by your ESPs

Want to test if you have SPF configured correctly for your domain? Try out our free SPF record lookup tool today!