Every inbound email arrives from a mail server, and most organisations accept it or reject it on a reputation verdict they never see or test. MITRE D3FEND names this countermeasure Sender MTA Reputation Analysis (D3-SMRA) and defines it as "Characterizing the reputation of mail transfer agents (MTA) to determine the security risk in emails." It sits in the Detect tactic as a child of Message Analysis (D3-MA), next to its only sibling, Sender Reputation Analysis (D3-SRA), and D3FEND models it as analysing the Email artefact. This card explains what D3-SMRA scores, which ATT&CK techniques D3FEND relates it to, where it lives in an email stack, how to prove it works and where it fails. It is written for email security engineers and detection teams; the wider programme is in the Email Security Guide.
Key takeaways
- D3-SMRA scores the server, not the person. It rates the sending MTA (its IP address and host) from how it has behaved towards your organisation, while D3-SRA rates the sender address.
- History with your organisation is the core signal. D3FEND's feature list is about first contact, volume, spread across your recipients and replies, which external reputation lists cannot know.
- Trusted infrastructure is shared infrastructure. Large cloud mail platforms carry good reputations and also carry attacker mail from compromised or newly registered accounts, so MTA reputation alone cannot clear a message.
- The ATT&CK mapping is inferred. D3FEND relates D3-SMRA to phishing and email techniques only because they share the Email artefact, so treat it as relevance, not proof of blocking.
- Verify the inputs. Most failures are a wrong connecting IP (behind a gateway or relay), a dead DNS list zone, or an allow list that silently bypasses the score.
D3-SMRA at a glance
| Field | D3-SMRA Sender MTA Reputation Analysis |
|---|---|
| D3FEND ID | D3-SMRA |
| Tactic | Detect |
| Parent technique | Message Analysis, D3-MA (sibling: Sender Reputation Analysis, D3-SRA) |
| Digital artefact | Email (D3FEND: the technique "analyzes" Email) |
| What it scores | The mail transfer agent that handed the message to your perimeter: connecting IP address, its host name and its history with your organisation |
| Typical implementation points | Secure email gateway or cloud email security service, the MTA's own connection-time checks, DNS-based block and allow lists, SIEM analytics on message trace data |
| Verdict bands in D3FEND | Unrated, neutral, trusted, suspicious, malicious |
| Main limitation | Mail sent through reputable shared platforms or compromised legitimate servers inherits a good MTA score |
| D3FEND reference | Graphus Inc patent US20170324767A1, systems for detecting targeted attacks in the email channel |
How it works
D3FEND's knowledge base describes a sender MTA trust rating as "an indicator of the level of security risk and/or a trust level associated with sender MTAs in an email header." It lists the features that feed the rating, all drawn from the Graphus patent it cites:
- Tenure: how long the MTA has interacted with the enterprise.
- Domain spread: how many sender domains send through that MTA.
- Recipient spread: how many recipients in the enterprise the MTA sends to.
- Volume: how many emails have been received from the MTA.
- Two-way traffic: how many email replies have been received from the MTA.
Longer tenure and higher volume push the rating up. The output is a category: unrated, neutral, trusted, suspicious or malicious. D3FEND adds one consideration: a legitimate MTA can lose trust over time if its sender's domain is spoofed and used for unauthorised mail.
In practice, products combine that internal history with external signals that describe the same server. The table below separates the two, because they fail in different ways.
| Signal | Source | What it tells you | Typical weakness |
|---|---|---|---|
| First seen date and tenure | Internal (your message logs) | Whether this server has ever delivered to you before | Needs months of retained trace data to be meaningful |
| Domains per MTA | Internal | A host suddenly sending for many unrelated domains looks like a spam relay or bulk platform | Legitimate shared platforms always look like this |
| Recipients reached and reply ratio | Internal | Real correspondents get replies; broadcast phishing rarely does | Marketing and notification servers legitimately get no replies |
| DNS block list (DNSBL) listing | External, RFC 5782 style zones | Whether a list operator has seen the IP send abuse | Lag after a new IP starts sending; listing policies differ |
| Reverse DNS and HELO consistency | Connection time | Whether the IP resolves to a host name that resolves back, and matches the greeting | Easy for a prepared attacker to set up correctly |
| Authentication results | SPF, DKIM, DMARC (recorded in the Authentication-Results header, RFC 8601) | Whether this MTA is authorised to send for the claimed domain | Says nothing about whether the domain or account is trustworthy |
RFC 5782 describes how DNS block lists work: the client reverses the IPv4 octets, appends the list's zone and queries an A record (conventionally 127.0.0.2 for a listed address), with an optional TXT record giving the reason. The RFC is Informational, from the IRTF Anti-Spam Research Group. It requires every list to carry 127.0.0.2 as a test entry and never to list 127.0.0.1, which gives you a simple liveness check (see verification below).
Authentication and MTA reputation answer different questions. SPF and DMARC confirm that a server may send for a domain; MTA reputation asks whether that server has a track record with you. See the DMARC, SPF and DKIM Guide and the D3FEND hardening counterpart D3-TAAN Transfer Agent Authentication.
ATT&CK techniques and D3-SMRA
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-SMRA. Each row below is inferred because D3-SMRA analyses Email and the ATT&CK technique produces or acts on Email; the D3FEND page calls these mappings "inferred, experimental" (checked November 2026). The D3FEND page showed the first four rows; T1667 Email Bombing is linked to the Email artefact in the D3FEND ontology release. The last column is NHI Mgmt Group's assessment, not part of D3FEND.
| ATT&CK ID | Technique (tactic) | What MTA reputation adds (NHI Mgmt Group assessment) |
|---|---|---|
| T1566.001 | Spearphishing Attachment (Initial Access) | Useful against attacker-run or newly stood-up servers; little effect when the attachment comes from a reputable cloud mail platform |
| T1566.002 | Spearphishing Link (Initial Access) | Same as above; pair it with D3-UA URL Analysis for the link itself |
| T1534 | Internal Spearphishing (Lateral Movement) | Minimal: internal mail travels through your own trusted MTAs, so a sender-level or behaviour signal is needed instead |
| T1114.001 | Local Email Collection (Collection) | None in practice: collection happens on the host, not at the inbound MTA; the relationship exists only through the shared artefact |
| T1667 | Email Bombing (Impact) | Moderate: a burst from many new, unrated MTAs is a usable signal, although bombing often uses legitimate sign-up and newsletter servers |
For the attacker side see the T1566 Phishing guide, T1534 Internal Spearphishing and T1667 Email Bombing.
Where it is implemented
- Secure email gateways and cloud email security services: connection filtering on the source IP, vendor reputation feeds, and admin allow and block lists, applied before content scanning. See the Email Security Buyer's Guide for evaluation criteria.
- Self-hosted MTAs: connection-time DNS list lookups, reverse DNS checks and rate limits per client IP, configured in the MTA or a policy service.
- SIEM or data lake analytics: your own tenure, volume, domain spread and reply ratio per connecting IP, built from message trace or gateway logs. This is where the D3FEND feature list is most directly implemented. See the Email Gateway and Message Trace Detection Guide.
- Threat intelligence platforms: enrichment of the connecting IP with external reputation, shared with D3-IPRA IP Reputation Analysis, which covers feed quality in depth.
Choosing where to score
| Situation | Better choice | Why |
|---|---|---|
| Small organisation on a cloud mail suite | Rely on the provider's connection filtering; add SIEM analytics only for high-risk mailboxes | Provider reputation data is broad; building your own baseline needs trace data and analyst time |
| Large organisation with a gateway in front of the mail suite | Score at the gateway and pass the original connecting IP downstream | The mail suite otherwise sees only the gateway's IP and its reputation logic goes blind |
| Regulated or targeted organisation | Add your own first-seen and reply-ratio analytics on top of vendor scores | Targeted senders are new to you even when they are clean on public lists |
Implementation steps
- Find the true connecting IP. Each relay prepends a Received line (RFC 5321), so identify which header your perimeter writes and trust only that one and the hops below it. If a gateway or relay sits in front, configure the downstream system to read the original client IP.
- Inventory your own and partner sending infrastructure. Start from the Email Sending Sources Inventory Template so known senders are not scored as unrated.
- Enable external reputation in monitor mode. Tag rather than reject for two to four weeks (an example period, not a standard) and review what would have been blocked.
- Build the internal baseline. Per connecting IP and /24: first seen, messages, distinct sender domains, distinct recipients, replies. Retain at least 90 days as a starting example.
- Define bands and actions. For example: malicious, reject at SMTP; suspicious, quarantine; unrated, deliver with extra content and URL scanning; trusted, normal path. Never let "trusted" skip malware scanning.
- Keep allow lists narrow and expiring. Allow exact IPs or small ranges with an owner and review date; record why.
- Roll back safely. Keep actions as policy changes you can revert to tagging, and keep quarantined mail long enough to release if a verdict was wrong.
How to verify it works
- DNS list liveness: query each configured zone for the RFC 5782 test entry 127.0.0.2 (must answer) and 127.0.0.1 (must not). Alert if either check fails, because an expired list domain can start answering everything.
- Header check: send test mail from an external host you control and confirm the logged connecting IP is that host, not a relay or your gateway.
- Verdict check: send from a newly provisioned sending host and confirm it lands in the "unrated" band with the expected action.
- Allow list audit: list every IP allow entry and confirm each still has an owner and a business reason.
| Metric | What it shows |
|---|---|
| Share of inbound messages with a correctly identified connecting IP | Whether the input is trustworthy at all (target 100 percent) |
| Phishing reports where the sending MTA was unrated or suspicious at delivery | How much of your missed phishing the score could have caught |
| False positive releases from MTA-based quarantine per week | Whether thresholds are too aggressive |
| Allow list entries older than their review date | Drift in exceptions that bypass the score |
| DNS list health check failures per month | Whether external inputs are actually live |
Limits, bypasses and failure patterns
- Reputable shared senders: attackers send from accounts on large cloud mail and marketing platforms, so the MTA is trusted by everyone. Sender-level and content analysis must carry the decision; see D3-SRA Sender Reputation Analysis.
- Compromised legitimate servers: a supplier's real mail server, once compromised, sends with years of good history. D3FEND's own consideration (trust erodes after spoofing) works slowly.
- Snowshoe sending: volume spread thinly across many fresh IPs keeps each below thresholds. Score at /24 and ASN level as well as single IP.
- Gateway blindness: the mail suite behind a gateway sees only the gateway IP, so its reputation logic rates every message the same.
- Allow lists as permanent bypass: an IP allow entry added for one delivery problem stays for years and skips scoring for whoever later uses that address.
- Dead DNS lists: a retired list zone left in configuration either returns nothing (silent loss) or, if the domain is re-registered, can list everything.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SI-8 Spam Protection; SI-4 System Monitoring | Spam protection at entry points; monitoring inbound mail for indicators |
| NIST CSF 2.0 | DE.CM-01; DE.AE-02 | Monitoring network services and analysing adverse events |
| CIS Controls v8.1 | Control 9 Email and Web Browser Protections | See the CIS Control 9 Email and Web Browser Protections Guide |
| ATT&CK mitigations | M1054 Software Configuration; M1049 Antivirus/Antimalware; M1017 User Training | Gateway configuration and scanning that the reputation verdict feeds; see M1054 Software Configuration |
Practitioner checklist
- Confirm which Received header your perimeter writes and that every scoring system reads the original connecting IP.
- Inventory your own and partner sending infrastructure before turning on blocking.
- Run external reputation in tag-only mode first and review would-be blocks.
- Build first-seen, volume, domain spread, recipient spread and reply ratio per connecting IP and /24.
- Map rating bands to actions; never let a trusted MTA skip malware or URL scanning.
- Give every IP allow entry an owner and an expiry date.
- Test DNS list zones daily with 127.0.0.2 and 127.0.0.1.
- Pair MTA scoring with sender-level reputation and URL analysis.
Standards and references
- MITRE D3FEND: Sender MTA Reputation Analysis (D3-SMRA)
- MITRE D3FEND: Message Analysis (D3-MA)
- Graphus Inc: Systems and methods for detecting and/or handling targeted attacks in the email channel (US20170324767A1)
- IETF: RFC 5782 DNS Blacklists and Whitelists
- IETF: RFC 5321 Simple Mail Transfer Protocol
- IETF: RFC 8601 Message Header Field for Indicating Message Authentication Status
- MITRE ATT&CK: T1566 Phishing
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Email Security Guide · D3-SRA Sender Reputation Analysis · D3-IPRA IP Reputation Analysis · Email Forensics and Header Analysis Guide · MITRE D3FEND Guide