Is this SPF Permerror incorrect?

Problem reported by Etienne Wilderink - 7/4/2019 at 12:59 AM

Resolved

Hello,

Yesterday we received a mail that was marked as SPF PermError.
After investigating, in my opinion the SPF record is correct. Can someone please take a look at it and tell me if I (or SmarterMail) is wrong?

IP of the sender: XX.XXX.54.179

[2019.07.03] 	SPF Record: v=spf1 include:_spf.XXX.com include:amazonses.com include:spf.XXX.com include:spflive.XXX.com ip4:XX.XXX.54.176/29 mx ~all
23:40:50.020 [29666] Finished SPF check; result = PermError

IP XX.XXX.54.179 is in the ip4:XX.XXX.54.176/29 subnet so I guess it should be valid instead of returning an PermError?
(I thoroughly checked the first 5 digits before replacing them with X)

According to mxtoolbox.com the full SPF record is valid.

Running SmarterMail build 7082

13 Replies

Reply to Thread

Ishan Talathi Replied

7/12/2019 at 12:06 AM

SPF PERMERROR is a major issue with Smartermail. Smartermail is unable to parse long SPF records or multi level SPF records. Due to this, valid emails are going to spam.

Placing the sender in Trusted User also doesn't help with SPF showing failed.

We have a ticket open for over a month with no resolution in sight.

Kyle Kerst Replied

7/16/2019 at 3:26 PM

Employee Post

Hello Etienne, this appears to have failed due to the length of the SPF record. The SPF RFC standard states SPF records should be limited in length to prevent DNS timeouts during SPF lookups. The recommendation is to set SPF PERMERROR to 0 in your Settings>Antispam>Spam Checks to ensure users on these domains can deliver mail to your server if you deal with a lot of domains with nested SPF records like this one.

Kyle Kerst

System/Network Administrator

SmarterTools Inc.

(877) 357-6278

www.smartertools.com

Kyle Kerst Replied

7/16/2019 at 3:29 PM

Employee Post

Ishan, quick follow up for you on your comment. First, Trusted Senders are always subjected to SPF and RDNS checks to prevent spammers using your Trusted Senders list to spoof mail to your users. This cannot be disabled, and is an antispam functionality.

On your SPF PERMERROR issue, I did review this with the assigned tech, and this SPF PERMERROR was not what caused the message to be delivered to spam. In your environment you have already correctly set the PERMERROR value to 0, so this was not included in the spam weight. Instead this user was sent to junk mail due to their email server being on several blacklists.

The resolution is to reach out to the sending user's administrator to have them request delisting on the given blacklists.

Kyle Kerst

System/Network Administrator

SmarterTools Inc.

(877) 357-6278

www.smartertools.com

LeapSwitch Networks Replied

7/17/2019 at 2:28 AM

Neither you nor the tech handling my ticket understood the issue.

1. I know how Trusted Sender works in case of SPF failures

2. I know the sender's IP (sender is using Godaddy) is blacklisted

My point is -

1. Sender's IP is blacklisted which is why we have placed the domain in Trusted Sender

2. Now, if SPF check in SmarterMail was working, it would have passed SPF and sent email to Inbox Regardless of the sender IP being blacklisted.

3. Because SPF showed PermError , the email was not considered Trusted and was sent to Junk.

We have dozens of tickets coming in from customers due to this.

Zoho, Godaddy and many other large providers are using long and multi-level SPF records. Are you saying that because SmarterMail refuses to fix this bug, we should contact Zoho and Godaddy and other providers and ask them to change SPF records for millions of domains ?

G-Suite is accepting these emails with SPF Pass. Office 365 is accepting them with SPF Pass. Only SmarterMail is showing PermError. So please FIX the error instead of closing tickets without a resolution.

Sébastien Riccio Replied

7/18/2019 at 9:37 AM

From what I understand, it means SmarterMail is actually treating SPF PermError as if it was a SPF Fail.

And therefore the whitelisting is not in effect because it doesn't bypass a SPF failure.

If it's the case PermError should be treated as SPF Pass.

But more important is: why SmarterMail is returing a PermError for this SPF entry as it is perfectly validated by other software and online spf checkers.

