Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

ES 10.0.6 Fails To Identify SPF Record (SPF Not Found)

Halon5Halon5 Enthusiast ✭✭


Has anyone seen this? Message Logs - "SPF Not Found" (MxToolbox "Analyze Headers" checks out with full readout).

Looks like we have this occurring in some specific situations (not good when a bank has specified -all or HARD FAIL) and we cant even see it to test it.


Category: Email Security Appliances


  • NevyadithaNevyaditha Moderator

    @Halon5 ,

    Can you please verify if the option"Enable SPF validation for incoming messages" is enabled under Manage>Anti-spoofing" inbound page?

    Also, would request you to contact support for more details

    Nevyaditha P

    Technical Support Advisor, Premier Services

  • Halon5Halon5 Enthusiast ✭✭

    Hi Nevyaditha,

    Thanks for following through here. Yes, enabled. I am interested to know if there are any others here seeing such behavior.

    I am seeing mail (including from SonicWALL but not in all cases - there is a pattern that can be seen by SW sender ) that fails the SPF lookup (No SPF Record) and I am trying to get to the bottom of it.

    I have already opened a case 43428904 and it is with Gailand (who is awesome) but I want to try and understand if its just my appliance or if others may be seeing this for 10.0.6

    Kindly, Steph.

  • BWCBWC Cybersecurity Overlord ✭✭✭

    Hi @Halon5

    do you mean the "No SPF Record" entries in the message log?

    Despite the fact that there is a SPF record? 3599 IN TXT "v=spf1 -all"


  • Halon5Halon5 Enthusiast ✭✭

    Hi @BWC ,

    yep. that's exactly what I mean. I had just furnished a similar example to @Nevyaditha . ie. from SonicWALL

    ** Thanks for YOUR sample! ** I guess that's CONFIRMED.

    This needs to be fixed FAST.

    Best & Regards --Steph

    P.S. Do i get a trophy cup thingy for my discovery? LOL.

  • NevyadithaNevyaditha Moderator

    @Halon5 ,

    I am on it and will provide an update as soon as possible.

    Nevyaditha P

    Technical Support Advisor, Premier Services

  • Halon5Halon5 Enthusiast ✭✭

    Hi @Nevyaditha ,

    It's Email Security 101 isn't it?

    This stuff should be reported properly.


  • NevyadithaNevyaditha Moderator

    @Halon5 ,

    I apologize for the delay in responding back to you on this.

    I am closely monitoring the Case 43428904 and checking with SME from Email Security for the reason behind the issue.

    I did get below information to investigate about the issue:

    -We need to check if Email Security queries the same DNS server as set in the UI.

    -We must check messages and check it’s contacting IP and query there DNS server for the response.

    Also, there are some instances where attachment scanning by Capture could play a role in the result since there are 2 passes in the plugin chain when Capture is used.

    I would request you to update the information requested in the case as this needs real-time investigation. I will keep you posted on the thread.

    Thanks for your patience.


    Nevyaditha P

    Technical Support Advisor, Premier Services

  • Halon5Halon5 Enthusiast ✭✭

    Hi @Nevyaditha ,

    Spent the afternoon on this with Gailand in (he is always awesome). Lots of traces and Wireshark diags.

    We both ran out of juice but we can clearly see from Wireshark that for certain DNS requests nothing is received (empty).

    Convinced that it was an ISP(DNS) issue the DNS server was moved to Google.. (SAME RESULT).

    We see a clear pattern (audit log illustrates) where for the same domain only certain source IP addresses have this issue but they are consistent. Some "SPF Pass" but others "No SPF Record".

    My probably somewhat naive questions are :-

    What module is making the request? Is it up to date? How does it ask?

    We see good results from NSLOOKUP every time.

    Bottom line. We need SPF, DKIM, DMARC to be totally reliable. Otherwise FILTERS WILL NOT WORK PROPERLY, And that is unsatisfactory.

    Lets see what happens today. I am running up a trial VM so we have a sandbox to play in.


  • David WDavid W SonicWall Employee
    edited June 17

    @Halon5 Hi, This issue really needs to be tracked and documented in the case.

    There wouldn't be any specific details that would be suitable for here at this time.

    I will work with Gailand and see if we can get more specific information for you on the case.


    David Wilbur

     Technical Support Senior Advisor, Premier Services , SME Email Security

  • Halon5Halon5 Enthusiast ✭✭

    Well we have already seen that this is happening elsewhere through the post from @BWC .

    That is the value that this forum provides.

  • SonicAdmin80SonicAdmin80 Newbie ✭

    I also have this problem, I believe it's a bug in Email Security.

    When a domain has many or long TXT records the UDP DNS reply could grow larger than the default 512 bytes originally set in the DNS standard. The resolving client can work around this by either using EDNS to indicate to the server that it can handle UDP responses larger than 512 bytes, or fallback to TCP after it receives an empty response from the server with the "truncated" flag set.

    Email Security doesn't do either when it handles incoming mail. But it actually does fallback to TCP when using the system diagnostics page's SPF query test.

  • SonicAdmin80SonicAdmin80 Newbie ✭

    Gailand has this information and is advancing this on their end. Hopefully we'll get a fix soon.

  • Halon5Halon5 Enthusiast ✭✭

    Thanks @SonicAdmin80 ,

    Your post is clearly and absolutely correct and is in line with what @BWC and I have also seen.

    I think this will help to "put to bed" the "your DNS may be broken" line of questioning.

    I completely agree:-

    ES is incapable of handling an extended response. So the response appears to be VOID.

    This is not a case for an RFE as has been suggested to me. ES is failing to do the job it is expected to do which is to handle SPF, DKIM and DMARC correctly. It is Email Security basics 101 in my mind at least. It requires TOP PRIORITY work. Which would no doubt be better than wasting time on TOC which only successfully broke DKIM.

    And yes, like you, I want it fixed so we can "get on with OUR jobs".


  • SonicAdmin80SonicAdmin80 Newbie ✭

    @Halon5 Yes, packet capture clearly shows the DNS server responding with an empty response with truncated flag set but ES not reacting to it properly by sending another query over TCP.

    Seems like a simple misconfiguration issue on the resolver used, like using the dig command with +ignore and +noedns options which I used to replicate the issue. Or a logic error where a null response with truncated flag doesn't cause another query to be sent.

    Should be quite easy to fix I think either by enabling EDNS or reacting properly to the flag set in the response. Might even be possible to fix without a patch, but probably requires root access by support if the virtual appliance is used.

    I wonder how long this problem has been in ES. At least a couple of months at least, perhaps even longer but it wasn't noticed until 10.0.6.

  • Halon5Halon5 Enthusiast ✭✭

    Hi @SonicAdmin80 ,

    This issue was raised by us 4 years ago in 2016 on Case 3620671

    They moved the SPF checking in the list to the end which was a stupid thing to do IMHO. Probably because it never worked properly.

    That was back in v8 if memory serves correctly.

    They need to fix SPF and put it back to the front.

    There is no need to check anything else if a HARD FAIL has occurred.

  • SonicAdmin80SonicAdmin80 Newbie ✭

    @Halon5 Wow, then it probably isn't that easy to fix for them after all. Although technically it should be simple to just enable EDNS for the DNS resolver, unless they are using some ancient/custom resolver that doesn't even support it.

  • Halon5Halon5 Enthusiast ✭✭

    Hiya @SonicAdmin80 ,

    Yes, Either they don't know how or its "too hard". Maybe the lost some code.... I don't know but it sure seems a little strange.

    I also notice that it is must be how the DNS query is constructed because there is a valid result for the same domain in different situations, namely where they email was originating from. don't work but from internal systems it does.. (for SWL).

    Of course, It's pretty hard to understand any of that without seeing the code.

    I hope they actually do something. It's well overdue.

    Best, Steph.

  • Halon5Halon5 Enthusiast ✭✭

    We have clients who are receiving spam / phishing mail from their own domains because SPF doesn't work.

    We even have a specific filter rule to drop SPF Hard Fails.. Which doesn't work because SW ES cant even figure that out.

    This is a serious problem. It needs to be fixed.

  • David WDavid W SonicWall Employee

    @Halon5 SPF checks are always done against the mail from header and not the from address itself.

    Can you please open a new support case for the issue so a tech can review it with you.

    There is a diag page option to return it to use the PRA instead of the mail from but that effectively disables the use of DKIM and DMARC.

    As far as support for EDNS we are working on this and it would be covered some time after 10.0.9.

    David Wilbur

     Technical Support Senior Advisor, Premier Services , SME Email Security

  • Halon5Halon5 Enthusiast ✭✭

    We are all suffering out here. Its really a disaster. The entire ES SPF mechanism is compromised and that is a serious security flaw.

    The bottom line is that the IETF intentions by way of the RFC need to be satisfied and respected.

    They are not.


  • David WDavid W SonicWall Employee

    @Halon5 Can you please open a new support case for the issue so a tech can review it with you.

    Engineering always follow the RFC's according to how they are written.

    David Wilbur

     Technical Support Senior Advisor, Premier Services , SME Email Security

  • Halon5Halon5 Enthusiast ✭✭

    Here is the case.

  • BWCBWC Cybersecurity Overlord ✭✭✭

    Hi all,

    @David W : "SPF checks are always done against the mail from header and not the from address itself."

    Hopefully we're not talking about the header, because SPF checks should be performed before the message (containg the headers) got transfered and checking is based on the SMTP envelope (HELO and MAIL FROM).

    I had some off-forum exchanges with @Halon5 about this SPF dilemma, and it clearly shows that the system is doing DNS resolving just wrong by not honoring the TC-flag and switching from UDP to TCP (RFC 1123) when the response is larger than 512 bytes. We tested this over and over again with different resolvers and I was under the impression that this bug is confirmed to Steph and addressed for 10.0.8.

    Is this not the case and no fixes are scheduled to get this right?


  • I heard they are working on implementing EDNS but it might be pushed back to 10.0.9.

  • BWCBWC Cybersecurity Overlord ✭✭✭

    Well, with EDNS they can stick with UDP, maybe this does the trick 😉

  • David WDavid W SonicWall Employee

    @BWC Yes, we are talking about the SMTP envelope (HELO and MAIL FROM) as being how checks are performed.

    EDNS was the original problem here not how the SPF checks were being done.

    If EDNS is not supported, than an empty reply would be seen where it was used.

    When we have long periods of time between releases I can understand how there may be some frustration with waiting.

    When new things are added to the roadmap it can take some time for them to be added depending on where they fit in.

    @Halon5 The case you mention is the same case we originally discussed here and any fixes related to that build are not available until it it posted. Some related issues may be resolved in 10.0.8 however EDNS will not be available until sometime later which is why you have had the issues you have seen. If you have some sort of new issue I would like to have you open a new case for it so it can be reviewed by a tech. If they find it is related to the original case then they can mark it as such or open a new engineering ticket should they find that it is something new. We do not want to mix issues together here and assume it is the same problem.

    I appreciate the patience you have both had with this problem.

    David Wilbur

     Technical Support Senior Advisor, Premier Services , SME Email Security

  • Halon5Halon5 Enthusiast ✭✭
    edited September 4

    @David W , @SonicAdmin80 , @BWC

    Well the other part of this problem is that SPF checking is not done in the proper place.

    SPF (Sender Policy Framework) has an IMPERATIVE in the form of " -all " .

    Since SPF is no longer tested "Up Front" as it used to be many releases ago, it is rendered IMPOTENT by ES. (SPF i understand is now at the end of ES testing which is questionable).

    We had added a FILTER RULE (the first) to try and fix this but the broken EDNS also makes this useless.

    Indeed the ES dialog's around SPF Settings have no hope of being effective. ie. senderAuth_config.html

  • Curiously, the SPF policy query in the system diagnostics page works by falling back to TCP. So ES is capable of correct queries, they are just not implemented in the inbound MTA path.

  • David WDavid W SonicWall Employee

    SPF checks do not happen in the MTA that is done in the SMTP Proxy.

    The MTA does not make any judgement on any aspect of a message.

    David Wilbur

     Technical Support Senior Advisor, Premier Services , SME Email Security

  • Has anyone tried the recent 10.0.9 yet? No mention of this issue in either resolved or known issues.

Sign In or Register to comment.