Why phishing in emails bypasses email filters
A traditional email filter checks a message at delivery time: sender domain reputation, links, attachment types.
Email phishing beats this scheme because at the time of the check it looks clean — the link points to a long-known site, and link substitution via redirect triggers after the click, outside the inspection window.
The same logic applies to attachments and login forms. A macro document detonates the payload on the work machine after the gateway has already passed the file by type and extension.
Phishing attachments and login forms on a fake page capture data on the user side — the email service knows nothing about the second scenario at all.
The cost of bypassing an email filter is not only realized incidents. Ambiguous emails go to manual InfoSec review, and false positives on legitimate mailings disrupt departments: employees stop trusting labels and click links indiscriminately.
A separate challenge is that techniques from MITRE ATT&CK change faster than static rules are updated. This is addressed by a model that evaluates the email, the link click, and the page content as one chain rather than three independent checks. We explain how this works and what it gives the email service and InfoSec.
What phishing detection in email traffic provides
Phishing detection in email traffic works not as a single classifier but as a set of independent checks.
A link from an email is detonated in an isolated environment, the domain is checked against sending history, and a discrepancy between the visible link text and the actual address sends the email to quarantine.
The verdict is assembled from several signals, so a fake login page is caught even when the sender has not yet appeared in any blocklist.
This yields two measurable effects. Reduction in miss rate comes from the class of attacks that keyword rules cannot distinguish: an email with no text, with one button and a link to a copy of the corporate login form.
False positive rate is kept at a level where an employee reviews a few quarantines per week, not hundreds — otherwise protection starts being bypassed. Incident tagging is done according to MITRE ATT&CK, so attacker tactics are described consistently across all reports.
A unified attachment policy removes gaps between channels. One set of rules applies to personal mailboxes, shared addresses, forwarding, and mobile clients: macros, executables, and password-protected archives are handled the same way.
Without this, it is enough to send a document to a shared mailbox with softer rules, and the check loses meaning.
For the analyst, this reduces incident response time to minutes. Review of an ambiguous email follows a ready-made card: which signals fired, where the links lead, what has already been detonated in the sandbox — instead of manually exporting headers and attachment headers.
Add to this a “report suspicious email” button for employees: some detections come from them earlier than from automation, and such reports go straight into the common review queue.
Approaches to phishing detection: rules, models, hybrid
No detection method simultaneously delivers high recall and a low false positive rate: signatures catch the known, a model catches variations, behavioral analysis catches what passed static filters.
The choice is determined by email volume and the cost of error: a missed phishing email and a blocked client email have different costs.
In practice, approaches do not compete but form a cascade. Below is what each option covers, when it is sufficient, and where it starts to fail.
How to choose an option
| Option | When it fits | Limitations |
|---|---|---|
| Signatures and blocklists | Known campaigns and recurring domains, need an instant verdict | Catch only what has been seen before, lists age quickly |
| Rules by sender and headers | Domain authentication, inconsistencies in the delivery chain, display name spoofing | Bypassed by correct sender configuration, many false positives |
| Model on email and link features | New campaigns without a signature: text, layout, domain age, mismatch between address and link text | Requires labeling and retraining for drift, outputs a probability, not a verdict |
| Behavioral analysis of link click | Link opened in an isolated environment: redirects, forms, credential prompts | More expensive in latency, does not scale to the entire flow |
| Hybrid scheme with ambiguous emails | High volume and high cost of error: obvious cases are handled by automation | Requires a review channel and feedback of verdicts into the training set |
The cascade is built from cheap checks to expensive ones: first headers and sender reputation, then the model, then isolated link opening. Emails where scores disagree are not silently blocked — they go to review, and the verdict is returned to the training set.
Implementation stages: from email flow audit to handover
The order of work is fixed: each step relies on an artifact from the previous one, and reordering stages breaks calibration.
Skip incident labeling or live traffic validation — the system will confidently block obvious mass mailings and stay silent on targeted emails with a spoofed sender domain.
-
Audit of email flow and email sources. We count correspondence volume, the share of external senders, attachments and links, and collect a list of email gateways and recipient groups. The output is a flow map and points where control is placed without disrupting delivery.
-
Labeling of the incident archive. From quarantine and employee reports, we assemble a corpus: confirmed phishing, legitimate mailings, ambiguous cases. Ambiguous emails are the main source of false blocks, so we review them separately.
-
Control point scheme. We agree on what is blocked immediately, what goes to quarantine, and what is only marked. Here we also describe how an employee disputes a verdict and where their request goes.
-
Configuration of rules and trigger thresholds. We balance false positives and misses: separate thresholds for finance and executives, separate ones for emails with attachments and external links. Each confidence level is mapped to an action.
-
Live traffic validation. The system runs in observation mode: emails are not blocked, verdicts are written to the log and compared with administrator decisions. We review discrepancies manually and adjust rules until a stable result.
-
Acceptance and handover of the solution. We provide response procedures, support service instructions, logs and control metrics, and the procedure for retraining on new incidents. The customer's team performs incident review and rule configuration independently.
Configurations, policies, and incident review procedures
The kit remains with the customer as working artifacts, not a report: rules and thresholds are in a version-controlled configuration file, access policies in the email system, procedures in the knowledge base.
Such a set allows adjusting detection sensitivity in-house, transferring support to another team, and passing internal audit without searching for the solution's authors.
- Rule and threshold configurations — values at which an email is delivered, marked, or quarantined, with an explanation for each change and a rollback procedure to the previous set.
- Email flow diagram — the path of a message from receipt to quarantine or delivery, points where checks trigger, logging points, and environment behavior when an individual component is unavailable.
- Quarantine access policies — which employees and with what role can view, release, and delete delayed emails, restrictions on bulk operations, and mandatory action logging.
- Procedure for reviewing ambiguous emails — response times, escalation procedure to second line, rules for releasing false positives, and actions when a missed attack is detected.
- First-line instructions — step-by-step scenarios for typical employee requests with response templates and a clear boundary beyond which an engineer is involved.
- Configuration and change documentation — where parameters are located, who approves a change, log with reason and date, interaction diagram with the email gateway, user directory, and ticketing system.
- Quality assurance kit — a labeled email sample and the procedure for running it after each change, so a threshold change does not raise the false positive rate unnoticed.
Each item is verified at acceptance: we show how to make a change, how to verify its effect, and how to roll back.
Case study: how a class of missed emails in email was closed
A mail service with tens of thousands of mailboxes came with a specific failure: emails with links to fake login pages passed filters and were delivered.
Sender signatures, blocklists, and static rules filtered out mass mailings, but not emails crafted for a specific organization — with a personal salutation and an address registered a couple of days before sending.
Pre-implementation measurements: the miss rate for this category held at 6–8% of all detected attempts, and the security service manually reviewed about a hundred incidents per week — from link detonation to a conversation with an employee who had already entered credentials.
What was built
The core is a link analysis pipeline: the address is extracted from the email body and attachments, resolved to the final destination, the page is opened in an isolated environment and compared with the reference login form of the target service.
In parallel, we calculate domain features: registration age, provider change, inconsistencies in the certificate chain, visual similarity to a legitimate address.
The solution is integrated into the delivery flow via Exchange Online — the email goes to quarantine before an employee sees it.
Measurements after
After three months of observation, the miss rate for the category dropped to 0.3–0.5%, and the flow of manual reviews decreased approximately fivefold.
We keep the false positive rate below 0.1%: each rule is run against the historical email corpus and enabled first in observation mode.
Metrics were calculated the same way before and after — using a single manual labeling by analysts, where miss rate is calculated as passed emails divided by the sum of passed and blocked.
How does phishing detection differ from anti-spam?
Anti-spam answers the question “is this a mass mailing,” phishing detection answers “is this harmful to a specific recipient right now.” The former evaluates the sender, volume, and similarity of emails; the latter evaluates link content and recipient context. Hence different feature sets and different trigger thresholds.
Sender reputation filtering works while the address or domain has already established a history.
Registration age, complaint history, sending volume, and domain authenticity provide a strong signal on mass waves — and almost zero on an email from a compromised contractor mailbox sent as a single copy.
Link content analysis relies on its behavior, not the email text.
We expand the redirect chain, compare the visible address with the actual one, and inspect the landing page: data entry form, copy of the login page, fresh domain without history, insertion of the recipient address into parameters.
Recipient context assessment covers what is not visible in the link itself: who the sender is relative to the recipient, whether there was prior correspondence, whether the request is typical.
Change of payment details, access to a document, urgency from a familiar name — an email without technical anomalies that a reputation filter will miss, while a context model will flag it.
Therefore the layers do not replace each other: reputation cuts noise before deep analysis, and the link and recipient model catches individual targeted emails. The final assessment is risk for a specific person, not “spam or not spam.”
Common technical concerns before implementation
Before implementation, customers ask the same set of questions: how sensitive detection thresholds are, what happens during peak mailing, and whether they will have to break an already working email gateway. They are all about one thing — how the system behaves on your traffic, not on a demo set.
How is accuracy configured and what about false positives on mailings?
The trigger threshold is a parameter, not a constant. At the start, we run your correspondence history and select the boundary so that the false positive rate on legitimate mailings fits within the limit you set.
We whitelist service notifications, invoices, and digests by sender and domain — even with a similar email structure, the model does not block them; ambiguous ones it marks and sends to quarantine rather than deletes.
What happens during peak mailing — will the gateway handle it?
The check runs in a separate stream, not on the delivery path: the gateway does not wait for the model verdict to hand the email to the recipient. During a peak, the queue stretches and review is delayed, but incoming traffic has priority, and deferred emails are not lost.
We deliberately do not use synchronous checking — it is exactly what brings down the gateway on mass mailings.
We already have a gateway configured with anti-spam and rules. What will happen to it?
Existing rules, whitelists, and routes remain in place. The module connects as an additional layer and can work in two modes: email marking without blocking, when your current logic makes decisions, or quarantine for what is above the threshold. When disabled, the configuration returns to its original state.
Who updates the rules and reviews ambiguous emails?
We take on rule updates: new phishing templates and changes in sender behavior are added to the model regularly, without your involvement.
Ambiguous emails are reviewed by a dedicated analyst — each gets a verdict and a short explanation, which your support service can use to respond to the user. We review borderline cases together with your administrator.
Let's discuss the task: what to prepare for the conversation
A conversation about phishing detection gets to the point fastest if we have the customer's live traffic in front of us, rather than a “general outline” description.
There is no need to prepare a technical specification — what already exists in the email infrastructure and logs is enough. Below is a list that saves us the first round of clarifications and immediately moves the task discussion into an engineering context.
- Email examples: 20–50 real messages in original form — both missed and held by the filter. Both classes matter, otherwise the trigger threshold cannot be configured.
- Full headers and source, not screenshots: it shows whether the sender domain is spoofed, how the delivery path diverges, and whether there is link substitution in the body.
- Current flow diagram: at which node the email stops — at the gateway, on the mail server, or at an external provider — and where the verdict goes.
- Email statistics for one to two months: incoming volume, share of filtered, share of false positives and delay complaints.
- List of past incidents: how many emails arrived, who clicked the link, how it ended, what was already changed after review.
- Quarantine requirements: who reviews the queue, within what time, what may be held, and which notifications must not be delayed.
- Environment constraints: where data may be processed, which channels must not be allowed out, and who on the customer side makes the ambiguous decision.
Describe the task in free form and attach what you have — we will return with an estimate and implementation plan: stages, scope of work, what changes in the current email flow, and which metrics we use to measure the result.
