Email still lets any server claim to send on behalf of any domain unless the domain owner publishes, and receivers check, who is allowed to. D3-TAAN Transfer Agent Authentication is the MITRE D3FEND countermeasure for that check: D3FEND defines it as "Validating that server components of a messaging infrastructure are authorized to send a particular message." It sits in the Harden tactic under Message Hardening, and D3FEND's knowledge base describes it for email through SPF, DKIM and DMARC. This card explains what D3-TAAN hardens, how D3FEND relates it to ATT&CK, where it is implemented, how to verify it and where it stops helping. It is written for email administrators, security engineers and SOC teams who already know the three protocols by name and want a precise, testable view. For full configuration guidance, see the DMARC, SPF and DKIM Guide.
Key takeaways
- D3-TAAN authenticates the sending infrastructure, not the person. SPF, DKIM and DMARC show that a server or signing key is authorised for a domain; they say nothing about whether the content is safe.
- D3FEND lists no ATT&CK mapping for D3-TAAN. ATT&CK itself names SPF, DKIM and DMARC under mitigation M1054 Software Configuration for phishing and email spoofing, which is the practical link.
- Only DMARC protects the visible From address. D3FEND notes that SPF alone verifies the Return-Path domain and does not prevent spoofing of the displayed From.
- The standards moved in 2026. RFC 9989 (May 2026, Standards Track) obsoletes the informational RFC 7489 for DMARC, removes the pct tag and replaces the Public Suffix List with a DNS tree walk.
- Enforcement is the goal, monitoring is the start. A DMARC record at p=none produces reports but asks receivers to do nothing with failing mail.
D3-TAAN at a glance
| Field | D3-TAAN Transfer Agent Authentication |
|---|---|
| D3FEND ID | D3-TAAN |
| Tactic | Harden |
| Parent technique | Message Hardening (siblings: Message Authentication, Message Encryption) |
| Digital artefacts | None stated for D3-TAAN in the D3FEND data (checked November 2026) |
| ATT&CK mapping in D3FEND | None |
| D3FEND references | RFC 6376 (DKIM), RFC 7208 (SPF), RFC 7489 (DMARC, since obsoleted by RFC 9989) |
| What it changes | Receiving mail servers can tell authorised senders for a domain from unauthorised ones and apply the domain owner's policy |
| Main limitation | Indirect mail flows (forwarding, mailing lists), look-alike domains and compromised legitimate senders |
How it works
D3FEND's knowledge base article covers three mechanisms. Each publishes data in DNS and each answers a different question:
| Mechanism | Standard and status | What it authenticates | Key details |
|---|---|---|---|
| SPF | RFC 7208, Standards Track | That the connecting server's IP address is authorised for the HELO/EHLO domain and the MAIL FROM (Return-Path) domain | Results: none, neutral, pass, fail, softfail, temperror, permerror. Qualifiers + - ~ ?. A limit of 10 DNS-querying terms (include, a, mx, ptr, exists, redirect); exceeding it gives permerror. The ptr mechanism is marked "do not use". |
| DKIM | RFC 6376, Standards Track, updated by RFC 8301 | That a signing domain (d=) signed the listed headers (h=) and body hash (bh=) and they have not changed | Public key at selector._domainkey.domain. RFC 8301: sign with rsa-sha256, never rsa-sha1; keys at least 1024 bits and should be at least 2048. The optional l= body length tag lets content be appended without breaking the signature. |
| DMARC | RFC 9989, Standards Track, May 2026 (obsoletes RFC 7489 and RFC 9091) | That the visible From domain aligns with a domain that passed SPF or DKIM | Policy p=none, quarantine or reject; alignment relaxed (default) or strict via aspf and adkim; np for non-existent subdomains; t for test mode; aggregate reports (RFC 9990) and failure reports (RFC 9991). |
D3FEND's considerations are worth stating plainly, because they are where deployments go wrong: records must be kept current, DKIM signing keys need maintenance, SPF without DKIM and DMARC does not protect the displayed From address, unsigned parts of the message can be altered, and email authentication "does not replace the need to do email content analysis". RFC 6376 makes the same point from the other side: a valid DKIM signature asserts only that the hashed content has not changed, and the signing domain does not have to match any other header. DMARC's alignment test is what ties these results to the From address a user sees. For the DMARC changes in detail, see the DMARCbis Changes Guide.
ATT&CK relationships
Relationship type: none in D3FEND. D3FEND lists no ATT&CK technique, inferred or direct, and no digital artefact for D3-TAAN (checked November 2026). The rows below come from ATT&CK v20 itself: mitigation M1054 Software Configuration tells defenders to "use anti-spoofing and email authentication mechanisms" based on SPF and DKIM and enforced through DMARC policies. They are NHI Mgmt Group's view of where D3-TAAN applies, not a D3FEND mapping.
| ATT&CK ID | Technique | What D3-TAAN changes (NHI Mgmt Group assessment) |
|---|---|---|
| T1684.002 | Social Engineering: Email Spoofing | Strong for exact-domain spoofing once DMARC is at quarantine or reject and receivers honour it; none for look-alike domains |
| T1566.001, T1566.002 | Phishing: Spearphishing Attachment, Spearphishing Link | Partial: removes your exact domain as a sender identity for outsiders; does not judge attachments or links |
| T1598 | Phishing for Information | Partial, for the same reason |
| T1534 | Internal Spearphishing | Minimal: mail sent from a compromised internal mailbox passes authentication |
See the MITRE ATT&CK T1566 Phishing, the MITRE ATT&CK T1598 Phishing for Information and the MITRE ATT&CK T1684 Social Engineering.
Where it is implemented
| Component | Role | What to configure |
|---|---|---|
| Authoritative DNS for each domain | Publishes the policy | SPF TXT record, DKIM public keys per selector, _dmarc record; change control on all three |
| Outbound mail servers and email platforms | Sign and send | DKIM signing with rsa-sha256 and 2048-bit keys, aligned d= domain, no l= tag |
| Third-party senders (marketing, ticketing, billing, HR systems) | Send on your behalf | Aligned DKIM with a delegated selector or subdomain, or SPF include within the lookup limit |
| Inbound gateway or receiving platform | Verifies and applies policy | Evaluate SPF, DKIM and DMARC, honour sender policies, record results in Authentication-Results headers |
| Report processing | Turns reports into action | A mailbox or service for rua aggregate reports, with owners for each sending source |
Where identity and NHIs fit
Every authorised sender is a non-human identity: an SMTP relay, a SaaS platform with a delegated DKIM key, or an application holding an email API key. Those credentials let anyone who holds them send mail that passes SPF, DKIM and DMARC. Inventory them like other machine credentials, with owners, scopes and rotation, and retire SMTP basic authentication where platforms offer alternatives. See the Exchange Online SMTP AUTH Basic Auth Retirement and the Email Identity and BEC Guide.
Implementation steps
- Inventory domains and senders. List every domain you own, including parked domains that never send mail, and every system that sends mail as any of them.
- Lock down non-sending domains. Publish an SPF record that authorises no senders and a DMARC record at p=reject.
- Publish SPF and DKIM for sending domains. Keep SPF under the 10-lookup limit; sign with rsa-sha256 using 2048-bit keys and plan selector-based key rotation.
- Start DMARC in monitoring mode. Publish p=none with an rua address and read aggregate reports. RFC 9989 says legitimate streams that fail or are unaligned "MUST be addressed" before moving to enforcement.
- Fix alignment per sender. Move each third-party sender to aligned DKIM on your domain or a dedicated subdomain.
- Move to quarantine, then reject. RFC 9989 removed the pct tag, so staged rollout now relies on subdomain policies (sp), the t test flag and per-subdomain records. Rollback is publishing the previous record, so keep DNS TTLs short during changes.
- Keep it current. Review reports on a schedule, remove retired senders from SPF and rotate DKIM keys.
How to verify it works
- Record checks: query SPF, DKIM selector and _dmarc records for every domain; confirm SPF evaluates without permerror and DKIM keys are at least 2048 bits.
- Spoof test: in an authorised test, send a message with your domain in the From address from an unauthorised server to mailboxes at major receivers and your own gateway. It should be quarantined or rejected, with dmarc=fail in Authentication-Results.
- Legitimate sender test: send from each authorised platform and confirm dmarc=pass with aligned DKIM.
- Inbound check: confirm your own gateway applies other domains' reject policies rather than only tagging.
| Metric | What it shows | Target direction |
|---|---|---|
| Share of owned domains at p=reject (or quarantine) | Enforcement coverage | Rising to 100% |
| Share of legitimate volume passing DMARC with aligned DKIM | Readiness for enforcement | Near 100% |
| Unknown sending sources in aggregate reports | Shadow senders or spoofing | Each source identified or blocked |
| SPF lookup count per domain | Risk of permerror | At or below 10 |
| Age of DKIM keys per selector | Key maintenance | Within your rotation policy |
For diagnosing failures, see the DMARC, SPF and DKIM Failure Troubleshooting Guide.
Limits, bypasses and failure patterns
- Stuck at p=none: reports arrive but receivers are asked to take no action, so spoofed mail is still delivered.
- Forwarding and mailing lists: RFC 7208 notes that SPF fails when a mediator keeps the original MAIL FROM, and lists that alter content break DKIM. See the ARC (Authenticated Received Chain) Guide.
- Look-alike domains: authentication protects only domains you own; a homoglyph or similar domain can pass its own checks. Pair with D3-HD Homoglyph Detection.
- Compromised legitimate senders: mail from a hijacked mailbox, a stolen SMTP credential or a third-party platform account passes every check.
- Over-broad SPF: large includes or ranges authorise shared infrastructure that other customers can also send from.
- Stale DKIM keys: short or unrotated keys, and leftover selectors from retired platforms, remain valid signing paths.
Framework mapping
| Framework | Reference | Relationship to D3-TAAN |
|---|---|---|
| MITRE ATT&CK | M1054 Software Configuration | ATT&CK's mitigation text names SPF, DKIM and DMARC for phishing and email spoofing |
| NIST SP 800-53 Rev 5 | SI-8 Spam Protection | Protection mechanisms at entry points for unsolicited messages |
| NIST SP 800-53 Rev 5 | SC-8(1) | Cryptographic protection of transmitted information (DKIM signatures) |
| NIST CSF 2.0 | PR.DS-02 | Confidentiality, integrity and availability of data in transit are protected |
The NIST rows are NHI Mgmt Group's mapping, not part of D3FEND.
Related countermeasures
- Siblings under Message Hardening: D3-MAN Message Authentication authenticates message content itself; Message Encryption protects confidentiality.
- Transport: authenticating the receiving server and encrypting the hop is a separate control; see the SMTP Security, STARTTLS and MTA-STS Guide.
- Analysis: D3-UA URL Analysis and D3-DNRA Domain Name Reputation Analysis cover what authentication does not.
Practitioner checklist
- Inventory every owned domain and every system that sends as it.
- Publish null SPF and p=reject DMARC on domains that never send mail.
- Sign all outbound mail with aligned DKIM, rsa-sha256 and 2048-bit keys; drop the l= tag.
- Keep SPF within 10 DNS lookups and remove retired senders.
- Collect and act on DMARC aggregate reports with named owners per source.
- Move every sending domain from p=none to quarantine and then reject.
- Treat SMTP relay credentials and email API keys as managed non-human credentials.
- Keep content filtering and look-alike domain monitoring in place alongside authentication.
Standards and references
- MITRE D3FEND: Transfer Agent Authentication (D3-TAAN)
- IETF: RFC 9989 Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
- IETF: RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
- IETF: RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
- IETF: RFC 8301 Cryptographic Algorithm and Key Usage Update to DKIM
- IETF: RFC 7489 DMARC (obsoleted)
- MITRE ATT&CK: M1054 Software Configuration
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
Related NHI Mgmt Group resources: MITRE D3FEND Guide · DMARC, SPF and DKIM Guide · Email Authentication Checklist · Email Authentication for Developers Guide · Business Email Compromise Response Playbook