Is the SPF parsing library used by SM outdated and doesn't handle long and/or multi-level spf ?

It makes perfect sense to me to dig this a bit more than that!

I remember last year also seing quite some SPF PermError in our SM logs and had checked them. Quite some where valid when I checked them with online tools, some others were real errors (bad spf syntax).

We don't have this problem anymore here as we completely disabled all antispam/antivirus processing by SmarterMail itself and are using dedicated front end filter (some E.F.A and some rspamd based solutions).

We then only use custom header checks rules on SmarterMail to give a SpamWeight score for further SmarterMail processing depending on the score returned by our gateways.

I hope you'll find a resolution to your problem.

Sébastien Riccio

System & Network Admin

https://swisscenter.com

LeapSwitch Networks Replied

7/23/2019 at 12:46 AM

As always, SmarterMail refuse to accept this bug and close tickets and community topics without a response.

echoDreamz Replied

7/23/2019 at 1:42 AM

Why not post the domain name so others can check the SPF record directly.

LeapSwitch Networks Replied

7/23/2019 at 2:51 AM

Here you go -

Domain - a3spl.com

SPF - https://mxtoolbox.com/SuperTool.aspx?action=spf%3aa3spl.com&run=networktools

Received: from sg2nlshrout02.shr.prod.sin2.secureserver.net (sg2nlshrout02.shr.prod.sin2.secureserver.net [182.50.132.194]) by with SMTP.

This is a standard domain using a standard Godaddy hosting / email plan. Does SmarterTools expect us to inform each such sender or Godaddy to change how they have setup SPF ?

Sébastien Riccio Replied

7/23/2019 at 4:30 AM

Marked As Resolution

To be honest there shouldn't be two spf records in your domain, it's against rfc:

it's probably that triggering the PermError.

madjik@prism:~/slftp$ host -t TXT a3spl.com
a3spl.com descriptive text "v=spf1 +a +mx include:secureserver.net ~all"
a3spl.com descriptive text "v=spf1 a mx ptr include:secureserver.net ~all"

What is the reason for this ?

Heh also when mxtoolbox displays a red spf line, it means it failed

Btw the secureserver.net inclode s not the problem here. Just remove on of your double entry in the domain. (if it's your domain)

Sébastien Riccio

System & Network Admin

https://swisscenter.com

LeapSwitch Networks Replied

7/23/2019 at 4:36 AM

@Sebastien,

This is the sender email address, should we follow up with our client's (the recipient's) sender for fixing this ?

We simply want SmarterTools to not mark it as SPF Fail.

echoDreamz Replied

7/23/2019 at 4:36 PM

SPF record lookup and validation for: a3spl.com

SPF records are published in DNS as TXT records.

The TXT records found for your domain are:
v=spf1 a mx ptr include:secureserver.net ~all 
v=spf1 +a +mx include:secureserver.net ~all 

Checking to see if there is a valid SPF record. 

Results - Permanent Error Two or more type TXT spf records found.
No valid SPF record found of either type TXT or type SPF.

Your SPF has some issues.

You can also override the SPF Permanent Error Weight under the SPF spam settings. This isnt an SM issue as it is so much a you have a messed up SPF record issue.

Even if you do a lookup with MXToolbox, it's in red, telling you it is wrong.

LeapSwitch Networks Replied

7/26/2019 at 7:49 AM

You can also override the SPF Permanent Error Weight under the SPF spam settings. This isnt an SM issue as it is so much a you have a messed up SPF record issue.

1. It is not my SPF. This is a sample domains sending emails to our SmarterMail. There are many cases where a single long SPF record is also unreadable by SM. We have provided multiple examples in tickets.

2. We have already set SPF Permanent Error Weight as 0. However, SM still marks this as an SPF Failure which is a problem.

echoDreamz Replied

7/26/2019 at 1:06 PM

1. Still doesnt takeaway the fact that the SPF is wrong, you have numerous sources and validation tests telling you it is wrong. Can you provide those domains here so we can check them too?

2. The SPF failure/error overrides the trusted sender, as how can they confirm the sender is actually the sender if the SPF record is wrong/failing.

Back to Community Threads

Please leave this box unchecked

13 Replies

Reply to Thread

Tags

Related Knowledge Base Articles