This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Spam Passing SPF/DKIM checks and making it in because skipping header anomaly check

Not sure if theres a design reason for this (or plain oversight) - we have recently been noticing an uptake in spam making it through sophos email.

After looking to them - it seems that at a glance, they should be blocked because headers smtp-from (spam) does not match mail.from (our domain). After investigating abit further I encountered this line "For example, a pass on the SPF check will skip the DKIM and header anomaly check." from KB https://support.sophos.com/support/s/article/KB-000039520?language=en_US

Does this not seem like abit of a red flag? I understand skip auth checks, but header-anomaly should not be one. Any decent mailout/news-letter service is going to ask you to add spf/dkim includes to your dns for there own system - this just seems like your giving bad-actors a easy way to get through?

Would really like some insight or clarification on this. I haven't raised a support case yet - because it could just be "its this way because xyz" but that's my next stop

Note - we currently have everything toggled on, with spam aggressiveness level set to L1

Note - I confirmed there's no conflicting allow rule or policy that could impact the process.



This thread was automatically locked due to age.
  • Just curious: If you pass the SPF Check, the email should be fine? So you are right, if the Threat Actor is hacking your Mailout service and spams you, he would get through, but this is a very "rare" scenario and certainly not a "easy way in". 

    So to compromise a "SPF pass", is actually hard to achieve as an attacker. 

    __________________________________________________________________________________________________________________

  • No - mailout service was an example. This was a direct email.

    For example - we had badguy@nogood.com (smtp.from) send to an internal using admin@ourdomain.com (mail-from) - because @nogood.com had a valid SPF record for itself, it appears to have bypassed checking the headers - thus failing to detect it was pretending to be our domain.

    They are not a member of our domains SPF - they are not sending from any of our whitelisted IPs (nor are there any in the smtp chain).