Proposal: SMTP Over TLS on Port 26

SMTP is still suffering from downgrade attacks like STRIPTLS. While we have “Opportunistic TLS”, we still don’t have “Implicit TLS” in the SMTP. Just to be clear, we do have “Implicit TLS” for “SMTP Submission” on port 465. But we don’t have a secure port 25 alternative. i.e. The real SMTPS.

Both MTA-STS and DANE tries to fix the STARTTLS downgrade issue. However the implementation is not simple. The former requires a HTTPS server and the latter requires TLSA dns record support.

This proposal fixes STARTTLS downgrade issue and propose a new port 26, an “Implicit TLS” alternative for port 25 and recommends the MX server to signal the port via a prefix.


20 years back “Opportunistic TLS” was introduced instead of “Implicit TLS”. That's because there was no way for a server to “signal” the port 465 existence. Actually there was a way (Prefix). But they missed that.

Port 465 was discontinued in the late 90’s and then reassigned to “submissions” in 2018.

This proposal offers two ways.

1. STARTTLS Prefix

Use this prefix on your MX records only to deal with STARTTLS downgrade issue.

e.g. should be prefixed like

Where “starttls-” says “Our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection”.


ACME, Inc. has the following MX servers.

They all should be prefixed like this if they support STARTTLS on port 25.

Now ACME, Inc. need to protect those records via DNSSEC since DNS responses can be modified.

If ACME, Inc. use a third party mail hosting services like Google G-Suite, Google MX servers will begin with “starttls-” prefix. However still need to protect their DNS via DNSSEC.

2. SMTPS Prefix

Use this prefix on your MX records if you wanna support both Implicit TLS on port 26 and Opportunistic TLS on port 25.

e.g. should be prefixed like

Where “smtps-” says “We prefer if you connect to our SMTPS in port 26. But we also accept mails in port 25. And our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection”.

In “starttls-” prefix, port 25 MUST support encryption with Valid SSL certificates.

In “smtps-” prefix, BOTH port 26 and port 25 MUST support encryption with Valid SSL certificates.

So now SMTP clients can check for whether MX server starts with the string “smtps”. If it starts with that string, then the clients gonna connect to port 26 (smtps). A normal client that doesn’t know what “smtps” stands for gonna connect to port 25 as usual.

Final Result:

| Port            | 25        | 26        | 587        | 465         |
| --------------- | --------- | --------- | ---------- | ----------- |
| Service Name    | smtp      | smtps     | submission | submissions |
| Protocol Name   | SMTP      | SMTPS     | Submission | SubmissionS |
| Auth Required?  | No        | No        | Yes        | Yes         |
| Implicit TLS?   | No        | Yes       | No         | Yes         |
| Plain Text?     | Yes       | No        | Yes        | No          |
| Discovery?      | MX Record | MX Record | Direct     | Direct      |
| Public?         | Yes       | Yes       | No         | No          |

IANA Considerations

Service Name

Let’s give a service name for IANA identification. Obviously it’s “smtps”.

IANA Service Name: smtps


Port 26 is unassigned. And it’s very adjacent to port 25. So let’s use port 26.

IANA Recommended Port: 26

Certificate Validation

The whole point of SMTPS (port 26) is about security. Clients should treat SMTPS as it treat HTTPS. So when the certificate is invalid, clients should drop the connection rather than proceeding with invalid certificates.

Mail server admins must make sure that they have valid SSL certificates on port 26 before naming their MX servers with “smtps” prefix.


In HTTPS, you have url like this.

That says the following two things.

Protocol: HTTPS


If the certificate presented by the server, doesn’t match the domain, then the certificate is INVALID. End of story.

In SMTPS, you have an email address [email protected]

Original Domain:

The MX record says,

Protocol: SMTPS

Delivery Server Domain:

Since MX records can point to any domain, SSL certificates cannot be trusted here.

For example, what if some attacker, change the MX response from to

Now, you are delivering your mails to the domain instead of domain.

If you don’t want your DNS responses to be spoofed, then you MUST enable DNSSEC for your domain.



This example assumes that your domain name is and your mail servers are,,, and

Step 1: Serve SMTPS mail server on port 26 and make sure to port 25 supports “Opportunistic TLS”.

Note: Both port 25 and 26 must have valid SSL certificates.

Step 2: Update firewall rules

Step 3: Add new hostnames with the same IP addresses

; mail domain              MX      5              MX     10              MX     20              MX     20              MX     40

; SMTP server host names (Old)          A          A          A          A          A

; SMTP server host names (New)   A   A   A   A   A

Note: I excluded AAAA records for simplicity. If you have AAAA records, don’t forget to duplicate that too.

Step 4: Update MX records

; mail domain        MX      5        MX     10        MX     20        MX     20        MX     40

Step 5: Wait for DNS propagation (Wait time depends on your TTL value). Use tools like whatsmydns to check propagation.


Step 6: Remove “SMTP server host names (Old)” once DNS propagated.

Third-Party Hosted

Third-Party mail servers are more like “Software Distributors”. Instead of distributing the “softwares”, they distributed “MX records”. e.g. Google Apps aka. G Suite

Millions of domains depend on the MX records. So third-party mail servers need to main two versions of MX Records for some years.

The following example uses as third party mail hosting provider.

Third party mail servers should work on both cases.

; mail domain        MX      5        MX     10        MX     20        MX     20        MX     40

; mail domain        MX      5        MX     10        MX     20        MX     20        MX     40

Third party mail servers should encourage their customers to update the MX records with the new version for better security.

They should gracefully degrade the older version of MX record. e.g. They should notify their customers via email saying old version will not work after X years.

When the grace period is over, third party mail hosting providers should fetch the MX record from their customers domain and warn them if they still use the older version.

Internationalized Domain Names

IDN converts non ASCII characters to ASCII characters.

Tested on:




So clients should look for prefixes like

“smtps-”, “starttls-”, “xn — smtps-” “xn — starttls-”


In HTTPS, you prepend the “https” in the URL like to signal the port 443 existence.

In this proposal you are doing the same thing with “smtps-” and “starttls-” prefixes. => => =>

Security Considerations

DNS Query responses are prone to forgery. So protect your DNS entries with the help of DNSSEC.

Port 26 will be a secure alternative for Port 25. So Internet Service Providers are advised to take precautions to prevent email spam abuse. They are advised to block port 26, if necessary.

MTA-STS — Requires additional TXT record and a HTTPS server

DANE — Requires DNSSEC and TLSA records.

SMTP Require TLS — Introduces SMTP service extension, REQUIRETLS, and message header field, RequireTLS.