What does “SMTP submission” mean?
In business email, “SMTP” often gets used to describe two different flows: server-to-server mail delivery and user-to-server message submission. SMTP submission is the second one: a user or application (Outlook, a mobile phone, a CRM, a website form, a printer, or an integration script) authenticates to an SMTP service to send email. This is a critical distinction because submission traffic comes with stricter expectations around authentication, encryption, and abuse prevention.
Many “can’t send email” tickets, and a surprising number of deliverability incidents, start with a simple mismatch: the wrong port, the wrong encryption mode, or an SMTP service that is not being used as intended. Understanding ports 587 and 465 helps IT teams standardize configuration, reduce support load, and keep outbound mail aligned with security best practices.
Port 587 vs port 465: what’s the real difference?
Port 587 is the widely recommended standard for SMTP submission. Connections typically start unencrypted and then switch to encryption using the STARTTLS command. Port 465 uses a different approach: implicit TLS, where the connection is encrypted from the very first packet. Both can provide encrypted submission, but they behave differently and require different client settings.
Port 587 (Submission with STARTTLS)
- Primary purpose: Authenticated client-to-server email sending (submission).
- Encryption model: Plain connection first, then upgraded to TLS via STARTTLS.
- Why it’s popular: It’s the expected submission standard in many environments and is broadly supported.
- Common pitfall: If a client isn’t set to use STARTTLS/TLS, the server may refuse the connection or the session may be downgraded in insecure environments.
Port 465 (SMTPS with implicit TLS)
- Primary purpose: Encrypted client-to-server sending (commonly used for submission in practice).
- Encryption model: TLS is active immediately on connect (implicit SSL/TLS).
- Why it’s useful: It can be simpler in environments where STARTTLS negotiation is unreliable or blocked.
- Common pitfall: If the client is set to STARTTLS on port 465, it often fails because encryption must be implicit from the start.
Why choosing the right port matters for companies
Using the wrong port or encryption mode doesn’t just cause a one-off error message. In real organizations, it leads to productivity workarounds and governance issues. When employees can’t send mail reliably from their preferred client, they may fall back to personal accounts or unmanaged tools, creating visibility and data handling risks.
Misconfiguration can also contribute to more serious security outcomes. For example, confusion around “SMTP ports” sometimes results in overly permissive server settings. If authentication requirements are weakened or relaying rules are misapplied, you risk creating an open relay scenario that can be abused for spam—damaging IP and domain reputation and making legitimate mail harder to deliver.
When should you use 587, and when should you use 465?
As a general rule, standardize on port 587 for business email clients and application submissions. It aligns well with modern mail client expectations and administrative policies. Keep port 465 as an alternative for specific compatibility cases where implicit TLS performs more reliably.
Prefer 587 (recommended default)
- You manage modern email clients (Outlook, Apple Mail, Thunderbird) and mobile devices
- You want one consistent internal standard that is easy to document and support
- You want to enforce authenticated sending with TLS as part of your baseline controls
- You expect STARTTLS to work reliably on the networks your users connect from
Consider 465 (compatibility option)
- A device or application fails STARTTLS consistently but supports implicit SSL/TLS
- Some networks interfere with STARTTLS negotiation and cause intermittent failures
- You support older clients or embedded systems that implement implicit TLS more predictably
The most common misconfigurations (and what they cause)
1) Selecting the wrong encryption setting
This is the #1 cause of SMTP setup failures. On port 587, the correct choice is typically STARTTLS (sometimes labeled “TLS” or “STARTTLS”). On port 465, the correct choice is usually “SSL/TLS” (implicit). Swapping these settings can lead to immediate connection failures, repeated password prompts, or confusing “server not responding” errors.
2) Not enabling SMTP authentication
Submission is expected to be authenticated. If the client isn’t configured to authenticate (“My outgoing server requires authentication”), the server may reject the message. Even when sending appears to work in limited cases, unauthenticated sending is a red flag operationally and can indicate an overly permissive configuration.
3) Mismatch between the login identity and the From address
Many systems enforce rules that tie the sender address to the authenticated account (or to explicitly permitted aliases). If a user tries to send as a different address without proper authorization, messages may be rejected or flagged. This is often misdiagnosed as a “port problem” when it’s actually a policy or identity alignment issue.
4) Firewall and network egress rules that don’t match your standard
Organizations sometimes allow only one outbound SMTP submission port. If your documentation says 587 but a corporate firewall blocks it (or a hotel/ISP network blocks it), users will experience failures and seek ad-hoc solutions. IT teams should decide which ports are supported and ensure that decision is reflected in network policy and user documentation.
A practical checklist for correct SMTP submission setup
Use this checklist to validate configuration regardless of the email client or application:
- SMTP server hostname: Use the hostname provided by your email service (often a mail host under your domain or a provider-supplied server name).
- Port: Default to 587; use 465 only when needed for compatibility.
- Encryption: 587 with STARTTLS; 465 with SSL/TLS (implicit).
- Authentication: Must be enabled. The username is often the full email address.
- Password: Confirm it is current and updated on all devices after any password change.
- Sender identity: Ensure the From address is one the user is allowed to use (primary mailbox or approved alias).
- Test delivery: Send a test message to an external recipient and watch for delays or bounce errors.
Port choice is not a deliverability “hack”
It’s important to set expectations: choosing 587 or 465 won’t magically move emails from spam to inbox. Deliverability depends on authentication (SPF/DKIM/DMARC), domain and IP reputation, content patterns, sending volume consistency, and recipient engagement signals. What correct submission setup does provide is a reliable, encrypted, authenticated sending path—which is foundational for everything else.
Special notes for devices and applications
Multi-function printers and legacy devices
Printers and older embedded devices sometimes lack STARTTLS support. If they support implicit TLS, port 465 may be the simplest secure path. If a device supports no encryption at all, treat it as a design and risk-management problem, not just a settings issue. In many environments, the safer approach is to route mail through a controlled internal relay or service that can enforce authentication and TLS, rather than letting the device send directly to the internet.
Websites, apps, and integrations
Application servers and website forms should also use authenticated submission with TLS. When troubleshooting, application logs are your best friend. Errors like “TLS handshake failed,” “authentication failed,” or “must issue STARTTLS first” typically point to a port/encryption mismatch rather than a broader email outage.
Conclusion: standardize, document, and test regularly
Small configuration details in outbound email settings can create outsized operational pain. The most resilient approach is to standardize on port 587 with STARTTLS for day-to-day submission, define port 465 as a documented fallback, require authentication, and run periodic send tests—especially after network changes or client rollouts.
If you are migrating to a professional business email platform like MX1Mail or cleaning up existing email administration practices, updating internal setup guides around SMTP submission ports and encryption modes will reduce helpdesk volume, improve consistency across devices, and support a more secure outbound email posture.