The DATA command is the SMTP command used to start sending the contents of an email message after the envelope has been set up. The server responds with a prompt, then the client sends headers and body until a line containing only a period ends the message, so controls like sender validation and content filtering apply at delivery time.
How the DATA command works
In SMTP, DATA is the transition from message setup to message transmission. After the server accepts the envelope, it invites the client to send the message contents, then treats the ensuing headers and body as one email payload until the terminating period line closes the transaction.
This matters because the command is not just a transport detail, it is the point where the server begins evaluating the actual content that will be delivered. Message composition, header handling, and content inspection all become relevant at this stage, which is why delivery security controls often focus on what is sent during DATA rather than only on who opened the connection.
Why DATA is security-sensitive
DATA is security-sensitive because it moves the session from negotiation into content submission, which can expose mail systems to spam, phishing, malware, and policy bypass if later-stage inspection is weak. SMTP controls that look acceptable at connect time can still fail when the body or headers are finally presented.
It also creates a natural boundary for enforcement. A server can accept the envelope and still reject or quarantine the message once the content is visible, which is important for sender validation, content filtering, and reputation-based controls that depend on the full message.
Message boundaries and protocol handling
The protocol semantics of DATA are simple, but implementation mistakes are common. Servers must parse the dot-terminated end of message correctly, preserve message integrity while normalising line endings, and avoid accepting malformed input that could confuse downstream scanners or MTAs.
Because the client streams the body after the server prompt, the receiving side must distinguish protocol framing from message text. The classic SMTP dot-stuffing rules exist to prevent accidental termination, and mishandling them can truncate content, alter delivery outcomes, or create inconsistent security decisions between relay systems.
Delivery-time controls and operational implications
Controls that depend on the final message, not just the envelope, are most effective at or after DATA. That includes content-based filtering, attachment analysis, DLP checks, sender policy enforcement, and reputation decisions that rely on the message body, headers, and embedded links or file types.
For practitioners, the practical question is whether the mail path enforces those checks consistently at the point where the message becomes complete. If DATA handling is permissive but downstream inspection is shallow or inconsistent, attackers can get malicious content accepted first and detected too late.
Risk and Threat Considerations
DATA can be abused because it is the stage where the server finally sees the full payload, which makes it the natural place for spam, phishing, malware delivery, and policy evasion attempts. If a mail system trusts the envelope too much, it may accept a message that only becomes obviously malicious once the body is transmitted.
Failure mechanism: Weak or delayed content inspection, inconsistent dot-termination handling, or incomplete policy enforcement at delivery time lets hostile messages pass the SMTP transaction before controls can react.
Impact: The organisation may deliver malicious email, miss suspicious content, or create parsing gaps between relays and security tools, increasing the chance of successful phishing, malware exposure, or message corruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | SMTP DATA handling depends on traceable mail transaction events and message submission visibility. |
| SI-4 — System Monitoring | Message content inspection and abuse detection at DATA align with monitoring for malicious or anomalous activity. | |
| Recommendation — Log SMTP transaction stages, including DATA entry and completion, to support investigation and abuse detection. Monitor mail flows and message content events to detect malicious payloads entering through SMTP. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | SMTP delivery requires auditable records for message submission, rejection, and filtering decisions. |
| Recommendation — Centralise and review SMTP logs so message submission and filtering outcomes are observable. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | The DATA command's termination, rejection, and handling errors mirror the need for reliable security logging and safe failure handling. |
| Recommendation — Record SMTP message handling failures and termination errors to preserve trustworthy security evidence. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Misconfigured mail handling around DATA can weaken enforcement of message acceptance and inspection controls. |
| Recommendation — Harden mail submission paths so SMTP content handling rules are consistently enforced. | ||
Practitioner Guidance
What to watch for: Treat the DATA phase as the point where content policy must actually bite. If filtering, authentication checks, and attachment handling only happen after acceptance, verify that rejection, quarantine, and logging are still enforced with the same message state that reached the recipient pipeline.
Practitioner note: For mail security, the most useful operational habit is to validate the message as it exists after DATA closes, not as it appeared when the session started. That is the version adversaries try to shape.
Related resources from NHI Mgmt Group
- What is the difference between disconnected privacy, security, and AI governance tools and a unified data command approach?
- What breaks when Android apps pass untrusted deep-link data into command-line arguments?
- What happens when an MCP server is connected to an AI client without tight command and data controls?
- Why does ransomware that exfiltrates data over a command and control channel create a broader security impact?