SMTP Port 25 and Actually Getting Email Delivered

Almost every cloud provider blocks outbound port 25 on new accounts. This is universal enough that it should be treated as the default state of the internet rather than a restriction to route around.

It is also, for most applications, entirely beside the point. Port 25 being open is the least interesting factor in whether your email arrives.

Why the restriction exists

Port 25 is the port mail servers use to talk to each other. It is also the port used to send bulk unsolicited mail directly, which is why it attracts abuse.

Providers restrict it because a single abusive sender damages the reputation of an entire IP range, harming every other customer using those addresses. The restriction protects the provider's network and its other users, and it is enforced consistently across essentially all reputable providers — DigitalOcean, Linode, Hetzner, OVHcloud, Kamatera and the rest.

Environments where it has been opened are described that way precisely because it is not the default.

The right architecture for almost everyone

For transactional email — password resets, receipts, notifications — the correct answer is a dedicated email service reached over the submission port:

• Port 587 with STARTTLS, or port 465 with implicit TLS.
• Authenticated with credentials issued by the service.
• Sending from a domain you control, with authentication records configured.

This gives you an established sending reputation, managed IP warming, bounce and complaint handling, feedback loops with the major mailbox providers, and deliverability monitoring. Building those yourself is a substantial ongoing commitment, not a weekend project.

Submission ports are not blocked. This architecture works on every provider without special arrangements.

Authentication: what actually determines delivery

Three DNS records do most of the work. Without them, mail is very likely to be filtered regardless of which port it left from.

SPF lists which servers may send for your domain.

“ v=spf1 include:_spf.yourprovider.com -all “

Use -all (hard fail) once you are confident. ~all (soft fail) is a reasonable starting point. Note the ten-DNS-lookup limit — exceeding it makes SPF fail entirely.

DKIM cryptographically signs each message, letting the recipient verify it was not altered and genuinely came from your domain. Your email service provides the key; you publish it as a DNS record.

DMARC tells receiving servers what to do when SPF and DKIM fail, and asks them to report back.

“ v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com “

Start at p=none and read the reports. Move to p=quarantine, then p=reject, once the reports show legitimate mail passing consistently. Publishing p=reject before you understand your own sending will block your own email.

Reputation, and why it is the hard part

Authentication gets you considered. Reputation gets you delivered.

Mailbox providers build reputation from: complaint rate, bounce rate, spam-trap hits, engagement, sending consistency, and the age of the domain and IP.

What protects it:

• Send only to people who asked. Confirmed opt-in is the standard that holds up.
• Honour unsubscribes immediately, and make them one click.
• Remove hard bounces on the first failure. Repeatedly mailing dead addresses is a strong negative signal.
• Keep complaint rates very low. A fraction of a percent matters.
• Warm up gradually. A new domain or IP sending high volume on day one looks exactly like abuse.
• Separate streams. Transactional and marketing mail should not share a sending domain or IP, because a marketing complaint should never delay a password reset.

Legal obligations

Sending commercial email is regulated, and the rules differ by recipient jurisdiction, not by where your server is:

• GDPR and ePrivacy (EU/UK) — a lawful basis for processing, usually consent for marketing, plus transparency and an easy withdrawal route.
• CAN-SPAM (US) — accurate headers, a valid physical postal address, a working unsubscribe honoured promptly.
• CASL (Canada) — among the strictest, generally requiring express or clearly documented implied consent.

These apply regardless of which port you use or which provider you are on. Consent records, suppression lists and honest sender identification are not optional extras.

When direct port 25 is genuinely appropriate

There are legitimate cases: running your own mail server for a domain, an inbound relay, a legacy system that cannot use a submission port, or a specialised high-volume operation with its own deliverability team.

If that is you, the responsibility that comes with it is real. You own IP reputation, reverse DNS configuration, complaint feedback loops, blocklist monitoring and removal, TLS configuration, and compliance with anti-spam law in every jurisdiction you send into. That is an ongoing operational commitment.

Environments with port 25 available are listed as such across the catalogue precisely because the capability is distinctive — and it should be chosen because you need it and can operate it responsibly, not because it sounds unrestricted.

Frequently asked questions

Will providers open port 25 on request? Some will consider it on established accounts with a clear legitimate use case. It is a review, not a setting.

Can I use my own domain with an email service? Yes, and you should. Publish the service's SPF include and DKIM records for your domain.

Why does my mail go to spam despite SPF and DKIM passing? Authentication is necessary, not sufficient. Reputation, content, engagement and list quality all contribute.

Do I need a dedicated IP? Only at substantial sustained volume. At lower volumes a well-managed shared pool usually delivers better, because it has established reputation.