← RFC Reference

RFC 6409 – Message Submission for Mail

Why This RFC Exists

In the early days of email, there was no distinction between a user sending a new message and a server relaying mail from another server. Both used port 25, and anyone could connect and send. This led to the open relay problem — spammers exploited any server that would accept and forward mail without authentication.

RFC 6409 (originally RFC 2476 in 1998, updated as RFC 4409 in 2006, and finalized as 6409 in 2011) formally separates message submission from message relay:

• Submission (port 587): An authenticated user or application submits a new message to their mail service for delivery. The server acts as an MSA (RFC 5598).
• Relay (port 25): A mail server transfers a message to another mail server en route to the destination. The server acts as an MTA.

This separation is foundational to modern email security. It enables authentication of senders, policy enforcement, and the ability to block unauthenticated relay while still accepting legitimate submissions.

How It Works

Message submission uses the same SMTP protocol defined in RFC 5321, but with important differences in behavior, policy, and port number.

The Submission Process

1. The client (MUA or application) connects to the MSA on port 587.
2. The client issues EHLO and discovers available extensions.
3. The client upgrades to TLS using STARTTLS (or connects via implicit TLS on port 465 per RFC 8314).
4. The client authenticates using AUTH (RFC 4954) — typically PLAIN or LOGIN over TLS.
5. The client submits the message with MAIL FROM, RCPT TO, and DATA.
6. The MSA validates the message, potentially adds missing headers (Date, Message-ID), and queues it for delivery via the MTA infrastructure.

Submission vs. Relay: Side by Side

SMTP Example

A typical submission session on port 587:

Key Technical Details

Authentication is Required

RFC 6409 states that an MSA SHOULD require authentication and MUST NOT accept messages for relay from unauthenticated clients unless there is a specific organizational policy allowing it. In practice, every modern submission server requires authentication. The standard mechanism is SMTP AUTH (RFC 4954) using PLAIN or LOGIN mechanisms, always over TLS.

Header Fixup by the MSA

Unlike an MTA (which must not alter message content), an MSA is expected to examine and fix the submitted message:

• Add missing Date header if the client didn't include one.
• Add missing Message-ID to ensure every message has a unique identifier.
• Verify the From address matches the authenticated identity, or add a Sender: header to indicate the real transmitting entity.
• Add trace headers — the MSA adds its own Received: header as the first entry.

Port 465: Implicit TLS

Historically, port 465 was briefly assigned for "SMTPS" (SMTP over implicit TLS), then reassigned, then re-standardized by RFC 8314 in 2018. Today, port 465 with implicit TLS is the recommended approach for submission — the TLS handshake happens immediately upon connection, before any SMTP commands. Port 587 with STARTTLS remains widely supported and valid.

Size and Rate Limits

MSAs typically enforce stricter limits than MTAs:

• Message size limits (commonly 10-25 MB)
• Rate limits per authenticated user (to prevent compromised accounts from spamming)
• Recipient count limits per message and per time period
• Sender address restrictions (you can only send from addresses you're authorized to use)

Common Mistakes

• Sending on port 25 from an application. Applications should always submit via port 587 (or 465) with authentication. Sending directly to a recipient's MX on port 25 bypasses your email service's authentication, DKIM signing, and reputation management. Most cloud platforms (AWS, GCP, Azure) block outbound port 25 by default.
• Not using TLS before AUTH. Sending credentials over an unencrypted connection exposes your SMTP username and password. Always STARTTLS before AUTH, or use implicit TLS on port 465.
• Confusing submission credentials with mailbox credentials. Some services use separate credentials for SMTP submission versus IMAP/POP access. Check your provider's documentation.
• Ignoring MSA rejection responses. If the MSA rejects your message (e.g., unauthorized sender address, message too large), your application needs to handle this gracefully, not silently drop the error.
• Hardcoding port 25 in application code. Legacy applications that connect to port 25 for submission cause deliverability problems and may stop working entirely as ISPs and cloud providers increasingly block this port for non-server use.
• Not re-issuing EHLO after STARTTLS. After the TLS handshake completes, you must send a new EHLO. The server's capability list may change (AUTH is typically only advertised after encryption is established).

Deliverability Impact

• Authentication enables DKIM signing. When you submit through an MSA, the service can apply DKIM signatures to your messages. Sending directly to remote MTAs bypasses this, meaning your messages arrive unsigned and are more likely to be flagged as spam.
• Sender identity verification. The MSA verifies that you're authorized to send from the address you claim. This prevents your account from being used to spoof other domains and maintains your sending reputation.
• Reputation management. Your email service (MSA) maintains shared IP reputation. By routing through submission, your messages benefit from the service's established reputation with major mailbox providers.
• Feedback loop processing. An MSA that processes your messages can track bounces, complaints, and delivery status, providing the data you need to maintain list hygiene and protect your sender reputation.
• TLS everywhere. Submitting over TLS (mandatory for submission) ensures your message is encrypted from your application to the email service. The service then handles encryption for the next hop, giving you end-to-end protection in transit.

Related RFCs