How to handle false positives (legit emails marked as phishing)?

A legitimate email from a trusted partner just got flagged as phishing. Before you click "release" and move on, it's worth spending five minutes understanding why it was flagged. Because sometimes, the filter got it right for the wrong reasons. And occasionally, what looks like a false positive reveals a real problem worth fixing.

Here's how to actually investigate, not just override.

Step 1: Pull the email headers

Open the flagged message and grab the full email headers. You're looking for three things. Did SPF pass or fail? Did DKIM pass or fail? Did DMARC pass or fail? If any of those are failing, your filter flagged it for a legitimate technical reason, even if the sender is someone you trust personally. That's not a false positive. That's the sender having an authentication problem worth flagging to them.

If you want a quick read on what the headers are actually saying, our free Email Header Analyzer parses them for you in plain English.

Step 2: Look at what triggered the flag

Your security system flagged it for a reason. Check the filter's log or the header's X-Spam fields to find the specific rule that fired. Common culprits include mismatched display names (the "From" name doesn't match the sending domain), suspicious links or URL shorteners in the body, a sending IP that's on a blocklist, and content patterns that overlap with known phishing templates.

Once you know the rule, you can decide whether to adjust it. Whitelisting a sender without understanding why they were flagged is the equivalent of disabling a smoke alarm because it went off once. It might be fine. It might not be.

Step 3: Verify the sender independently

Don't just look at the email itself. Check the sending domain against what you'd expect. Did the email come from captain@deepcurrent.io or from captain@deepcurrent-io.com? One letter difference is a classic spoofing move. If the domain looks right, cross-reference the sending IP against what that domain normally uses. You can use SPF records to see which IPs are authorized to send on that domain's behalf.

Step 4: Release and remediate (if it's genuinely clean)

And if the headers check out, the domain is legitimate, and you can identify a specific rule that over-fired, then yes, release the message to the recipient. After that, tune the rule rather than blindly whitelisting the sender. A narrow exception (this specific domain, this specific content type) is safer than a blanket whitelist that could later be exploited if that sender's domain gets compromised.

Step 5: Tell the sender what you found

If the flag revealed an authentication failure on their side (a broken DKIM signature, an SPF miss, a DMARC rejection), let them know. Most senders genuinely don't realize their emails are failing these checks. Pointing it out is helpful, not accusatory. They can fix it, and you'll stop seeing their emails flagged.

If you're seeing false positives repeatedly from the same sender or domain, that pattern is worth documenting. It might mean your detection rules need calibration, or it might mean the sender's email setup genuinely needs work. Either way, tracking it helps you spot the difference between a one-off and a systemic issue.

Not sure what you're looking at in the headers? Drop us a message on the SOS hotline and we'll take a look with you. No pitch, just help.