I'm experiencing an issue with spam emails containing SVG attachments. They have a subject line like "Caller left 34s April 16, 2026 - 6iujVwcr" and are failing SPF, but they're still making it into my inbox and landing in the spam folder. The email header shows something like "Received: from [127.0.0.1] (104.168.115.168)." Is there any chance the presence of the 127 IP in the header is letting these bypass the filter?
7 Answers
We're facing something similar today. SPF showed a hard fail, and the DMARC reported a temp error, yet the SCL was low, making it hard to deal with these obvious phishing emails! Really puzzling at times.
It sounds like you might be dealing with an SPF soft fail combined with a DMARC setting of p=none. That could potentially allow some messages to slip through even if they fail SPF. Just a thought!
It's worth checking your logs to see if there were issues during SPF record verification. That could give you some insights into what's going wrong.
The 127.0.0.1 in your header is just part of the sending server's process; it isn't evaluated by O365 for SPF checks. The actual connecting IP (104.168.115.x) is the one failing SPF. By default, O365 doesn't reject these emails; they just end up in the junk folder. If you need them blocked outright, consider creating a mail flow rule or tightening your anti-spam policy. Just be cautious—legitimate forwarded emails can also fail SPF. Also, the SVG attachments are a known phishing tactic right now; I'd suggest blocking or quarantining them unless they're absolutely necessary.
Yeah, I noticed the same issue with those fake VM emails. The source IP might even match! I've confirmed these are coming through with a hard fail on SPF too. Curious to see what others think.
Do you have direct send enabled in your setup?
I've seen this situation arise due to customer requests to prevent any emails from being classified as spam. If you notice an SCL score of -1, it indicates that messages are bypassing filters. It’s important to look into any adjustments made to the SCL settings that could be causing this issue.
It’s likely a direct send issue. Check this resource for more details on managing those settings. Just make sure to adjust your configuration properly if you're encountering these problems.
Exactly! We had the same problem with that kind of mail.
But isn't this a case of a hard fail? That’s what I’ve been seeing.