Secure SMTP

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 21 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

SMTP [RFC5321] has always been defined as an unencrypted protocol. The STARTTLS extension [RFC3207] allows an optional upgrade to TLS within an existing session.¶

Secure SMTP performs the TLS negotiation at the start of each session, so all traffic is encrypted.¶

2. Session protocol

Secure SMTP uses port TBD. To start a session, a Secure SMTP client connects to that port and negotiates a TLS connection. The client MUST use MTA-STS [RFC8461] or DANE for SMTP [RFC7672] to verify that it has connected to the intended server.¶

After the connection, the protocol is identical to SMTP.¶

3. Server discovery

Once a Secure SMTP client identifies a domain to which mail is to be delivered, it MUST do a DNS lookup to locate an MX record for the domain.¶

Secure SMTP servers are identified in an MX record by adding a _ssmtp prefix to the hostname of the server. The _ssmtp prefix is removed from the hostname before finding addresses associated with the secure SMTP server's address.¶

bigcorp.example. IN MX 10 _ssmtp.mail1.bigcorp.example.
                 IN MX 20 mail2.bigcorp.example.

In the example above, mail1.bigcorp.example is a Secure SMTP server, and mail2.bigcorp.example is a conventional SMTP server. If a server provides both conventional and Secure SMTP, two records identify the two services:¶

bigcorp.example. IN MX 10 _ssmtp.mail1.bigcorp.example.
                 IN MX 10 mail1.bigcorp.example.

The numerical priority is used to select a server in the same manner as conventional SMTP. If there is both a conventional and Secure SMTP server at the same priority, a client MAY prefer the Secure one, or it may do load levelling as it would for multiple conventional servers at the same priority.¶

Unlike conventional SMTP, there is no fallback to A or AAAA address records. A domain MUST publish an MX record with a _ssmtp prefix on the host name, to indicate that it supports Secure SMTP.¶

The prefix appears in the MX to identify the server but is not part of the server's hostname. Note that since hostnames cannot contain underscores, there is no conflict with conventional SMTP MX records.¶

4. Differences from SMTP

Secure SMTP servers MUST present a signed certificate that can be verified with MTA-STS, or a certificate that can be verified with DANE for SMTP, or preferably either way.¶

Secure SMTP allows all SMTP extensions except STARTTLS which is irrelevant.¶

When a mail server adds a Received: header field to an incoming message, it identifies the protocol as "with SSMTP" or "with SUTF8SMTP" depending on whether the session used SMTPUTF8.¶

5. Security considerations

Secure SMTP is functionally the same as conventional SMTP except that all sessions are encrypted with TLS and the servers' certificates are validated, which should deter interception and entity-in-the-middle attacks.¶

Messages are still stored in the clear on servers, so the same considerations about message encryption apply as for conventional SMTP.¶

6. IANA Considerations

IANA is requested to allocate a port number for Secure SMTP.¶

IANA is requested to add the following entries to the Mail Transmission Types for the "Received:" Header Field Reference, in the WITH Protocol Types table:¶

SSMTP Secure SMTP¶

SUTF8SMTP Secure SMTP with SMTPUTF8¶

IANA is requested to add the following entry to the Underscored and Globally Scoped DNS Node Names registry.¶

MX _ssmtp [this document]¶

7. Implementation Status

Many MTAs provide secure submission on port 465. Often a configuation tweak will be enough to accept secure SMTP on a different port.¶

Authors' Addresses