What this RFC defined
RFC 4409 defined the mail submission protocol, establishing port 587 as the dedicated port for email client submission and requiring authentication for all submitting clients. It was the first RFC to formally separate the submission role (client to server) from the relay role (server to server on port 25), giving email infrastructure a cleaner security boundary.
Where you would have seen it in practice
The configuration of email clients to use port 587 with username and password authentication follows the framework established in RFC 4409, later refined in RFC 6409. Port 587 with authentication is the standard submission port used by virtually every ESP and mail hosting provider today. RFC 4409 made this separation of submission and relay a formal standard rather than just best practice.
How it connects to other RFCs
RFC 4409 obsoletes RFC 2476 and was itself obsoleted by RFC 6409 in 2011. RFC 6409 tightened requirements around authentication and clarified the relationship with TLS, but the fundamental port-587-with-authentication model established in RFC 4409 is unchanged in its successor.
Current status
RFC 4409 was obsoleted by RFC 6409 in November 2011. New deployments should reference RFC 6409. The port 587 submission model it established remains the universal standard; the successor RFC 6409 refined the requirements without changing the fundamental client-to-server architecture.
The submission service specification
RFC 4409 was the second revision of the message submission standard, published in April 2006 and obsoleting RFC 2476. It defined what a mail submission service does: accept mail from authenticated users, validate syntactic conformance, apply signing (DKIM), add trace headers, and forward to the appropriate destination MTA. The document formalized what had been common practice at ISPs and enterprise mail systems for years, providing a single reference for submission behavior.
Superseded by RFC 6409
RFC 4409 was obsoleted by RFC 6409 in November 2011. The changes were incremental: better guidance on interaction with modern authentication (DKIM signing at submission time), clarifications on how to handle malformed input, and updated recommendations for logging and error responses. If your MTA references RFC 4409, it is not broken; RFC 6409 is a superset that maintains backward compatibility. New implementation work should target RFC 6409.
Practical significance
Every modern MTA runs a submission service on port 587 (or 465 with implicit TLS) that follows RFC 6409 (formerly RFC 4409) semantics. This is different from a relay service on port 25: submission requires authentication, applies stricter policy checks, and often modifies the message (adding Message-ID if missing, applying DKIM signatures, rewriting the return path). If your mail client cannot send but can receive, the submission service configuration is where to look first.
RFC 4409 (April 2006) defined Message Submission: the architectural distinction between server-to-server relay (port 25, per RFC 5321) and client-to-server submission (port 587, authenticated, policy-enforcing). Obsoleted by RFC 6409 in November 2011 (which folded improvements from operational experience). The core idea: mail servers accepting messages FROM users should behave differently from those receiving mail from other servers, applying authentication, header rewriting, message fixups, and DKIM signing.
RFC 4409 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Separate client submission from server-to-server relay |
| Port | 587 (submission) |
| Authentication | Required per policy (typically SMTP AUTH) |
| TLS | Recommended via STARTTLS; required in modern deployments per RFC 8314 |
| Message policy | Submission service adds missing headers, applies signing, enforces policy |
| Successor | RFC 6409 (November 2011) |
| Status | Obsolete; reference RFC 6409 for current specification |
Submission vs Relay: the architectural split
| Aspect | Submission (port 587) | Relay (port 25) |
|---|---|---|
| Source | Authenticated user (MUA) | Another MTA |
| Authentication | Required (SMTP AUTH or client cert) | Typically none (IP-based trust) |
| Header rewriting | Server may add Message-ID, Date, From if missing | Server must not modify user content |
| DKIM signing | Submission server signs on behalf of user | Usually already signed upstream |
| Policy enforcement | Rate limits, content policies, virus scan | Reputation-based filtering |
| Recipient scope | Any (subject to policy) | Local mailboxes only (no open relay) |
| Failure handling | Immediate feedback to user | Bounce back to sender via DSN |
Message fixups performed by submission servers
RFC 4409 explicitly permits the submission server to modify or add certain headers that user-generated messages often lack or have malformed. This is critical: many mail clients produce messages that would be rejected by strict server-to-server relay checking.
| Header | Fixup performed | Rationale |
|---|---|---|
| Message-ID | Add if missing | RFC 5322 recommends; some clients omit |
| Date | Add if missing or fix if clearly wrong | RFC 5322 requires; clients occasionally omit or send wrong timezone |
| From | Ensure present with valid address | Required per RFC 5322 |
| Return-Path | Set from MAIL FROM | Never should be present at submission (added at delivery) |
| Bcc | Remove or hide | Should not be visible to other recipients |
| DKIM-Signature | Add on behalf of user’s domain | Sign at submission so downstream sees authenticated mail |
| Sender | Add if From is different from authenticated user | Per RFC 5322 when the actual submitter differs from the visible From |
Common submission service configuration mistakes
smtpd_client_restrictions = permit_sasl_authenticated, reject. Exchange: enforce via Receive Connectors.master.cf per-service overrides.smtpd_tls_auth_only = yes on Postfix, or serve on port 465 with implicit TLS.d= won’t match the rewritten From) and defeats accountability. Modern practice: preserve the user’s From, use Sender header if the submitter is truly different, sign DKIM with the authenticated user’s domain.Related standards and further reading
- RFC 6409: Current Message Submission standard (obsoletes RFC 4409)
- RFC 4954: SMTP AUTH (authentication mechanism)
- RFC 3207: STARTTLS (transport security)
- RFC 8314: Cleartext obsolete for submission
- RFC 5321: SMTP base protocol
- RFC 5322: Message Format (headers that submission may fix)
- RFC 6376: DKIM (typically applied at submission)
- Email Protocols and Ports Guide: 587 vs 465 vs 25
- Postfix Guide: submission service configuration
- SSL/TLS Email Setup Guide: securing submission
Frequently asked questions
What is the difference between port 587 and port 25?
Port 25 is for server-to-server relay per RFC 5321: mail transfer agents talking to each other. It typically requires no authentication and applies delivery-focused policies. Port 587 is for client-to-server submission per RFC 4409/6409: end-user mail clients submitting messages. It requires authentication (SMTP AUTH), applies message fixups, and often signs DKIM on the user’s behalf. The split lets ISPs block outbound port 25 (to prevent spam from compromised endpoints) while allowing authenticated submission on port 587.
Should I use port 587 or 465?
Both are valid for authenticated submission. Port 587 starts cleartext and upgrades via STARTTLS. Port 465 uses implicit TLS from the first byte. RFC 8314 recommends implicit TLS (465) over STARTTLS (587) because it eliminates the pre-upgrade cleartext window. Practical reality: both are widely supported; use whichever your provider recommends. Gmail, Microsoft 365, and most modern ESPs support both.
Why does RFC 4409 exist if RFC 6409 replaced it?
RFC 4409 was published in April 2006 and defined the initial submission concept. Operational experience revealed improvements needed (clarifications, error handling, TLS integration). RFC 6409 in November 2011 folded those improvements. The core architecture (port 587, AUTH required, message fixups) is identical. Modern references should target RFC 6409, but existing code and documentation targeting RFC 4409 remains valid because the semantics are compatible.
Can I use port 587 without authentication?
No, at least not for the mainstream deployment pattern. The whole architectural point of port 587 is authenticated submission. Some servers offer port 587 without AUTH for local network use (behind firewall, IP-restricted), but this is unusual. If you need unauthenticated submission from a specific source, it is better handled through IP allow-listing on a dedicated MSA (Mail Submission Agent) rather than exposing port 587 without AUTH broadly.
Does the submission server sign DKIM for me?
Typically yes, when the submission server is your own domain’s MTA or your ESP. The submission service signs DKIM using a key it holds on behalf of your sending domain. This is why ESP DKIM often has d=yourdomain.com (via CNAME delegation) rather than d=esp.com. Configuration varies: verify with your ESP or run a test send and inspect the DKIM-Signature header on the resulting message.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
