Phishing links, malicious attachments and mail floods all arrive through the same SMTP path, and a filter that rejects them before they reach a mailbox removes the user from the decision. MITRE D3FEND names this countermeasure Email Filtering (D3-EF) and defines it as "Filtering incoming email traffic based on specific criteria." It sits under the Isolate tactic as a child of Inbound Traffic Filtering (D3-ITF), and D3FEND models it as filtering the Email artefact. This card covers what the technique does and does not include, which ATT&CK techniques D3FEND relates to it, the filtering stages in common mail platforms, how to test that the filter works and where it is bypassed. It is for email administrators and detection engineers; the wider email programme is in the Email Security Guide.
Key takeaways
- Pre-delivery by definition. D3FEND says Email Filtering is distinct from Email Removal because it prevents a message from reaching the inbox; pulling a delivered message back is a different technique.
- Policy completeness is the whole game. D3FEND's only stated consideration is that filter effectiveness depends on the completeness of the filter policies, so allow lists and bypass rules matter as much as detection engines.
- Five related ATT&CK techniques. Through the Email artefact D3FEND relates D3-EF to Spearphishing Attachment (T1566.001), Spearphishing Link (T1566.002), Internal Spearphishing (T1534), Local Email Collection (T1114.001) and Email Bombing (T1667).
- Internal mail needs filtering too. D3FEND notes the technique can also apply to outbound traffic, and internal spearphishing from a compromised account never crosses the perimeter gateway.
- Test with safe samples. The EICAR test file, including its nested zip variant, shows whether attachment scanning and archive inspection work end to end.
D3-EF at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-EF (d3f:EmailFiltering) |
| Tactic | Isolate |
| Parent technique | Inbound Traffic Filtering (D3-ITF) |
| Digital artefact (D3FEND relation) | filters Email |
| Where it acts | At the SMTP connection and before mailbox delivery; can also be applied to outbound mail |
| Distinct from | Email Removal (D3-ER), which acts after delivery |
| Typical data sources | Gateway and platform message trace, quarantine logs, filtering verdict headers |
| Main limitation | Only as complete as its policies; bypass rules and allow lists open holes |
How it works
D3FEND's article says mail filters can scan inbound messages at the initial SMTP connection stage to detect and reject email containing spam and malware. In practice filtering is a pipeline of checks, each with its own verdict and action:
- Connection filtering: sender IP reputation and connection behaviour, evaluated before the message body is accepted. Most bulk spam is rejected here.
- Sender authentication: SPF, DKIM and DMARC results feed spoofing verdicts. These protocols are covered in the DMARC, SPF and DKIM Guide and the related countermeasure page D3-MAN Message Authentication.
- Content and attachment filtering: malware scanning, file type blocking, archive inspection and, in many products, detonation in a sandbox.
- URL filtering: reputation checks and rewriting of links for time-of-click checks.
- Spam and phishing classification: scoring that drives actions such as reject, quarantine, junk folder or tag.
- Organisation rules: transport or routing rules written by administrators, including allow lists and exceptions.
D3FEND cites one reference for the technique, a Nokia patent on anonymous remailing and filtering of electronic mail. The operational guidance comes from platform documentation and NIST SP 800-177 Rev. 1, Trustworthy Email, which covers sender authentication, transmission security with TLS and content security with S/MIME.
ATT&CK techniques D3FEND relates to D3-EF
Relationship type: inferred only. D3FEND does not hand-map D3-EF to ATT&CK. These relationships are derived through the shared Email artefact: D3-EF filters Email, and each ATT&CK technique below produces or reads Email in the D3FEND ontology (D3FEND 1.6.0, checked November 2026). The D3FEND technique page labels its relations inferred and experimental and shows four of them; the ontology adds Email Bombing through the same artefact. Every ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via Email) | What filtering does about it |
|---|---|---|---|
| T1566.001 | Spearphishing Attachment | produces Email | Attachment scanning, file type blocking and sandboxing reject or quarantine the payload |
| T1566.002 | Spearphishing Link | produces Email | URL reputation, rewriting and phishing classification |
| T1534 | Internal Spearphishing | produces Email | Only if internal mail passes through the same filters; a perimeter-only gateway never sees it |
| T1667 | Email Bombing | produces Email | Bulk and rate-based filtering limit the flood; see MITRE ATT&CK T1667 Email Bombing |
| T1114.001 | Local Email Collection | reads Email | Weak relation: collection of mail already on a host is not an inbound filtering problem; filtering reduces what lands there |
The attacker side of the first three is covered in MITRE ATT&CK T1566 Phishing and MITRE ATT&CK T1534 Internal Spearphishing.
Where it is implemented
| Implementation class | Where it sits | Strength | Watch for |
|---|---|---|---|
| Secure email gateway | In the MX path, before the mail platform | Rejects at SMTP time; one policy for all inbound mail | Direct delivery to the platform that bypasses the MX record; internal mail never passes it |
| Native filtering in the mail platform | Inside the hosted mailbox service | Sees inbound, outbound and internal mail with platform context | Organisation-wide bypass rules and allow lists |
| API-based (integrated) email security | Connected to the mailbox through the platform API | Context from user behaviour and internal mail | Often acts just after delivery, which is Email Removal rather than pure pre-delivery filtering |
| Self-hosted MTA filters | Milters or content filters on an organisation's own mail servers | Full control of policy and rejection logic | Signature and rule maintenance is your job |
Mail platforms are listed alphabetically; examples only, with each platform's own terms.
- Google Workspace Gmail: the Spam, Phishing and Malware settings in the Admin console apply per organisational unit. The Spam setting includes approved senders lists that can bypass spam filters, an option to bypass spam filters for internal senders, and an option to put spam in administrative quarantine; messages released from quarantine are checked against Gmail spam filters again.
- Microsoft Exchange Online Protection: filtering runs in order through connection filtering, anti-malware, mail flow rules and then anti-spam and anti-phishing, each configured by its own policy type. Default threat policies cover all recipients and Standard and Strict preset security policies are available. Malware and high confidence phishing are quarantined and, by default, only admins can act on them; the Tenant Allow/Block List holds overrides.
Gateway placement, MX routing and post-delivery remediation are covered in depth in the Email Security Guide, and hardening of the filter itself in Securing the email security gateway itself.
Implementation steps
- Map every path mail takes. List MX records, connectors, third-party sending services and any route that delivers straight to the mail platform. A filter is only as good as the share of mail that passes through it.
- Turn on the strongest baseline. Apply the platform's recommended or strict preset to a pilot group first, with quarantine rather than junk folder for high-confidence phishing and malware.
- Block risky file types. Block executable and script attachment types your business does not exchange, and inspect archives, including nested ones.
- Filter internal and outbound mail. Make sure internal messages are scanned so a compromised mailbox cannot spearphish colleagues unfiltered, and that outbound spam controls are on.
- Audit bypasses. Export every allow list entry, approved sender and transport rule that skips filtering. Remove whole-domain bypasses for public mail domains and give each remaining entry an owner and expiry.
- Roll out by group and keep a rollback. Widen from the pilot after reviewing false positives in quarantine; keep the previous policy export so a change can be reversed quickly.
How to verify it works
- Malware test file: send the EICAR test file from an external test account, plain and inside the single and nested zip variants EICAR provides. Expect rejection or quarantine for the first two; the nested zip shows whether archive inspection goes more than one level deep.
- Blocked file type test: send a harmless file with a blocked extension and confirm the action and the message trace entry.
- Path coverage test: send a test message directly to the mail platform, bypassing the MX record, and confirm it is still filtered or refused.
- Internal path test: send the EICAR test file between two internal test mailboxes.
- Verdict headers: inspect received headers on test messages to confirm which filtering stages ran.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Share of inbound mail that passed through filtering | 100% | Unfiltered routes are the usual bypass |
| User-reported phishing that the filter delivered, per month | Falling | Measures misses, not just blocks |
| Allow list and bypass entries without owner or expiry | Zero | Policy completeness, D3FEND's stated consideration |
| Monthly test suite (EICAR, blocked type, direct delivery, internal) passing | All tests | Proves the pipeline end to end |
| Legitimate messages released from quarantine | Tracked and reviewed | False positives drive users to request bypasses |
Limits and bypasses
- Allow lists and bypass rules: a sender or domain on an approved list skips spam filtering, so a spoofed or compromised listed sender walks straight in.
- Compromised trusted senders: mail from a real supplier's hijacked account passes authentication; content and URL checks still apply, sender reputation does not help.
- Delayed weaponisation: a link that is clean at delivery and malicious later defeats delivery-time checks unless time-of-click protection or post-delivery removal is in place.
- Encrypted and password-protected archives: content the filter cannot open cannot be scanned; policy must decide whether to quarantine it.
- Non-email channels: chat and collaboration messages, calendar invitations created by API, and QR codes in images may avoid traditional filtering. See QR Code Phishing (Quishing) Guide and Calendar Invite Phishing Detection.
Common failure patterns
- Whole-domain allow lists for public mail providers: every attacker with a free account on that provider is exempt.
- Gateway bypass through direct delivery: the mail platform accepts messages from any source instead of only the gateway's connector.
- Junk folder instead of quarantine for phishing: users open high-confidence phishing from the junk folder.
- Internal mail unfiltered: a compromised account sends malicious attachments to colleagues and nothing inspects them.
- No owner for filter policy: exceptions accumulate after every business complaint and none expire.
Where identity fits
Applications that send mail through API keys for delivery services, and AI agents with mailbox access, are senders and readers your filters must account for. Mail sent with a stolen delivery API key can pass sender authentication for your own domain. See the SendGrid, Mailgun and Mailchimp API Keys Security Guide and AI Agent Email Access Security.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-8 Spam Protection; SI-8(2) Automatic Updates | Spam protection at entry points, with updated mechanisms |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Malware scanning of attachments |
| NIST CSF 2.0 | DE.CM-09, PR.PS-05 | Monitoring of software and data for adverse events; preventing execution of unauthorised software |
| CIS Controls v8.1 | 9.6 Block Unnecessary File Types; 9.7 Deploy and Maintain Email Server Anti-Malware Protections | Email safeguards this technique implements |
| ISO/IEC 27001:2022 Annex A | A.8.7 Protection against malware; A.5.14 Information transfer | Malware controls and rules for electronic messaging |
| MITRE ATT&CK | M1049 Antivirus/Antimalware; M1031 Network Intrusion Prevention; M1021 Restrict Web-Based Content; M1017 User Training | Mitigations ATT&CK lists for phishing that overlap with filtering |
| MITRE D3FEND | D3-ITF (parent), D3-EF | Hierarchy |
Related countermeasures
- Inbound Traffic Filtering (D3-ITF): the parent family. See D3-ITF Inbound Traffic Filtering.
- Email Removal (D3-ER): post-delivery removal of messages that slipped through. See D3-ER Email Removal.
- Message Authentication (D3-MAN): the authentication results filters rely on. See D3-MAN Message Authentication.
- Emulated File Analysis (D3-EFA): the sandbox detonation many filters use for attachments. See D3-EFA Emulated File Analysis.
Practitioner checklist
- Confirm every inbound route, including direct delivery to the platform, passes through filtering.
- Quarantine malware and high-confidence phishing; do not send them to the junk folder.
- Block executable and script attachment types the business does not need and inspect nested archives.
- Scan internal mail and turn on outbound spam controls.
- Give every allow list entry and filter bypass an owner and expiry; remove public-domain bypasses.
- Run the EICAR, blocked-type, direct-delivery and internal tests monthly.
- Feed message trace and quarantine logs to the SIEM and correlate with user reports.
- Pair filtering with post-delivery removal for threats detected later.
Standards and references
- MITRE D3FEND: Email Filtering (D3-EF)
- NIST: SP 800-177 Rev. 1 Trustworthy Email
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-8 Spam Protection)
- MITRE ATT&CK: T1566 Phishing
- Google Workspace Admin Help: Customise spam filter settings
- Microsoft Learn: Exchange Online Protection overview
- EICAR: Anti-malware test file
Related NHI Mgmt Group resources: Email Security Guide · MITRE ATT&CK T1566 Phishing · CIS Control 9 Email and Web Browser Protections Guide · Email Gateway and Message Trace Detection Guide · MITRE D3FEND Guide