Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1684.002: Email Spoofing

Adversaries may fake, or spoof, a sender’s identity by modifying the value of relevant email headers in order to establish contact with victims under false pretenses.[1] In addition to actual email content, email headers (such as the FROM header, which contains the email address of the sender) may also be modified. Email clients display these headers when emails appear in a victim's inbox, which may cause modified emails to appear as if they were from the spoofed entity.

Enterprise environments can use Domain-based Message Authentication, Reporting, and Conformance (DMARC) as an email authentication protocol that references results of the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) configurations. SPF and DKIM are configured separately in DNS: SPF verifies that the sending server is authorized for the domain, while DKIM uses a digital signature to verify email integrity and domain authentication. Together, they validate email authenticity and specify how receiving servers should handle authentication failures. Without enforced identity authentication, adversaries may compromise the integrity of an authentication check with altered headers that would not have otherwise passed.[2][3][4]

An example of a weak or absent DMARC policy is `v=DMARC1; p=none; fo=1;`. The `p=none`. The `p=none` indicates no action should be taken, and therefore no filtering action will take place, even if an email fails authentication checks (i.e., SPF and/or DKIM fail). When a DMARC policy indicates no action, the email will still be delivered to the victim’s inbox.[5]

Adversaries have abused weak or absent DMARC policies to circumvent authentication checks and conceal social engineering attempts. Adversaries can alter email headers to include legitimate domain names with fake usernames or impersonate legitimate users via Impersonation for Phishing. Additionally, adversaries may abuse Microsoft 365’s Direct Send functionality to spoof internal users by using internal devices like printers to send emails without authentication.[6]

EnterpriseT1684.002Sub-techniqueObject v1.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Email spoofing is a trust problem, not just an email problem. If an organization’s email authentication is weak or unenforced, a message can appear to come from a legitimate internal user, executive, vendor, or trusted domain even when the sender identity has been manipulated. That makes this behavior material to phishing resilience, executive impersonation risk, help desk and approval workflows, and incident response triage.

Executive priority

Leaders should treat this as a control-validation issue for business email trust. The priority is to know whether SPF, DKIM, and DMARC are correctly configured and enforced, especially whether DMARC is still set to monitor-only behavior such as p=none. This matters for audit evidence, fraud prevention, social engineering resilience, and reducing the likelihood that users or business processes rely on misleading sender identity alone.

Technical view

This ATT&CK sub-technique sits under Social Engineering and the stealth tactic. SOC, messaging, IAM, and IR teams should validate how inbound and internal-looking email is authenticated, logged, and presented to users across Office Suite, Windows, macOS, and Linux environments. Because ATT&CK does not provide a detection section for this object, detection engineering should be based on email authentication outcomes, header analysis, DMARC/SPF/DKIM results, and relationship context from DET0431, while mitigation should align to M1054 Software Configuration.

Likely telemetry

  • Email gateway or mail security logs showing SPF, DKIM, and DMARC pass/fail/disposition results
  • Full email headers, including From, Return-Path, Reply-To, Received, Authentication-Results, and DKIM signature fields
  • DMARC aggregate and failure reports where available
  • DNS records for SPF, DKIM, and DMARC configuration state
  • Mail platform audit logs for unauthenticated or internal-looking sending paths, including Microsoft 365 Direct Send scenarios referenced by ATT&CK

Detection direction

  • Validate whether DET0431 or equivalent local detection logic exists for spoofed sender identity and whether it uses authentication results rather than display name alone.
  • Prioritize detections where the visible From domain or user identity conflicts with SPF, DKIM, DMARC, Return-Path, Reply-To, or sending infrastructure evidence.
  • Tune for weak-control scenarios: DMARC p=none may generate useful evidence but does not by itself prevent delivery.
  • Review internal-looking messages sent without normal authentication paths, including device or application mail flows such as printers or Direct Send-style behavior where applicable.
  • Account for false positives from legitimate third-party senders, marketing platforms, ticketing systems, and business applications that send on behalf of corporate domains.

Mitigation priorities

  • Inventory domains used for corporate email and confirm SPF, DKIM, and DMARC are present and intentionally configured.
  • Move from monitoring-only DMARC posture toward enforcement where business mail flows have been validated, using staged configuration changes to reduce disruption.
  • Review software and mail platform configuration under M1054 Software Configuration, including application, device, and service accounts that send email.
  • Validate third-party senders so enforcement does not break legitimate business email while still preventing unauthorized use of trusted domains.
  • Educate users and approval-process owners that displayed sender identity is not sufficient proof of authenticity, especially for financial, credential, help desk, or executive requests.
Analyst notes and limits

ATT&CK identifies Email Spoofing as a sub-technique of Social Engineering and notes that adversaries may alter email headers to make messages appear to originate from a trusted entity. The object explicitly highlights DMARC, SPF, DKIM, weak or absent DMARC policies, and Microsoft 365 Direct Send abuse as relevant defensive considerations. The most useful local assessment is whether email authentication evidence is collected, enforced, monitored, and usable during investigations.

The official ATT&CK object does not provide a detection section, and the supplied DET0431 relationship includes only the detection strategy name without detailed analytics. This take therefore avoids claiming guaranteed detection coverage. Local mail architecture, DNS records, third-party senders, and platform logging must be reviewed before determining actual exposure or control maturity.

