AN1203: Analytic 1203
Detects spoofed emails by analyzing mail server logs (e.g., Postfix, Sendmail) for mismatched header fields, failed SPF/DKIM checks, and anomalies in SMTP proxy logs. Defender observes discrepancies between sending domain, return-path domain, and message metadata.
Analyst context for executives and security teams
This analytic matters because spoofed email can undermine trust in business communications, trigger fraud workflows, and create incident-response noise even when no malware is present. The ATT&CK object focuses on Linux-based mail infrastructure logs, looking for mismatches between sender-related headers, return-path domains, message metadata, and failed SPF/DKIM checks.
Executive priority
Leaders should treat this as an email trust and resilience control-validation item. The key decision is whether the organization can produce reliable evidence from mail servers and SMTP proxy logs to investigate suspected spoofing, support compliance or audit questions around email authentication, and reduce business risk from impersonation attempts. Priority should be higher where critical approvals, payments, customer support, or executive communications depend heavily on email authenticity.
Technical view
For SOC, detection engineering, and IR teams, the supplied object supports validation against Linux mail server telemetry such as Postfix or Sendmail logs and SMTP proxy logs. Analysts should confirm that logs expose sending domain, return-path domain, relevant header fields, message metadata, and SPF/DKIM outcomes. Because no ATT&CK tactic, relationship context, or official detection logic is provided, teams should build or assess local detection logic around discrepancies rather than assuming a complete analytic is defined by ATT&CK.
Likely telemetry
- Linux mail server logs, including Postfix or Sendmail where deployed
- SMTP proxy logs
- Email header fields related to sending domain and return-path domain
- Message metadata needed to compare sender identity indicators
- SPF check results
Detection direction
- Validate that mail logging captures the fields needed to compare sending domain, return-path domain, and message metadata.
- Tune alerting around failed SPF/DKIM checks combined with header or domain discrepancies rather than treating every failure as equally suspicious.
- Account for legitimate forwarding, mailing lists, relays, and third-party senders as likely false-positive sources.
- Confirm whether SMTP proxy logs and mail server logs can be correlated during investigations.
- Document gaps where cloud email systems, gateways, or non-Linux mail paths are outside the supplied platform scope.
Mitigation priorities
- Inventory authoritative email paths and confirm which Linux mail servers or SMTP proxies generate relevant logs.
- Ensure SPF and DKIM results are available to defenders in searchable telemetry.
- Establish investigation playbooks for spoofed-email reports that include header, return-path, and authentication-result review.
- Use findings from detection testing to prioritize email authentication governance and logging improvements.
- Maintain audit-ready evidence showing how suspected spoofing can be investigated from retained mail infrastructure logs.
Analyst notes and limits
This object is a detection analytic, AN1203, in the enterprise ATT&CK domain. It has Linux as the only supplied platform and provides a high-level description but no official detection query or relationship context. The practical value is in validating whether the organization’s email telemetry supports the comparisons described by MITRE.
No tactics, relationships, aliases, labels, or official detection logic were supplied. This take cannot infer coverage for cloud email platforms, specific gateways, active exploitation, adversary attribution, or guaranteed detection outcomes. Local mail routing, forwarding behavior, and log retention must be assessed before operational use.
Analytic 1203
Detects spoofed emails by analyzing mail server logs (e.g., Postfix, Sendmail) for mismatched header fields, failed SPF/DKIM checks, and anomalies in SMTP proxy logs. Defender observes discrepancies between sending domain, return-path domain, and message metadata.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | b369888179ad… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1203Open source URL
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.