Join our Newsletter — 33% off our NHI Course
Home› Guides› D3-EF Email Filtering: Stopping Malicious Mail Before Delivery…
Guide Email & Communications Security

D3-EF Email Filtering: Stopping Malicious Mail Before Delivery and Testing It

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 12 November 2026 11 min read
On this page

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

AttributeValue
D3FEND IDD3-EF (d3f:EmailFiltering)
TacticIsolate
Parent techniqueInbound Traffic Filtering (D3-ITF)
Digital artefact (D3FEND relation)filters Email
Where it actsAt the SMTP connection and before mailbox delivery; can also be applied to outbound mail
Distinct fromEmail Removal (D3-ER), which acts after delivery
Typical data sourcesGateway and platform message trace, quarantine logs, filtering verdict headers
Main limitationOnly 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 IDTechniqueD3FEND relation (inferred via Email)What filtering does about it
T1566.001Spearphishing Attachmentproduces EmailAttachment scanning, file type blocking and sandboxing reject or quarantine the payload
T1566.002Spearphishing Linkproduces EmailURL reputation, rewriting and phishing classification
T1534Internal Spearphishingproduces EmailOnly if internal mail passes through the same filters; a perimeter-only gateway never sees it
T1667Email Bombingproduces EmailBulk and rate-based filtering limit the flood; see MITRE ATT&CK T1667 Email Bombing
T1114.001Local Email Collectionreads EmailWeak 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 classWhere it sitsStrengthWatch for
Secure email gatewayIn the MX path, before the mail platformRejects at SMTP time; one policy for all inbound mailDirect delivery to the platform that bypasses the MX record; internal mail never passes it
Native filtering in the mail platformInside the hosted mailbox serviceSees inbound, outbound and internal mail with platform contextOrganisation-wide bypass rules and allow lists
API-based (integrated) email securityConnected to the mailbox through the platform APIContext from user behaviour and internal mailOften acts just after delivery, which is Email Removal rather than pure pre-delivery filtering
Self-hosted MTA filtersMilters or content filters on an organisation's own mail serversFull control of policy and rejection logicSignature 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

  1. 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.
  2. 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.
  3. Block risky file types. Block executable and script attachment types your business does not exchange, and inspect archives, including nested ones.
  4. 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.
  5. 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.
  6. 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.
MetricExample target (NHI Mgmt Group suggestion, not a standard)Why it matters
Share of inbound mail that passed through filtering100%Unfiltered routes are the usual bypass
User-reported phishing that the filter delivered, per monthFallingMeasures misses, not just blocks
Allow list and bypass entries without owner or expiryZeroPolicy completeness, D3FEND's stated consideration
Monthly test suite (EICAR, blocked type, direct delivery, internal) passingAll testsProves the pipeline end to end
Legitimate messages released from quarantineTracked and reviewedFalse 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

FrameworkReferenceRelevance
NIST SP 800-53 Rev 5SI-8 Spam Protection; SI-8(2) Automatic UpdatesSpam protection at entry points, with updated mechanisms
NIST SP 800-53 Rev 5SI-3 Malicious Code ProtectionMalware scanning of attachments
NIST CSF 2.0DE.CM-09, PR.PS-05Monitoring of software and data for adverse events; preventing execution of unauthorised software
CIS Controls v8.19.6 Block Unnecessary File Types; 9.7 Deploy and Maintain Email Server Anti-Malware ProtectionsEmail safeguards this technique implements
ISO/IEC 27001:2022 Annex AA.8.7 Protection against malware; A.5.14 Information transferMalware controls and rules for electronic messaging
MITRE ATT&CKM1049 Antivirus/Antimalware; M1031 Network Intrusion Prevention; M1021 Restrict Web-Based Content; M1017 User TrainingMitigations ATT&CK lists for phishing that overlap with filtering
MITRE D3FENDD3-ITF (parent), D3-EFHierarchy

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

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

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 12 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org