Which ports should a mail server expose?

Open ports according to the server's role. Internet mail exchange normally uses TCP 25, authenticated client submission uses 587 with STARTTLS or 465 with implicit TLS, and mailbox access commonly uses IMAP over TLS on 993. A listening port alone does not prove that authentication or encryption is configured correctly.

Port reference

The port number does not itself force an upgrade on 587, 143, or 110. Configure the service and clients so credentials and message access are not allowed before the required TLS protection.

Decide inbound and outbound access separately

A full mail service receiving directly from other MTAs needs inbound port 25. If users submit through it, expose the intended submission service, such as 587 or 465. If they read mail there, expose IMAP or POP3 as appropriate. Direct outbound delivery to recipient MX servers needs outbound port 25.

An application that only submits to a third-party relay may need no inbound mail ports at all. It needs outbound access to that relay's documented submission endpoint. A server that accepts client submission but delegates mailbox hosting elsewhere likewise does not need local IMAP or POP3 listeners.

For internal testing, restrict listeners and firewall rules to the required internal sources. Choose the network scope explicitly rather than assuming that a nonstandard deployment is private.

Example UFW rules

For an already configured server that intentionally offers public SMTP receipt, STARTTLS submission, and encrypted IMAP:

sudo ufw allow 25/tcp
sudo ufw allow 587/tcp
sudo ufw allow 993/tcp
sudo ufw status verbose

Do not open unused POP3 ports. These commands do not configure the mail services or override upstream security groups and provider restrictions. Before enabling a previously inactive firewall, preserve the required management access and a recovery path; there is no need to run ufw enable merely to add rules to an active firewall.

Verify security and delivery

Public submission should require authentication or another deliberate, tightly scoped authorization method. Allowing every unauthenticated client to relay externally creates an open relay; merely opening 587 does not by itself establish that behavior. Keep public inbound delivery on 25 distinct from authenticated client submission.

Port 465 is a standardized implicit-TLS submission port, not an obsolete port to avoid. RFC 8314 recommends TLS-protected submission and access, with support for implicit TLS. Offer 465 and/or correctly enforced STARTTLS on 587 according to client requirements.

Hosting providers may restrict outbound 25; confirm the current policy for the actual environment. An authenticated relay on 587 can be an alternative, but arbitrary destination MX servers do not accept inter-server mail on that submission port.

Test connectivity from the real sending and receiving networks, then test TLS negotiation, authentication, and a controlled message end to end. A Guance TCP synthetic test checks connectivity to the selected port; it does not prove successful SMTP authentication or inbox delivery.

Troubleshoot sending versus receiving

If sending works but receiving fails, inspect MX records, their target addresses, inbound 25, and the receiving server's logs. Test the actual MX host rather than assuming the domain apex is the mail server.

IMAP is useful for synchronized mail and state across devices. POP3 can suit simpler download workflows and can also leave copies on the server, depending on the client. Choose the access service you intend to operate and secure it.

SPF, DKIM, DMARC, PTR records, sender reputation, and recipient policy remain relevant after ports are reachable. None of those, alone or together, guarantees delivery.

References

• RFC 8314: TLS for submission and mail access
• Ubuntu UFW manual

Related reading

• What @ means in a DNS zone file
• Show your global Git configuration