A job applicant's resume email got flagged as 'high confidence phishing' and quarantined

A colleague reported that resume emails from job applicants weren’t showing up in the inbox. Checking the mailbox’s quarantine log revealed the cause: a few resume emails had been judged “High Confidence Phish” and dropped straight into quarantine, completely invisible to the recipient.

First, confirm this isn’t a one-off misjudgment on a single email

The quarantine log showed the blocked emails’ subjects were mostly things like “Resume” or “Application for Finance role,” sent from external personal email addresses. The first instinct was to suspect some special rule had been set for a particular hiring round, but investigation confirmed there was no shared, human-configured rule behind these misjudgments - it was purely the mail security service’s own detection model getting it wrong.

With a misjudged email, both sender and recipient assume the other “never received it / never replied” - it was actually caught in the middle by the system

Why resume emails are prone to this misjudgment

Resume emails carry surface features that resemble phishing: from an unfamiliar external personal mailbox, carrying an attachment, with a subject line that’s often short and generic (“Resume,” “Application for [role]”). Cloud mail security detection models are trained on huge sample sets, and this combination of features has a real chance of being flagged as high-risk even when the content is entirely legitimate - especially when the model’s own threshold leans toward “better to over-block than under-block.”

There’s no “turn off this rule” option for this kind of misjudgment

Investigating this confirmed an important constraint: this anti-phishing detection policy is enforced tenant-wide by the cloud mail security service as part of its core security mechanism, with no switch to disable it directly. Even after confirming a particular class of email has an elevated false-positive rate, the entire detection feature can’t simply be turned off, because the same mechanism is also actively catching genuinely malicious phishing emails.

The response

Since the mechanism can’t be disabled at the source, management has to happen downstream instead: check quarantine regularly (daily is recommended), manually verifying and releasing emails confirmed harmless - especially during active hiring periods, proactively reminding the relevant department that “if an applicant’s resume hasn’t shown up, check quarantine first,” rather than assuming the mail system is inherently reliable.

Lessons

1. The more legitimate an email’s content while its surface features resemble malicious mail, the more prone it is to automated misjudgment. Resumes, invoices, quotations - anything with an attachment from an unfamiliar external address - fall into this high-false-positive category, and teams managing the mail system are better off setting expectations with affected departments in advance;
2. Not every security policy can be disabled by a local administrator, especially a cloud vendor’s own built-in core detection mechanism. When facing a policy that’s enforced tenant-wide with a non-trivial false-positive rate, it’s more productive to accept the need for a manual review process early than to keep looking for a way to switch it off;
3. A business process heavily dependent on external email - like hiring - is worth building a dedicated “check quarantine” habit around. The business impact of a mail security policy rarely gets proactively surfaced to the affected department on its own; only proactive checking from IT catches it in time.