Official MITRE ATT&CK definition

Email Spoofing

Adversaries may fake, or spoof, a sender’s identity by modifying the value of relevant email headers in order to establish contact with victims under false pretenses.[1] In addition to actual email content, email headers (such as the FROM header, which contains the email address of the sender) may also be modified. Email clients display these headers when emails appear in a victim's inbox, which may cause modified emails to appear as if they were from the spoofed entity.

Enterprise environments can use Domain-based Message Authentication, Reporting, and Conformance (DMARC) as an email authentication protocol that references results of the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) configurations. SPF and DKIM are configured separately in DNS: SPF verifies that the sending server is authorized for the domain, while DKIM uses a digital signature to verify email integrity and domain authentication. Together, they validate email authenticity and specify how receiving servers should handle authentication failures. Without enforced identity authentication, adversaries may compromise the integrity of an authentication check with altered headers that would not have otherwise passed.[2][3][4]

An example of a weak or absent DMARC policy is `v=DMARC1; p=none; fo=1;`. The `p=none`. The `p=none` indicates no action should be taken, and therefore no filtering action will take place, even if an email fails authentication checks (i.e., SPF and/or DKIM fail). When a DMARC policy indicates no action, the email will still be delivered to the victim’s inbox.[5]

Adversaries have abused weak or absent DMARC policies to circumvent authentication checks and conceal social engineering attempts. Adversaries can alter email headers to include legitimate domain names with fake usernames or impersonate legitimate users via Impersonation for Phishing. Additionally, adversaries may abuse Microsoft 365’s Direct Send functionality to spoof internal users by using internal devices like printers to send emails without authentication.[6]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1672 Email Spoofing Email Spoofing revoked by this object.
Enterprise T1684 Social Engineering This object subtechnique of Social Engineering.
Relationship explorer

All related ATT&CK context

revoked by · Technique T1672: Email Spoofing Enterprise detects · Detection Strategy DET0431: Detection Strategy for Email Spoofing Enterprise subtechnique of · Technique T1684: Social Engineering Enterprise mitigates · Mitigation M1054: Software Configuration Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1054: Software Configuration

Software configuration refers to making security-focused adjustments to the settings of applications, middleware, databases, or other software to mitigate potential threats. These changes help reduce the attack surface, enforce best practices, and protect sensitive data. This mitigation can be implemented through the following measures:

Conduct a Security Review of Application Settings:

- Review the software documentation to identify recommended security configurations. - Compare default settings against organizational policies and compliance requirements.

Implement Access Controls and Permissions:

- Restrict access to sensitive features or data within the software. - Enforce least privilege principles for all roles and accounts interacting with the software.

Enable Logging and Monitoring:

- Configure detailed logging for key application events such as authentication failures, configuration changes, or unusual activity. - Integrate logs with a centralized monitoring solution, such as a SIEM.

Update and Patch Software Regularly:

- Ensure the software is kept up-to-date with the latest security patches to address known vulnerabilities. - Use automated patch management tools to streamline the update process.

Disable Unnecessary Features or Services:

- Turn off unused functionality or components that could introduce vulnerabilities, such as debugging interfaces or deprecated APIs.

Test Configuration Changes:

- Perform configuration changes in a staging environment before applying them in production. - Conduct regular audits to ensure that settings remain aligned with security policies.

*Tools for Implementation*

Configuration Management Tools:

- Ansible: Automates configuration changes across multiple applications and environments. - Chef: Ensures consistent application settings through code-based configuration management. - Puppet: Automates software configurations and audits changes for compliance.

Security Benchmarking Tools:

- CIS-CAT: Provides benchmarks and audits for secure software configurations. - Aqua Security Trivy: Scans containerized applications for configuration issues.

Vulnerability Management Solutions:

- Nessus: Identifies misconfigurations and suggests corrective actions.

Logging and Monitoring Tools:

- Splunk: Aggregates and analyzes application logs to detect suspicious activity.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
db398425c4214901...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle db398425c421…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Proofpoint TA427 April 2024

    Lesnewich, G. et al. (2024, April 16). From Social Engineering to DMARC Abuse: TA427’s Art of Information Gathering. Retrieved May 3, 2024.

    Open source URL
  2. [2]
    Cloudflare DMARC, DKIM, and SPF

    Cloudflare. (n.d.). What are DMARC, DKIM, and SPF?. Retrieved April 8, 2025.

    Open source URL
  3. [3]
    DMARC-overview

    DMARC. (n.d.). Retrieved March 24, 2025.

    Open source URL
  4. [4]
    Proofpoint-DMARC

    Proofpoint. (n.d.). Retrieved March 24, 2025.

    Open source URL
  5. [5]
    ic3-dprk

    FBI, State Department, NSA. (2024, May 2). North Korean Actors Exploit Weak DMARC Security Policies to Mask Spearphishing Efforts. Retrieved April 2, 2025.

    Open source URL
  6. [6]
    Barnea DirectSend

    Tom Barnea. (2025, September 9). Ongoing Campaign Abuses Microsoft 365’s Direct Send to Deliver Phishing Emails. Retrieved September 24, 2025.

    Open source URL
  7. [7]
    mitre-attack T1684.002
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use