← All guides

587, unless told otherwise

Which one to choose, why yours is blocked, and what an open port does not settle.

6 min read

The three ports at a glance

PortWhat it doesEncryptionFor whom
587Hand a message to your sending serverSTARTTLS (starts clear, switches to encrypted)You, by default
465The same thingTLS from the first byteYou, if your provider says so
25Link two mail servers togetherOpportunistic, no authenticationServers — blocked almost everywhere else

The submission port is defined by RFC 6409 (2006); port 465's return comes from RFC 8314 (2018), which recommends encryption from the first byte. These are not vendor conventions: that is why the same port behaves the same everywhere.

Three numbers show up the moment you configure email sending, and half of all failed setups come from mixing them up. They do not do the same job: one links two servers together, the other two are for you, dropping off a message.

Port 587, the one you almost always want

This is the submission port: the one a program uses to hand a message to its sending server, with a username and a password. The connection starts in the clear then switches to encrypted with the STARTTLS command.

It is the default choice, and has been for a long time: the standard describing it is twenty years old. If your provider says nothing, take 587.

Port 465, back in favour

It does the same thing, but encrypted from the first second: no clear-text phase, no STARTTLS command. Long declared obsolete, it was rehabilitated in 2018 by a standard that explicitly recommends it for submission.

In short: 465 and 587 are both fine. Take the one your provider names, and do not change your mind halfway through a setup that works.

Port 25, which is not for you

Port 25 links servers to each other. It is not a drop-off port: you do not authenticate on it, which is exactly why it was the port of unwanted email for twenty years.

Most internet providers block it outbound, on home connections and on many shared servers. If your software is set to 25 and nothing goes out, that is almost always it — and the fix is not to insist, it is to move to 587.

An authenticated sending domain, and its DNS records.VerifiedThis domain is authenticatedTYPENAMEVALUECNAMEpm1._domainkeypm1.dkim.plumail.frCNAMEpm2._domainkeypm2.dkim.plumail.frTXT@v=spf1 include:…
An authenticated sending domain, and its DNS records.

When nothing goes out

Why it still does not go through

  • The machine or network firewall. A closed outbound port shows up as a timeout, not a refusal: the message sits in the queue with no explanation.
  • Shared hosting. Many forbid any outbound SMTP connection and impose their own server. It is in their documentation, rarely in their interface.
  • The password. On an account with two-factor authentication, the usual password will not do: you need an app password, generated separately.

What a good port does not settle

An open port carries your message; it does not prove who you are. Domain authentication — SPF, DKIM, DMARC — happens elsewhere, in your DNS records, and that is what Gmail and Yahoo look at before deciding where to put your letter.

Put plainly: a perfect SMTP setup on an unauthenticated domain lands in spam, and no port can do anything about it.

Sending without setting a port

With Plumail, sending goes through an HTTP API, and domain authentication is set once, guided. 3,000 emails a month, no credit card.