Message submission: what RFC 6409 actually defines
A standards-first look at message submission: why RFC 6409 treats a client handing off its own mail differently from a server relaying mail for another.
Treating "a client submitting its own outgoing mail" and "a server relaying mail for anyone" identically makes it hard to require authentication or apply submission-specific policy, rate limits, missing-header fixups, without breaking the open-relay behavior server-to-server delivery historically assumed. RFC 6409, from 2011, obsoletes RFC 4409 from 2006 and the original RFC 2476 from 1998.
What RFC 6409 defines
RFC 6409 defines message submission as its own protocol role, conventionally on port 587, with its own requirements on top of SMTP. Authentication is expected. And a submission server is permitted to fix up minor issues, like a missing Date or Message-ID, before the message becomes wire-valid, something a pure relay server should never do to someone else's mail in transit.
"This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server. Message relay is unaffected, and continues to use SMTP over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587. This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements."
How it works
A mail client connects to its provider's submission server and authenticates, commonly SMTP AUTH, layered under STARTTLS. It then proceeds with the same MAIL FROM, RCPT TO, and DATA sequence RFC 5321 defines.
The submission server, once it accepts the message, takes responsibility for it: either relaying it onward via ordinary SMTP, or delivering it locally.
Anatomy
| Relay | Submission | |
|---|---|---|
| Port | 25 | 587 |
| Authentication | Not required by the base protocol | Required, RFC 6409 section 4.3 |
| Direction | Server-to-server | Client-to-server |
| Historical default | Open by default | The trust boundary where a provider knows exactly who's sending |
Worked example
A submission sequence, authenticating before the message is accepted:
EHLO mail.acme.com250 mx.example.com Hello mail.acme.comAUTH LOGIN334 VXNlcm5hbWU6aGVsbG9AYWNtZS5jb20=334 UGFzc3dvcmQ6c2VjcmV0235 Authentication successfulMAIL FROM:<hello@acme.com>250 OKRCPT TO:<user@example.com>250 OKDATA354 Start mail input, end with <CRLF>.<CRLF>...
AUTH LOGIN prompts for a base64-encoded username, then a base64-encoded password, before the server accepts 235 Authentication successful. In practice, this whole exchange typically happens inside a TLS session already, implicit TLS on port 465 or STARTTLS on port 587, not in the clear.
Where this doesn't reach
RFC 6409 doesn't define the authentication mechanism itself. SMTP AUTH is its own standard, RFC 4954. It doesn't define the encryption either, transport security covers STARTTLS separately.
Requiring authentication at submission controls who can send through a given provider. It says nothing about what happens to the message once it leaves that provider's own submission server.
Check it yourself
Connect to port 587 and port 25 on the same mail server and compare behavior:
openssl s_client -connect yourdomain.com:587 -starttls smtp
Port 587 typically demands AUTH before accepting MAIL FROM. Port 25 usually doesn't, or shouldn't, on a well-configured server.
Where it fits
This page covers the client-side entry point that hands a message off to the transport protocol. For what happens once the submission server relays the message onward, see SMTP. For the STARTTLS layer this exchange typically runs inside, see transport security. For the full standards landscape, see the reference hub.
FAQ
Why port 587 instead of port 25?
Port 25 is server-to-server relay, historically open and unauthenticated by default. Port 587 is the submission entry point, where RFC 6409 requires authentication, letting a provider control exactly who submits mail through it.
Does RFC 6409 define SMTP AUTH?
No. SMTP AUTH is its own extension, RFC 4954. RFC 6409 requires that submission be authenticated, it doesn't define the mechanism used to do it.
Can a submission server modify my message?
Within limits, yes. It's permitted to fix up minor issues, like adding a missing Date or Message-ID, before the message becomes wire-valid. A pure relay server shouldn't do this to mail already in transit.
Is submission always encrypted?
Not by RFC 6409 alone. Encryption is a separate concern, layered in via STARTTLS or implicit TLS, not something this RFC requires on its own.
RFC reference
RFCs covered: RFC 6409. Superseded / updated by: obsoletes RFC 4409 and RFC 2476.