HTTP Mail Transfer Protocol

1.1. Problem Statement

This document is motivated by the following properties of SMTP-based mail transfer:¶

Optional transport security:

STARTTLS is negotiated in plaintext and can be removed by an active attacker. Certificate validation is frequently not performed. Additional mechanisms such as MTA-STS and DANE are required to prevent downgrade attacks, and they are not universally deployed.¶

Limited error reporting:

SMTP reply codes [RFC5321] and enhanced status codes [RFC3463], accompanied by free-form text, provide limited structured information about why a message was rejected, which makes automated handling of failures difficult.¶

Inefficient transfer of large content:

All content, including large attachments, is transferred inline within the message. The same content is transferred again for every receiving domain, and there is no standard way to refer to content stored elsewhere with integrity protection.¶

Separate authentication mechanisms:

Sender authentication relies on several independent mechanisms (SPF, DKIM, and DMARC) that are evaluated separately and can give conflicting results.¶

No protection against duplicate delivery:

If the connection is lost after a server has accepted a message but before the client has received the reply, the client cannot tell whether the message was accepted. Retrying the transaction can result in the message being delivered twice.¶

No standard HTTP interface:

Applications increasingly submit mail through HTTP APIs offered by individual products and services. These APIs are proprietary and mutually incompatible, and none of them can be used to transfer mail between independent domains.¶

1.2. Overview of HMTP

HMTP uses HTTP [RFC9110] over TLS as its transport and a JSON [RFC8259] envelope to carry delivery information. Its main properties are:¶

• Transport security is mandatory. HMTP is only defined over HTTPS with certificate validation, so no plaintext mode exists and no downgrade is possible within the protocol. A domain can additionally publish a policy that prevents senders from falling back to SMTP.¶

• The message itself is not changed. Messages are carried in the Internet Message Format [RFC5322] with MIME [RFC2045] exactly as produced by the sender. Servers only prepend trace header fields, as SMTP servers do. Existing DKIM signatures and end-to-end protection such as OpenPGP [RFC9580] or S/MIME [RFC8551] therefore remain valid.¶

• The envelope is separate from the message. As in SMTP, the envelope sender and recipients are distinct from the header fields of the message, which preserves the semantics of blind carbon copies, mailing lists, and forwarding.¶

• Senders are identified by domain. Each request is signed using HTTP Message Signatures [RFC9421] together with Digest Fields [RFC9530], with keys published in DNS in the same way as DKIM keys.¶

• Content may be transferred by reference. A message, or any part of it such as an attachment, may be provided as a URL together with its size and cryptographic hash. The receiving server retrieves such content directly from where it is stored, either before it responds or after it has accepted the message, so that large content does not have to be carried in every request.¶

• Requests are idempotent. Each request carries an identifier that allows the receiving server to recognize a retried request and avoid delivering the same message twice.¶

• Endpoints are discovered through DNS. A single SVCB [RFC9460] record identifies the HMTP endpoint of a domain, and a well-known URI [RFC8615] describes the capabilities of the server.¶

• Errors are structured. Failures are reported using Problem Details for HTTP APIs [RFC9457], with a defined mapping to SMTP enhanced status codes. The result is reported separately for each recipient. Delivery status notifications can optionally be sent as JSON reports to the domain of the sender instead of as DSN messages.¶

• The protocol is extensible. Servers advertise optional extensions, called capabilities, in the Capabilities Document, and requests indicate the capabilities they use, so that new functionality can be added without changing the base protocol.¶

• HMTP coexists with SMTP. HMTP is a complete protocol on its own and does not depend on SMTP, but the two can be combined freely: the protocol is chosen separately for each hop, so a server can receive a message with one protocol and forward it with the other. An implementation can also deliver messages using SMTP when a receiving domain does not publish an HMTP endpoint. Because the message is carried unmodified, no conversion is needed, provided that the SMTP server supports the SMTP extensions that the message requires.¶

HMTP defines two roles: submission, in which a client hands a message to its mail service, and transfer, in which one mail server delivers a message to another. Both use the same data model. Clients authenticate to their submission server using HTTP authentication. Basic authentication [RFC7617] provides compatibility with existing SMTP AUTH credentials, and bearer tokens [RFC6750] obtained through OAuth 2.0 [RFC6749] are supported for deployments that require stronger authentication.¶

1.3. Relationship to SMTP

HMTP is not an extension or a revision of SMTP and does not update [RFC5321]. It is also more than a new transport for the SMTP mail model. HMTP takes from SMTP the parts on which the rest of the mail system depends and redesigns the protocol around them, with security and extensibility built in. Table 1 lists the main SMTP concepts and their HMTP counterparts.¶

The counterparts are specified in Section 4.1, Section 4.3, Section 5.4, Section 8, Section 7.1, Section 5.1, Section 5.2, Section 9.1, Section 6.3, Section 6.5, and Section 9.4.¶

The following parts of the mail system are the same for both protocols: the Internet Message Format, DKIM and DMARC evaluation of the message, the meaning of accepting responsibility for a message, delivery status notifications, and enhanced status codes. This is what allows a message to travel over a path that combines HMTP and SMTP hops without conversion (Section 3.3).¶

In addition, HMTP provides the following, which SMTP offers only through optional extensions or not at all:¶

• Security by default. TLS with certificate validation is mandatory, every transfer request is authenticated by the Sending Domain, and a domain can prevent downgrade to SMTP. In SMTP, the corresponding functions are provided by STARTTLS, SPF, DKIM, DMARC, MTA-STS, and DANE, each of which is deployed separately.¶

• Request identifiers. A Transfer Identifier in every request prevents duplicate delivery when the request is retried (Section 6.4).¶

• Declared extensions. Capabilities are advertised with their parameters in the Capabilities Document, are listed in the requests that depend on them, and are either registered with IANA or named by URIs (Section 5.4).¶

• Structured errors. Each failure is reported per recipient as a problem details object with a registered type (Section 9.1).¶

• Content by reference. Large messages and attachments do not have to be carried in every request (Section 5.2).¶

HMTP does not provide the line-oriented, interactive dialogue of SMTP; each request carries a complete transaction.¶

1.4. Relationship to Other Work

The JSON Meta Application Protocol (JMAP) [RFC8620] [RFC8621] provides HTTP-based access to mailboxes and supports message submission, but it does not define transfer of messages between mail servers. HMTP is complementary: a JMAP server can use HMTP to deliver submitted messages to other domains.¶

Some mail transfer agents provide HTTP APIs for injecting messages. For example, the Halon MTA accepts a multipart HTTP request that carries a JSON object with the envelope sender and recipients together with the message in Internet Message Format, authenticated with an API key [HALON]. Sending services such as Amazon Simple Email Service [AWS-SES] and Oracle Cloud Infrastructure Email Delivery [OCI-EMAIL] likewise offer proprietary HTTP APIs for submitting messages. Each of these APIs is specific to one product or service and covers only submission to it, while delivery to other domains continues to use SMTP. Because each service defines its own API, an application that integrates with one of them cannot switch to another without being modified. HMTP follows a similar model, an envelope that accompanies an unmodified message, and standardizes it for both submission and transfer between independent domains, together with discovery, domain-based authentication, and a common error model.¶

HMTP does not replace DKIM. DKIM signatures inside the message continue to protect the message across all hops, including hops that use SMTP. HMTP signatures protect each individual HMTP request.¶

1.5. Non-Goals

The following are outside the scope of this document:¶

• Defining a new format for messages. Alternative message formats may be defined as extensions.¶

• Defining spam filtering or reputation algorithms. These remain a matter of local policy at the receiving server.¶

• Mailbox access and synchronization, which are addressed by IMAP [RFC9051] and JMAP.¶

• End-to-end encryption of messages, which continues to be provided by existing mechanisms such as OpenPGP and S/MIME.¶

3.1. Roles

Submission:

A Client sends a Message to its Submission Server. The Client authenticates to the Submission Server as described in Section 7.¶

Transfer:

A Sending Server sends a Message to a Receiving Server. The Sending Server signs each request on behalf of the Sending Domain, and the Receiving Server verifies the signature as described in Section 8.¶

Both interactions use the same Data Model (Section 5). A Submission Server typically also acts as a Sending Server for the Messages it accepts.¶

3.2. Message Flow

Figure 1 shows the path of a Message from a Client to a recipient.¶

+--------+  submission   +------------+   transfer   +-----------+
| Client | ------------> | Submission | -----------> | Receiving |
|  (MUA) |    (HMTP)     |   Server   |    (HMTP)    |  Server   |
+--------+               +------------+              +-----------+
                               |                           |
                               | fallback                  v
                               | (SMTP, optional)    +-----------+
                               v                     | Recipient |
                         +------------+              |  Mailbox  |
                         |   SMTP     |              +-----------+
                         |  Server    |
                         +------------+

1. The Client constructs a Message and an Envelope and submits them to its Submission Server.¶

2. The Submission Server authenticates the Client and verifies that the Client is authorized to use the Envelope Sender and the originator addresses of the Message.¶

3. For each recipient domain, the Sending Server performs discovery (Section 4). If the domain publishes an HMTP Endpoint, the Sending Server transfers the Message to it using HMTP. Otherwise, a Sending Server that supports SMTP fallback delivers the Message using SMTP as described in Section 10.¶

4. The Receiving Server verifies the signature of the request, applies its local policy, and accepts or rejects the Message for each Envelope Recipient.¶

5. If the request contains Content References, the Receiving Server retrieves the referenced content and verifies its size and hash, either before it responds or after it has accepted the Message (see Section 5.2.1).¶

6. The Receiving Server prepends a trace header field to the Message and delivers the Message to the recipient mailbox or relays it further.¶

3.3. Coexistence with SMTP

HMTP is designed to coexist with SMTP permanently, not only during a transition period. HMTP does not change the use of MX records [RFC5321] or the operation of existing SMTP servers. A domain can publish an HMTP Endpoint in addition to its MX records, and a server can support both protocols at the same time.¶

The protocol is chosen separately for each hop. A server that supports both protocols decides how to forward a Message independently of the protocol over which it received the Message, so that all four combinations shown in Figure 2 are possible:¶

   incoming hop                                     outgoing hop

  (1) --- HMTP --->  +------------------------+  --- HMTP --->
  (2) --- HMTP --->  |  Server that supports  |  --- SMTP --->
  (3) --- SMTP --->  |  both HMTP and SMTP    |  --- HMTP --->
  (4) --- SMTP --->  |                        |  --- SMTP --->
                     +------------------------+

HMTP to HMTP:

A server relays a Message that it received over HMTP to another HMTP Endpoint, for example a Submission Server that delivers to a domain that publishes an HMTP Endpoint.¶

HMTP to SMTP:

A server accepts a Message over HMTP and forwards it over SMTP. Examples are a Submission Server that sends all outbound Messages through an SMTP relay of its operator, a Receiving Server that passes accepted Messages to an existing SMTP-based mail system of the recipient domain, and a Sending Server that falls back to SMTP for a domain that does not support HMTP (Section 10).¶

SMTP to HMTP:

A server accepts a Message over SMTP and forwards it over HMTP. Examples are an existing MX server that relays Messages to an HMTP-based mailbox service of the same domain, and an SMTP server that delivers outbound Messages to domains that publish an HMTP Endpoint, as described in Section 10.3.¶

SMTP to SMTP:

The operation of SMTP is not affected by HMTP.¶

In every combination, the Message is forwarded unchanged, except for the trace header fields that each server prepends (Section 6.5), and the Envelope information is carried over between the parameters of SMTP commands and the members of the Envelope as described in Section 10.1 and Section 10.3. DKIM signatures and end-to-end protection of the Message therefore remain valid on any path.¶

How the protocol for an outgoing hop is chosen depends on how the next hop is determined:¶

• If the next hop is determined by discovery for the domain of an Envelope Recipient, HMTP is used if the domain supports it. SMTP is used only under the conditions of Section 10.1, which include the downgrade policy of the domain.¶

• If the next hop is determined by local configuration, for example a relay of the operator of the server, the internal mail system of the recipient domain, or a filtering or backup service under an agreement with the recipient domain, the server uses the protocol configured for that next hop. This is not a fallback in the sense of Section 10. The rules of Section 10.1 apply to the server that eventually delivers the Message to the recipient domain.¶

As a result, a domain can, for example, receive mail over HMTP while its outbound mail continues to use SMTP, or send mail over HMTP while it continues to receive mail over SMTP, without any dependency between the two directions.¶

Support for SMTP is not required for an HMTP implementation. A server that implements only HMTP is fully conformant to this document; it can exchange mail only with domains that publish an HMTP Endpoint.¶

4.1. DNS Record

A domain that supports HMTP publishes one or more SVCB resource records [RFC9460] at the following owner name:¶

_hmtp.<domain>

where <domain> is the domain part of an email address, in the form of A-labels [RFC5890] for internationalized domain names. The "_hmtp" label is a globally scoped underscored node name [RFC8552]. It does not indicate a transport protocol, which is determined by the "alpn" SvcParam.¶

Addresses whose domain part is an address literal [RFC5321] have no associated DNS name; HMTP is not used for such addresses.¶

The records are interpreted according to [RFC9460] with the following rules:¶

• AliasMode records are processed as specified in [RFC9460]. An AliasMode record whose TargetName is "." indicates that the domain does not provide HMTP (Section 2.5.1 of [RFC9460]).¶

• In ServiceMode records, the TargetName identifies the host that provides the HMTP Endpoint. Because the owner name of the record is not a host name, the TargetName of a ServiceMode record MUST NOT be ".". A ServiceMode record whose TargetName is "." is unusable.¶

• The "alpn" SvcParam MUST be present and MUST include "h2". It MAY also include "h3". Servers MUST support HTTP/2 [RFC9113] and MAY support HTTP/3 [RFC9114]. A ServiceMode record without an "alpn" SvcParam, or whose "alpn" SvcParam does not include "h2", is unusable.¶

• The "port" SvcParam indicates the TCP or UDP port of the HMTP Endpoint. If it is absent, port 443 is used.¶

• Other SvcParams, such as "ipv4hint" and "ipv6hint", are used as defined in [RFC9460] and in the documents that define them. A record that lists an unsupported key in the "mandatory" SvcParam is unusable, as specified in [RFC9460].¶

• If multiple ServiceMode records are present, the host to connect to is selected as described in Section 4.2.¶

A Sending Server uses the domain of each Envelope Recipient to locate the Receiving Server. A Client uses the domain of its own address to locate its Submission Server. A Client MAY instead be configured with the URI of the Capabilities Document of its Submission Server.¶

When connecting to the target host, the server or Client MUST validate the TLS certificate of the host against the TargetName, as described in [RFC9525]. DNS responses SHOULD be validated using DNSSEC [RFC4033] when available. See Section 14.2 for the consequences of an unauthenticated DNS response.¶

The result of the DNS query is interpreted as follows:¶

• If the query returns one or more usable ServiceMode records, the domain supports HMTP.¶

• If the query returns a response indicating that the name does not exist or that no SVCB records exist for it, if the only record is an AliasMode record whose TargetName is ".", or if all returned records are unusable, the domain does not support HMTP. A Sending Server then proceeds as described in Section 10.¶

• If the query fails for any other reason, such as a timeout or a server failure, the result MUST be treated as a temporary failure. The server MUST NOT conclude that the domain does not support HMTP.¶

Results of DNS queries MAY be cached for the duration of their TTL.¶

4.2. Selection of the Target Host

A domain can publish several ServiceMode records, for example to provide redundant hosts or a backup host. The server or Client selects among them in the same way as an SMTP client selects among MX records (Section 5.1 of [RFC5321]):¶

1. It discards the records that are unusable as described in Section 4.1.¶

2. It orders the remaining records by their SvcPriority, from the lowest value to the highest. A lower value indicates a more preferred host.¶

3. It orders records with the same SvcPriority randomly, so that each of them is equally likely to be tried first, as recommended in Section 2.4.1 of [RFC9460]. SVCB records have no weight, so the load is distributed evenly among hosts of equal priority.¶

4. It tries the hosts in the resulting order. A host with a higher SvcPriority value is tried only after all hosts with lower values have failed.¶

5. If the attempt fails at every host, the delivery attempt has failed temporarily. The server retries later as described in Section 6.4, starting again with step 1, so that a new random order is used. A retry of a request whose outcome is unknown is an exception to this rule, as described below.¶

If the TargetName of a host resolves to several IP addresses, the server or Client tries these addresses before it proceeds to the next host, for example using the Happy Eyeballs algorithm [RFC8305].¶

The server or Client proceeds to the next host if the attempt at the current host fails in one of the following ways:¶

• The TargetName cannot be resolved, or no connection can be established to any of its addresses.¶

• The TLS handshake fails, including a failure to validate the certificate of the host.¶

• The Capabilities Document cannot be retrieved because of a temporary failure, or the host is not usable according to Section 4.3.¶

• The connection fails before the request has been sent completely, or the host indicates that it has not processed the request, for example in HTTP/2 by resetting the stream with the error code REFUSED_STREAM or by sending a GOAWAY frame whose last stream identifier is lower than that of the request (Section 8.7 of [RFC9113]).¶

• The response has the status code 500, 502, or 503 and does not contain a problem details object with an "smtpStatus" member. Such a response is typically generated by an intermediary, such as a load balancer, that could not pass the request to an HMTP server.¶

Otherwise, the attempt ends, and the server or Client does not try further hosts:¶

• A response with the status code 200 (OK) or 202 (Accepted) completes the attempt. Envelope Recipients with the result "deferred" are retried later as described in Section 6.4.¶

• A response that contains a problem details object with an "smtpStatus" member has been generated by an HMTP server that received the request, whatever its status code. Trying another host would not help, because the condition usually applies to the domain as a whole, as with "rate-limited" or "key-unavailable", or could cause the request to be processed twice, as with "request-in-progress". The response is handled as described in Section 6.4, according to the class of the "smtpStatus" member: a temporary failure is retried later, and a permanent failure is not retried. Any other response is handled in the same way, according to its status code.¶

• If no response is received after the request has been sent completely, for example because the connection is lost or a timeout expires, or if the response has the status code 504 (Gateway Timeout) and does not contain a problem details object, the outcome of the request is unknown. The request is retried later.¶

A request whose outcome is unknown, or that was rejected with the "request-in-progress" problem type, may have been processed, or may still be processed, by the host. A retry at another host could then cause duplicate delivery, because the other host does not necessarily know the Transfer Identifier. The sender therefore sends the retry (Section 6.4) to the same host, rather than to a host chosen in a new random order. It proceeds to the other hosts, in the order described above, only if the retry fails at that host in one of the first four ways listed above, or if the host is no longer listed in the SVCB records of the domain.¶

Even then, the host may have processed the request before it became unreachable. A domain that publishes several hosts SHOULD therefore ensure that the stored Transfer Identifiers are shared among them. Where this is not possible, for example for a backup host operated by a third party, duplicate delivery can still occur (see Section 14.10).¶

A server MAY reuse an established connection to a host for further requests for the same domain while the SVCB records that led to the host remain valid.¶

In the following example, the hosts "hmtp1.example.net" and "hmtp2.example.net" share the lowest priority. Each of them is tried first with equal probability, and the other one is tried if the first fails. The host "backup.provider.example" is tried only if both fail:¶

_hmtp.example.net.  3600 IN SVCB 10 hmtp1.example.net. alpn=h2,h3
_hmtp.example.net.  3600 IN SVCB 10 hmtp2.example.net. alpn=h2,h3
_hmtp.example.net.  3600 IN SVCB 20 backup.provider.example. alpn=h2

4.3. Capabilities Document

The Capabilities Document describes the HMTP Endpoint of a host. It is retrieved with an HTTP GET request to the well-known URI [RFC8615] "/.well-known/hmtp" on the target host and port identified by the DNS record. The request carries no authentication, and servers MUST NOT require authentication or a signature to retrieve the Capabilities Document.¶

The response is a JSON object with the media type "application/json" and contains the following members:¶

versions:

REQUIRED. A JSON object whose member names identify the versions of HMTP supported by the server and whose values are Version Objects. Version names are strings of decimal digits without leading zeros; a higher number denotes a later version. This document defines version "1". When the server and the sender of a request have more than one version in common, the sender SHOULD use the highest of them. The object MUST contain at least one member.¶

A Version Object contains the following member:¶

endpoints:

REQUIRED. A JSON object whose member names identify the interactions supported in this version and whose values are Endpoint Objects (Section 4.3.1). This document defines the following members:¶

• "transfer": the Transfer Endpoint Object, which describes the endpoint for transfer (Section 6) and the related OPTIONAL endpoint for delivery status reports (Section 9.4);¶

• "submission": the Submission Endpoint Object, which describes the endpoint for submission (Section 7) and the related identities endpoint (Section 7.4).¶

At least one of "transfer" and "submission" MUST be present. Additional endpoints MAY be defined by capabilities (Section 5.4) and are registered as described in Section 16.7.2.¶

limits:

OPTIONAL. A JSON object describing limits of the server, which apply to all of its endpoints unless an Endpoint Object specifies other values (Section 4.3.1). All values are non-negative integers. This document defines the following members:¶

• "maxMessageSize": the maximum size of a Message in octets, after the reconstruction of all segments described in Section 5.2.¶

• "maxRequestSize": the maximum size of the content of an HMTP request in octets, that is, of the JSON document itself. Content that is transferred by reference does not count toward this limit.¶

• "maxRecipients": the maximum number of Envelope Recipients in one request. The value MUST NOT be less than 100.¶

• "maxIdLength": the maximum length of a Transfer Identifier in characters (see Section 5.1). The value MUST NOT be less than 22 and MUST NOT be greater than 255. If this member is absent, the maximum length is 64.¶

The absence of any other limit means that the server does not advertise it; the server can still reject a request that exceeds a limit it applies, as described in Section 9.1. Where this document refers to a limit of a server or of the recipient of a request, it means the value that applies to the endpoint to which the request is sent.¶

policy:

OPTIONAL. A JSON object that expresses the downgrade policy of the domains served by this host. It is specified in Section 10.2.¶

capabilities:

OPTIONAL. A JSON object whose member names identify supported extensions and whose values contain parameters of each extension. Extensions are specified as described in Section 5.4. Their names are either registered with IANA or URIs that serve only as unique names (Section 5.4.1).¶

Recipients of the Capabilities Document MUST ignore members they do not understand.¶

_hmtp.example.com.  3600 IN SVCB 1 hmtp.provider.example. (
                               alpn=h2,h3 )

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=86400

{
  "versions": {
    "1": {
      "endpoints": {
        "transfer": {
          "uri": "/hmtp/v1/transfer",
          "reports": "/hmtp/v1/reports"
        },
        "submission": {
          "uri": "/hmtp/v1/submission",
          "identities": "/hmtp/v1/identities",
          "authentication": ["basic", "bearer"],
          "oauthResourceMetadata":
            "/.well-known/oauth-protected-resource",
          "limits": {
            "maxRecipients": 100
          }
        }
      }
    }
  },
  "limits": {
    "maxMessageSize": 107374182400,
    "maxRequestSize": 52428800,
    "maxRecipients": 1000,
    "maxIdLength": 64
  },
  "policy": {
    "mode": "enforce",
    "maxAge": 604800
  },
  "capabilities": {}
}

5.1. Envelope

The Envelope is a JSON object with the following members:¶

id:

REQUIRED. The Transfer Identifier of the request. It is a string of at least 22 characters consisting only of the characters of the base64url alphabet (Section 5 of [RFC4648]): "A" to "Z", "a" to "z", "0" to "9", "-", and "_". Its length MUST NOT exceed the "maxIdLength" limit of the recipient of the request (see Section 4.3). The sender MUST generate the Transfer Identifier with at least 128 bits of randomness, for example from 16 random octets encoded in base64url without padding, which yields 22 characters. A request whose Transfer Identifier does not meet the requirements on its length and characters is rejected with the "invalid-request" problem type.¶

A Transfer Identifier is not globally unique and is never interpreted on its own. The recipient of a request stores and compares it only together with its scope (Section 6.4):¶

• for a transfer request, the Sending Domain, that is, the domain of the key that signed the request as established by the verification procedure (Section 8.3). The host name and IP address of the Sending Server are not part of the scope, so that a retry is recognized even if it is sent from another host of the same Sending Domain. Neither is the selector of the key, so that a retry is recognized even if it is signed with a new key after a key rollover;¶

• for a submission request, the account of the authenticated Client.¶

The sender MUST generate Transfer Identifiers that are unique within their scope. Identical Transfer Identifiers in different scopes, for example from two different Sending Domains, identify unrelated requests. Several independent senders can share one scope, for example a domain and an email service provider to which it has delegated a selector (Section 8.5). The randomness of Transfer Identifiers ensures that the identifiers of such senders do not collide without any coordination between them.¶

from:

REQUIRED. The Envelope Sender. The value is either a "Mailbox" as defined in Section 4.1.2 of [RFC5321], without the enclosing angle brackets, or the empty string, which denotes the null reverse-path. If "smtpUtf8" is true, the address MAY use the syntax extended by [RFC6531].¶

to:

REQUIRED. A non-empty array of Recipient Objects, one for each Envelope Recipient. The array MUST NOT contain two Recipient Objects with the same address. Its length MUST NOT exceed the "maxRecipients" limit of the recipient of the request, if one is advertised.¶

dsn:

OPTIONAL. A JSON object that carries the per-message parameters of the Delivery Status Notification (DSN) extension [RFC3461]. It has the following members, both OPTIONAL:¶

• "ret": the string "full" or "hdrs", with the semantics of the RET parameter of [RFC3461];¶

• "envid": a string with the semantics of the ENVID parameter of [RFC3461]. The value is carried in decoded form, without the "xtext" encoding used in SMTP, and is subject to the same length and character restrictions as in [RFC3461].¶

body:

OPTIONAL. The type of the body of the Message. The value is one of "7bit", "8bitmime", and "binarymime", with the semantics of the BODY parameter values "7BIT", "8BITMIME" [RFC6152], and "BINARYMIME" [RFC3030], respectively. The default is "7bit". The sender MUST set this member to a value that correctly describes the Message.¶

smtpUtf8:

OPTIONAL. A boolean that is true if any address in the Envelope or any header field of the Message contains non-ASCII characters, as permitted by [RFC6531] and [RFC6532]. The default is false. The sender MUST set this member to true in that case.¶

requireTls:

OPTIONAL. A boolean that, when true, requests that the Message be transferred only over connections that are protected by TLS with certificate validation on every hop, with the semantics of the REQUIRETLS extension [RFC8689]. The default is false. HMTP hops always satisfy this requirement; SMTP hops are governed by [RFC8689].¶

A Recipient Object is a JSON object with the following members:¶

address:

REQUIRED. The Envelope Recipient. The value is a "Mailbox" as defined in Section 4.1.2 of [RFC5321], without the enclosing angle brackets, or, if "smtpUtf8" is true, as extended by [RFC6531]. A sender MUST NOT send an address that does not have this syntax. If the value is a string that does not have this syntax, the Request Object is nevertheless valid: the recipient of the request rejects only this Envelope Recipient, with the "invalid-address" problem type (Section 6.2), and processes the other Envelope Recipients as usual.¶

dsn:

OPTIONAL. A JSON object that carries the per-recipient parameters of the DSN extension [RFC3461]. It has the following members, both OPTIONAL:¶

• "notify": an array of strings with the semantics of the NOTIFY parameter of [RFC3461]. The array contains either the single value "never", or one or more of the values "success", "failure", and "delay";¶

• "orcpt": a string with the semantics of the ORCPT parameter of [RFC3461], consisting of an address type, a semicolon, and the original recipient address, for example "rfc822;bob@example.net". The value is carried in decoded form, without the "xtext" encoding used in SMTP.¶

When the domain part of an address is compared, for example to determine alignment (Section 8.4) or to perform discovery, it is first converted to A-labels and then compared without regard to case.¶

The following example shows an Envelope:¶

{
  "id": "3q2-7wEXAMPLEd9Kc1fQ0g",
  "from": "bounces+7f3a@example.com",
  "to": [
    {"address": "bob@example.net"},
    {
      "address": "carol@example.net",
      "dsn": {
        "notify": ["failure", "delay"],
        "orcpt": "rfc822;carol@example.net"
      }
    }
  ],
  "dsn": {"ret": "hdrs", "envid": "QQ314159"},
  "body": "8bitmime"
}

5.2. Content Object

A Content Object carries a sequence of octets, called its content. It takes one of three forms, distinguished by the members present. A Content Object MUST contain exactly one of the members "data", "uri", and "segments".¶

Inline:

The content is carried in the request. The Content Object has the following member:¶

data:

REQUIRED. The content, encoded using base64 as defined in Section 4 of [RFC4648], with padding and without line breaks.¶

Reference:

The content is retrieved from a URI. A Content Object of this form is a Content Reference and has the following members:¶

uri:

REQUIRED. An absolute URI [RFC3986] with the "https" scheme from which the content is retrieved, as described in Section 5.2.1.¶

size:

REQUIRED. The size of the retrieved representation data in octets, before any transformation specified by "encoding".¶

digest:

REQUIRED. A Digest Object for the retrieved representation data, before any transformation specified by "encoding".¶

expires:

REQUIRED. A timestamp until which the sender guarantees that the content can be retrieved from the URI. The timestamp MUST be at least 24 hours after the time at which the request is sent and SHOULD be at least 7 days after it.¶

encoding:

OPTIONAL. The name of a transformation that is applied to the retrieved representation data to produce the content, as described in Section 5.3. If this member is absent, the content is the retrieved representation data itself.¶

Composite:

The content is the concatenation of the content of a sequence of segments. The Content Object has the following members:¶

segments:

REQUIRED. A non-empty array of Content Objects, each of which is either of the inline or of the reference form. A segment MUST NOT itself be of the composite form.¶

size:

REQUIRED. The size of the content, that is, the sum of the sizes of the content of all segments.¶

The content of a composite Content Object is reconstructed by concatenating the content of its segments in the order in which they appear in the array. No octets are added between segments. The integrity of the reconstructed content follows from the integrity of each segment: inline segments are covered by the Content-Digest of the request, and reference segments by their "digest" member. Recipients MUST support composite Content Objects with at least 64 segments.¶

A Digest Object is a JSON object whose member names are hash algorithm keys from the "Hash Algorithms for HTTP Digest Fields" registry established by [RFC9530] and whose values are the hashes computed with these algorithms, encoded using base64 as defined in Section 4 of [RFC4648]. A Digest Object MUST contain at least one of the members "sha-256" and "sha-512", and MAY contain additional members. Recipients MUST support "sha-256" and "sha-512", MUST ignore algorithms they do not support, and MUST verify the hash of every supported algorithm that is present. If a Digest Object contains no supported algorithm, the request is rejected with the "invalid-request" problem type.¶

The "maxMessageSize" limit (Section 4.3) applies to the size of the reconstructed Message. Because the size of every segment is known before any content is retrieved, the recipient of a request can determine whether the limit is exceeded without retrieving any content.¶

The following example shows a Message carried inline and the same Message carried as a single Content Reference:¶

{
  "data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..."
}

{
  "uri": "https://files.example.com/m/7f3a91c2e4d8",
  "size": 52428800,
  "digest": {
    "sha-256": "rbJw2yTgX0Gj3nVQb1Zu4eKcN9mF8sPq7LdW6xHtA0E="
  },
  "expires": "2026-01-08T12:00:00Z"
}

5.3. Attachments

A composite Content Object allows a sender to transfer parts of a Message, such as the body of an attachment, by reference, while the reconstructed Message remains identical, octet for octet, to the Message as produced by its originator. DKIM signatures and other signatures computed over the Message therefore remain valid.¶

To transfer an attachment by reference, the sender splits the Message into three segments: an inline segment containing everything up to the first octet of the body of the MIME body part, a reference segment containing the body of the body part, and an inline segment containing the remainder of the Message. Following [RFC2046], the CRLF that precedes a boundary delimiter belongs to the delimiter and therefore to the following inline segment. A Message may contain any number of such references, subject to the limit on segments described in Section 5.2.¶

Attachments are usually encoded with the base64 Content-Transfer-Encoding [RFC2045], while the content stored at a URI is usually the original, unencoded file. The "encoding" member allows a Content Reference to refer to the unencoded file. This document defines the following encoding:¶

base64:

The retrieved representation data is encoded using base64 as defined in Section 6.8 of [RFC2045]. The encoded output is divided into lines of exactly 76 characters, except that the last line contains the remaining 1 to 76 characters. Lines are separated by CRLF. No CRLF follows the last line. If the representation data is empty, the content is empty.¶

A sender MUST use the "base64" encoding only if the body of the MIME body part in the Message is exactly the output of this transformation. Senders that wish to use this encoding therefore produce base64-encoded body parts with lines of 76 characters, which is the most common practice. The size of the content produced by the "base64" encoding from n octets of representation data is 4 * ceil(n / 3) characters plus 2 octets for each line separator.¶

Additional encodings can be registered as described in Section 16.7.3. A sender MUST NOT use an encoding other than "base64" unless the recipient of the request advertises support for it through a capability.¶

The following example shows a Message with a 700 MiB attachment. The first segment contains the header section and the MIME structure up to the body of the attachment, which is followed by a CRLF and the closing boundary delimiter "--b1--" in the last segment:¶

{
  "segments": [
    {
      "data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..."
    },
    {
      "uri": "https://files.example.com/f/9b1c4e7a",
      "size": 734003200,
      "digest": {
        "sha-256": "Yk3qV0sJpRm9T2cFhWxN6dL1bA8eQu7ZgKi4oPyXwE0="
      },
      "expires": "2026-01-08T12:00:00Z",
      "encoding": "base64"
    },
    {
      "data": "DQotLWIxLS0NCg=="
    }
  ],
  "size": 1004426786
}

In this example, the first segment contains 1342 octets, the second segment produces 1004425434 octets after the "base64" encoding, and the last segment contains 10 octets.¶

The same URI can be used in requests to any number of Receiving Servers, so that the attachment is uploaded by the originator only once. Receiving Servers that retrieve the same content for several Messages can recognize it by its digest. Messages that are protected end to end, such as encrypted OpenPGP or S/MIME messages, can only be transferred by reference as a whole.¶

5.4. Capabilities

Capabilities allow HMTP to be extended without changing this document. A capability can define new members of the Request Object, the Envelope, the Recipient Object, Content Objects, the Response Object, and the Capabilities Document; new endpoints; new encodings; and new problem types. Examples of functionality that could be defined as capabilities include the transfer of several Messages in one request, a status endpoint for submitted Messages, and the recall of Messages that have not yet been delivered.¶

{
  "versions": {
    "1": {
      "endpoints": {
        "transfer": {
          "uri": "/hmtp/v1/transfer"
        }
      }
    }
  },
  "capabilities": {
    "https://vendor.example/hmtp/future-release": {
      "maxInterval": 604800
    }
  }
}

{
  "capabilities": [
    "https://vendor.example/hmtp/future-release"
  ],
  "envelope": {
    "id": "Rt5yU8iO1pA4sD7fG0hJ2k",
    "from": "alice@example.com",
    "to": [{"address": "bob@example.net"}],
    "https://vendor.example/hmtp/future-release": {
      "releaseAt": "2026-01-02T09:00:00Z"
    }
  },
  "message": {
    "data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..."
  }
}

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type": "urn:ietf:params:hmtp:error:unsupported-capability",
  "title": "Unsupported capability",
  "status": 400,
  "detail": "https://vendor.example/hmtp/future-release",
  "smtpStatus": "5.5.4",
  "smtpReply": 555
}

6.1. Request

A transfer request is an HTTP POST request [RFC9110] to the transfer endpoint, with the following properties:¶

• The content of the request is a Request Object (Section 5), and the Content-Type header field is "application/json".¶

• The request MUST contain a Content-Digest header field [RFC9530] computed over the content of the request, using the "sha-256" or "sha-512" algorithm.¶

• The request MUST be signed on behalf of the Sending Domain as described in Section 8, using the Signature-Input and Signature header fields [RFC9421].¶

• If the Envelope Sender is not empty, its domain MUST be aligned with the Sending Domain as described in Section 8.4.¶

• The request does not use HTTP authentication. Receiving Servers ignore any Authorization header field in a transfer request.¶

• The content of the request MAY use a content coding only if the Receiving Server has indicated support for it in an Accept-Encoding header field, as described in Section 12.5.3 of [RFC9110].¶

A Sending Server SHOULD reuse connections for several requests and MAY send several requests concurrently on one connection, within the limits that the Receiving Server sets, such as the SETTINGS_MAX_CONCURRENT_STREAMS setting of HTTP/2 [RFC9113]. This document does not define the transfer of several Messages in one request.¶

Sending Servers SHOULD wait at least 10 minutes for the response after the request has been sent completely, consistent with the timeouts recommended in Section 4.5.3.2 of [RFC5321].¶

The following example shows a transfer request:¶

NOTE: '\' line wrapping per RFC 8792

POST /hmtp/v1/transfer HTTP/1.1
Host: mx.example.net
Content-Type: application/json
Content-Digest: sha-256=:Cw2CRUGnwBRSPpU7qzJnP6Fk2zBdJ8u8mXh7sQe1zYI=:
Signature-Input: hmtp=("@method" "@target-uri" "content-type" \
  "content-digest");created=1767268800;expires=1767269100;\
  keyid="hmtp2026";domain="example.com";alg="ed25519";tag="hmtp"
Signature: hmtp=:3iXk1Lw3P1pZq9xH0M2eR8vUe6bJ4yD7nT5aC0fK2gS9\
  hV1mQ4wL8oE6rB3tY7uI0pA5sD2fG9hJ1kL3zX8cVQ==:

{
  "envelope": {
    "id": "3q2-7wEXAMPLEd9Kc1fQ0g",
    "from": "bounces+7f3a@example.com",
    "to": [
      {"address": "bob@example.net"},
      {"address": "carol@example.net"}
    ]
  },
  "message": {
    "data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..."
  }
}

6.2. Processing by the Receiving Server

A Receiving Server processes a transfer request as follows:¶

1. It verifies that the request uses the POST method and that the media type and size of the content are acceptable. It rejects a request whose content exceeds its "maxRequestSize" limit with the "request-too-large" problem type.¶

2. It verifies the signature and the Content-Digest of the request as described in Section 8.3, including the alignment of the Envelope Sender (Section 8.4).¶

3. It parses the Request Object and validates it against Section 5. It rejects an invalid Request Object with the "invalid-request" problem type. A syntactically invalid address of an Envelope Recipient does not make the Request Object invalid; it is handled in step 7.¶

4. It checks the Transfer Identifier as described in Section 6.4. If the request is a retry of a request that has already been processed, it returns the stored response and does not process the request again.¶

5. It checks that it supports every capability listed in the "capabilities" member (Section 5.4).¶

6. It verifies that the size of the Message does not exceed its "maxMessageSize" limit and that the number of Envelope Recipients does not exceed its "maxRecipients" limit.¶

7. It determines, for each Envelope Recipient, whether it accepts the Message for that recipient. It rejects an Envelope Recipient whose address is syntactically invalid (Section 5.1) with the "invalid-address" problem type. For an Envelope Recipient whose domain it does not serve, and for which it has no agreement to relay, it rejects the recipient with the "domain-not-served" problem type. Other decisions are a matter of local policy.¶

8. It retrieves referenced content as described in Section 5.2.1, either before responding or after responding, or, if it relays the Message, passes the Content References on to the next hop.¶

9. It prepends trace header fields as described in Section 6.5, stores the Message for each accepted Envelope Recipient, and sends the response.¶

A Receiving Server MAY perform these steps in a different order, as long as the result is the same. In particular, it MAY start verifying the signature before the content of the request has been received completely.¶

6.3. Response

If the Receiving Server has processed the request, it responds with a Response Object and one of the following status codes, even if it has rejected the Message for some or all Envelope Recipients:¶

200 (OK):

The request has been processed completely. Either the request contains no Content References, or all referenced content has been retrieved and verified, or the Message has not been accepted for any Envelope Recipient.¶

202 (Accepted):

The Message has been accepted for at least one Envelope Recipient, but the retrieval of referenced content is still pending. The Receiving Server has accepted responsibility for completing the retrieval later, or for passing the Content References on to a next hop that takes over this responsibility, as described in Section 5.2.1. A Receiving Server MUST NOT use this status code for a request that contains no Content References.¶

In both cases, the results for the individual Envelope Recipients are final: a recipient with the result "accepted" remains accepted, and any later failure, including a failure of the pending retrieval, is reported through a delivery status notification (Section 9.3). The status code only tells the sender whether it still has to keep the referenced content available.¶

If the request as a whole fails, the Receiving Server responds with a 4xx or 5xx status code and a problem details object as described in Section 9.1; in that case, the Message has not been accepted for any Envelope Recipient.¶

The Response Object is a JSON object with the media type "application/json" and the following members:¶

queueId:

OPTIONAL. A string assigned by the Receiving Server that identifies the Message in its systems, such as a queue identifier. It is intended for logging and diagnostics.¶

recipients:

REQUIRED. An array of Recipient Result Objects, exactly one for each Envelope Recipient, in the same order as in the "to" member of the Envelope.¶

A Recipient Result Object is a JSON object with the following members:¶

address:

REQUIRED. The address of the Envelope Recipient, as given in the request.¶

result:

REQUIRED. One of the following strings:¶

• "accepted": the Receiving Server has accepted responsibility for delivering or relaying the Message to this recipient, with the semantics of Section 6.1 of [RFC5321]. It MUST NOT lose the Message, and if it later fails to deliver it, it generates a delivery status notification as described in Section 9.3.¶

• "deferred": the Message was not accepted for this recipient because of a temporary condition. The sender MAY retry delivery to this recipient later.¶

• "rejected": the Message was not accepted for this recipient because of a permanent condition. The sender MUST NOT retry delivery to this recipient.¶

problem:

REQUIRED if "result" is "deferred" or "rejected", and absent otherwise. A problem details object, as described in Section 9.1, that describes the reason. Its "smtpStatus" member MUST have the class 4 if "result" is "deferred" and the class 5 if "result" is "rejected".¶

The following example shows a response in which the Message was accepted for one recipient and rejected for another:¶

HTTP/1.1 200 OK
Content-Type: application/json

{
  "queueId": "4Y7mKq2ZtR",
  "recipients": [
    {
      "address": "bob@example.net",
      "result": "accepted"
    },
    {
      "address": "carol@example.net",
      "result": "rejected",
      "problem": {
        "type": "urn:ietf:params:hmtp:error:unknown-recipient",
        "title": "Unknown recipient",
        "detail": "The mailbox carol@example.net does not exist.",
        "smtpStatus": "5.1.1",
        "smtpReply": 550
      }
    }
  ]
}

6.4. Retries and Idempotency

The Transfer Identifier allows a Receiving Server to recognize a request that is retried because the sender did not receive the response, for example because the connection was lost after the Receiving Server had accepted the Message.¶

The scope of a Transfer Identifier is the Sending Domain for transfer requests, and the authenticated account of the Client for submission requests (see Section 5.1). The key under which a Receiving Server stores and looks up a Transfer Identifier is therefore the pair (Sending Domain, Transfer Identifier) for transfer requests and the pair (account, Transfer Identifier) for submission requests. The Sending Domain is the one established by verifying the signature of the request (Section 8.3), never a value taken from the content of the request. A sender MUST NOT use the same Transfer Identifier within one scope for requests with different content.¶

When a Receiving Server sends a 200 (OK) or 202 (Accepted) response to a transfer or submission request, or a 204 (No Content) response to a delivery status report (Section 9.4.3), it MUST store the key, a hash of the content of the request, and the response, and MUST retain them for at least 24 hours. The hash is computed over the content after any content coding has been removed, so that a retry is recognized even if it uses a different content coding. When the Receiving Server receives a request whose key matches a stored entry:¶

• If the hash of the content of the request matches, the Receiving Server MUST NOT process the request again and MUST return the stored response. If the stored response has the status code 202 (Accepted) and the retrieval of referenced content has been completed in the meantime, it MAY return the status code 200 (OK) with the same Response Object instead. Senders MUST NOT retry requests solely to learn whether a retrieval has been completed.¶

• Otherwise, it MUST reject the request with the "id-conflict" problem type. If the stored response contains a Response Object, the problem details object contains, as extension members, its "recipients" member and, if present, its "queueId" member.¶

If a request with the same scope and Transfer Identifier is still being processed, the Receiving Server MUST NOT process the second request concurrently. It either waits until the processing of the first request has been completed and then proceeds as described above, or rejects the second request with the "request-in-progress" problem type, which is a temporary failure. A response with this problem type SHOULD include a Retry-After header field.¶

A request that fails as a whole does not need to be stored, because the Message has not been accepted for any recipient.¶

A sender retries a request as follows:¶

• If the sender has not received a response, or has received a response indicating a temporary failure of the whole request, it MAY send the identical request again, with the same Transfer Identifier and the same content. It signs each attempt anew. It SHOULD send the retry within 24 hours of the first attempt, so that the Receiving Server can recognize it. If the outcome of the earlier attempt is unknown, or if it was rejected with the "request-in-progress" problem type, the retry is sent to the same host as described in Section 4.2.¶

• For Envelope Recipients with the result "deferred", the sender sends a new request containing only those recipients, with a new Transfer Identifier.¶

• The sender MUST NOT retry a request, or deliver to an Envelope Recipient, after a permanent failure.¶

The content of a retry is compared with the content of the earlier request octet for octet. The sender MUST therefore retain the octets of the content of the request and MUST resend them unchanged. A Request Object that is serialized again, for example from fields that the sender has stored in a database, is different content, even if it represents the same JSON values, because the order of members, whitespace, and escaping can differ. Only the header fields of the request, including its signature, and its content coding can differ between attempts.¶

If a retry is nevertheless rejected with the "id-conflict" problem type, the earlier request has been processed, and the problem details object contains its results. A sender that receives this problem type in response to a retry of its own earlier request MUST treat these results as the results of the earlier request, and not as a failure of the whole request. In particular, it MUST NOT generate a delivery status notification reporting a failure for an Envelope Recipient that has the result "accepted". If the request was not a retry, the "id-conflict" problem type is a permanent failure.¶

A failure of the whole request is temporary if the "smtpStatus" member of the problem details object has the class 4. If the response does not contain a problem details object with an "smtpStatus" member, the status codes 408, 429, and 5xx, as well as connection failures, are temporary, and all other status codes are permanent.¶

The sender MUST honor a Retry-After header field [RFC9110] in the response. Otherwise, the intervals between retries and the time after which the sender gives up SHOULD follow the guidance of Section 4.5.4.1 of [RFC5321]. When the sender gives up, it generates a delivery status notification as described in Section 9.3. Before each retry, the sender repeats discovery if its cached results have expired.¶

6.5. Trace Information

A server that accepts responsibility for a Message, whether through transfer or submission, MUST prepend a Received header field to the Message. The field follows the syntax of Section 4.4 of [RFC5321] and has the following content:¶

• The "from" clause contains, for a transfer request, the Sending Domain, followed by the IP address of the sender of the request in the "TCP-info" part, for example from example.com (hmtp-out.example.com [192.0.2.25]). For a submission request, it contains the IP address of the Client as an address literal, followed by the same address literal in the "TCP-info" part, for example from [198.51.100.7] ([198.51.100.7]). For privacy reasons, a Submission Server MAY use the address literal [127.0.0.1] in both places instead of the IP address of the Client.¶

• The "by" clause contains the host name of the server.¶

• The "with" clause contains "HMTP" for a transfer request and "HMTPA" for a submission request (see Section 16.5).¶

• The "id" clause, if present, contains the "queueId" of the response.¶

• The "for" clause SHOULD be included only if the request has a single Envelope Recipient (see Section 15).¶

A server MAY also prepend other trace header fields, such as an Authentication-Results header field [RFC8601] that records the result of the verification described in Section 8.3.¶

Prepending header fields is the only modification that servers make to a Message during transfer. When the Message is represented as a Content Object, a server prepends header fields by adding an inline segment that contains them before the existing content; existing Content References can thus be passed on unchanged.¶

A Receiving Server SHOULD reject a Message that contains more Received header fields than a locally configured limit with the "loop-detected" problem type, as described in Section 6.3 of [RFC5321].¶

The following example shows a Received header field added by a Receiving Server:¶

Received: from example.com (hmtp-out.example.com [192.0.2.25])
        by mx.example.net with HMTP id 4Y7mKq2ZtR;
        Thu, 01 Jan 2026 12:00:01 +0000

7.1. Client Authentication

The "authentication" member of the Submission Endpoint Object (Section 4.3.1) lists the HTTP authentication schemes [RFC9110] accepted by the Submission Server for the submission and identities endpoints, using the scheme names from the "HTTP Authentication Scheme Registry". Scheme names are compared without regard to case. This document uses the following schemes:¶

basic:

The "Basic" scheme [RFC7617]. The user-id is the name of the account at the Submission Server. Servers that support this scheme SHOULD include the "charset" parameter with the value "UTF-8" in their challenges. This scheme allows existing SMTP AUTH credentials, including application-specific passwords, to be used with HMTP.¶

bearer:

The "Bearer" scheme [RFC6750]. Access tokens are obtained using OAuth 2.0 [RFC6749]. The Client discovers the authorization servers and the supported scopes from the OAuth 2.0 Protected Resource Metadata [RFC9728] of the Submission Server.¶

A Submission Server MUST support at least one of these schemes and SHOULD support "bearer". Clients SHOULD support both.¶

If a submission request or a request to the identities endpoint does not contain valid credentials, the server responds with the status code 401 (Unauthorized), a WWW-Authenticate header field containing a challenge for each accepted scheme, and a problem details object with the "authentication-required" problem type if no credentials were provided, or the "authentication-failed" problem type if the provided credentials are not valid. A challenge for the "Bearer" scheme SHOULD include the "resource_metadata" parameter defined in [RFC9728]. If a bearer token is valid but lacks a required scope, the server responds as specified in [RFC6750].¶

Servers SHOULD limit the rate of failed authentication attempts. Credentials for submission MUST NOT be sent to a transfer endpoint.¶

The following example shows a rejected submission request:¶

NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="hmtp", charset="UTF-8"
WWW-Authenticate: Bearer realm="hmtp", resource_metadata=\
  "https://hmtp.provider.example/.well-known/oauth-protected-resource"
Content-Type: application/problem+json

{
  "type": "urn:ietf:params:hmtp:error:authentication-required",
  "title": "Authentication required",
  "status": 401,
  "smtpStatus": "5.7.0",
  "smtpReply": 530
}

7.2. Authorization of Sender Addresses

A Submission Server determines the set of identities that the authenticated Client is authorized to use, as returned by the identities endpoint (Section 7.4). It MUST verify that each of the following addresses is covered by one of these identities:¶

• the Envelope Sender, unless it is empty;¶

• each address in the From header field of the Message;¶

• the address in the Sender header field of the Message, if present.¶

An empty Envelope Sender is permitted for Messages that require it, such as message disposition notifications [RFC8098].¶

If any of these addresses is not authorized, the Submission Server rejects the request with the "sender-not-authorized" problem type.¶

When the Submission Server acts as a Sending Server for the Message, it signs the transfer requests with a key of a Sending Domain that is aligned with the Envelope Sender (Section 8.4). A Submission Server therefore only includes in the identities of a Client addresses for which it can produce such signatures.¶

7.3. Message Validation and Modification

A Submission Server MUST verify that the Message conforms to [RFC5322], and in particular that it contains exactly one Date header field and exactly one From header field. It MUST reject a Message that does not conform with the "invalid-request" problem type, except as follows.¶

A Submission Server MAY add a Date header field or a Message-ID header field if either is missing, as permitted by Section 8 of [RFC6409]. Besides adding these fields, prepending trace header fields (Section 6.5), and prepending DKIM-Signature header fields [RFC6376], a Submission Server MUST NOT modify the Message. The Client is responsible for any other content of the Message, including the removal of Bcc header fields (Section 3.6.3 of [RFC5322]).¶

7.4. Identities

The identities endpoint returns the identities that the authenticated Client is authorized to use as originator addresses. Its URI is given by the "identities" member of the Submission Endpoint Object (Section 4.3.1). A Client sends an HTTP GET request to the endpoint, authenticated as described in Section 7.1. The server responds with the status code 200 (OK) and a JSON object with the media type "application/json" and the following member:¶

identities:

REQUIRED. An array of Identity Objects.¶

An Identity Object is a JSON object with the following members:¶

email:

REQUIRED. An address that the Client may use. If the local part of the address is the single character "*", as in "*@example.org", the Client may use any address in that domain, following the convention of Section 6 of [RFC8621].¶

name:

OPTIONAL. A display name associated with the address, which the Client can use in the From header field.¶

The server SHOULD include an ETag header field in the response and support conditional requests [RFC9110]. The response is specific to the authenticated account and MUST be marked accordingly for caches, for example with "Cache-Control: private".¶

GET /hmtp/v1/identities HTTP/1.1
Host: hmtp.provider.example
Authorization: Bearer mF_9.B5f-4.1JqM

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private
ETag: "a7c3"

{
  "identities": [
    {"email": "alice@example.com", "name": "Alice Example"},
    {"email": "*@sales.example.com"}
  ]
}

8.1. Signing Keys

A signing key is identified by a selector and a domain, as in DKIM (Section 3.1 of [RFC6376]). In a signature, the selector is carried in the "keyid" parameter and the domain in the "domain" parameter (Section 8.2). The public key is published as a DKIM key record (Section 3.6.1 of [RFC6376]) in a TXT record at the following name:¶

<selector>._domainkey.<domain>

The tags of the key record are interpreted as follows:¶

• "k" (key type): the value "ed25519" [RFC8463] corresponds to the signature algorithm "ed25519", and the value "rsa" corresponds to the signature algorithm "rsa-v1_5-sha256", both as defined in Section 3.3 of [RFC9421]. Records with other key types MUST NOT be used for HMTP.¶

• "p" (public key data): an empty value means that the key has been revoked. RSA keys MUST have a modulus of at least 2048 bits.¶

• "s" (service type): the record can be used for HMTP only if this tag is absent, or if its value includes "*" or "hmtp". The service type "hmtp" is registered in Section 16.3.¶

• "h" (acceptable hash algorithms): if present for a record of key type "rsa", the value MUST include "sha256".¶

• "t" (flags): if the flag "y" is present, the domain is testing the key. In accordance with the meaning of this flag in [RFC6376], a verifier MUST NOT treat a request signed with such a key differently from an unsigned request, and therefore rejects it.¶

A domain SHOULD use a dedicated selector for HMTP with the service type "hmtp" only. Such a key record is ignored by DKIM verifiers, which keeps keys for HMTP request signing separate from keys for DKIM message signing (see Section 14.4). A domain MAY instead use an existing DKIM key whose record permits all service types; this simplifies deployment but forgoes this separation.¶

Signers and verifiers MUST implement both "ed25519" and "rsa-v1_5-sha256". Signers SHOULD use "ed25519".¶

To replace a key, a domain publishes a new key record under a new selector, starts signing with the new key, and keeps the old key record published for at least the maximum lifetime of a signature plus the TTL of the old record before revoking or removing it.¶

8.2. Signature Construction

The Sending Server creates a signature as specified in Section 3.1 of [RFC9421], with the following requirements:¶

• The covered components MUST include "@method", "@target-uri", "content-type", and "content-digest". The Content-Digest header field MUST be present in the request, as required in Section 6.1.¶

• The signature parameters (Section 2.3 of [RFC9421]) MUST include "created", "expires", "keyid", "domain", "alg", and "tag":¶

  • "created" is the time at which the signature was created.¶

  • "expires" MUST NOT be more than 300 seconds after "created".¶

  • "keyid" is the selector of the key, with the syntax defined in [RFC6376], for example "hmtp2026".¶

  • "domain" is the Sending Domain, that is, the domain under which the key record is published, in A-label form, without a trailing dot, for example "example.com". This parameter is defined in Section 16.4. If the Envelope Sender is not empty, the Sending Domain MUST be aligned with it as described in Section 8.4.¶

  • "alg" is the signature algorithm that corresponds to the key type of the key record.¶

  • "tag" is the string "hmtp".¶

  The key record is located at the name formed from these two parameters as <keyid>._domainkey.<domain>. Because both parameters are covered by the signature, they cannot be changed without invalidating it.¶

• The signature label is not significant; "hmtp" is RECOMMENDED.¶

A request MAY carry more than one signature with the tag "hmtp", for example during a key rollover or a change of algorithm. Other signatures that the request carries are ignored for the purposes of HMTP.¶

The following example shows the signature-related header fields of a transfer request:¶

NOTE: '\' line wrapping per RFC 8792

Content-Digest: sha-256=:Cw2CRUGnwBRSPpU7qzJnP6Fk2zBdJ8u8mXh7sQe1zYI=:
Signature-Input: hmtp=("@method" "@target-uri" "content-type" \
  "content-digest");created=1767268800;expires=1767269100;\
  keyid="hmtp2026";domain="example.com";alg="ed25519";tag="hmtp"
Signature: hmtp=:3iXk1Lw3P1pZq9xH0M2eR8vUe6bJ4yD7nT5aC0fK2gS9\
  hV1mQ4wL8oE6rB3tY7uI0pA5sD2fG9hJ1kL3zX8cVQ==:

The corresponding key record, located at hmtp2026._domainkey.example.com, is:¶

hmtp2026._domainkey.example.com. 3600 IN TXT (
    "v=DKIM1; k=ed25519; s=hmtp; "
    "p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=" )

8.3. Verification Procedure

The Receiving Server verifies a transfer request as follows. Unless stated otherwise, a failure of any step causes the request to be rejected with the "signature-invalid" problem type.¶

1. It selects the signatures in the request whose "tag" parameter is "hmtp". If there is none, verification fails. If there are several, it processes each of them until one is verified successfully.¶

2. It verifies that the covered components and signature parameters meet the requirements of Section 8.2 and that it supports the algorithm given in "alg".¶

3. It verifies that "created" is not later than the current time and that "expires" is not earlier than the current time, both evaluated at the time the header section of the request was received, allowing for a clock skew of no more than 60 seconds, and that "expires" is not more than 300 seconds after "created".¶

4. It verifies that "keyid" is a selector with the syntax defined in [RFC6376] and that "domain" is a domain name in A-label form. The value of "domain" is the Sending Domain.¶

5. It queries DNS for TXT records at the name <keyid>._domainkey.<domain>. If the query fails temporarily, it rejects the request with the "key-unavailable" problem type, which is a temporary failure. If the name does not exist, or if the response does not contain exactly one valid key record, verification fails. DNS responses SHOULD be validated using DNSSEC [RFC4033] when available.¶

6. It verifies that the key record meets the requirements of Section 8.1 and that its key type corresponds to "alg".¶

7. It verifies the signature as specified in Section 3.2 of [RFC9421].¶

8. It verifies that the Content-Digest header field matches the content of the request as specified in [RFC9530]. If it does not, it rejects the request with the "digest-mismatch" problem type.¶

9. It verifies the alignment of the Envelope Sender with the Sending Domain as described in Section 8.4.¶

If verification fails, the response MAY include an Accept-Signature header field as described in [RFC9421].¶

A Receiving Server that terminates TLS in a reverse proxy MUST ensure that the covered components reach the verifier unchanged, or perform verification in the proxy.¶

8.4. Sender Alignment

The domain of a non-empty Envelope Sender is aligned with the Sending Domain if it is equal to the Sending Domain or is a subdomain of it. For example, the Envelope Sender "bounces@mail.example.com" is aligned with the Sending Domain "example.com", but not with the Sending Domain "example.org".¶

A Receiving Server MUST reject a transfer request in which the Envelope Sender is not empty and is not aligned with the Sending Domain, with the "sender-not-aligned" problem type, unless the Receiving Server has a local agreement that authorizes the Sending Domain to relay Messages for other domains. Such agreements are used, for example, with inbound filtering services and backup servers that relay Messages to the Receiving Server on behalf of the recipient domain (see Section 10.3).¶

If the Envelope Sender is empty, any Sending Domain is acceptable, and the Receiving Server applies its local policy based on the Sending Domain.¶

Alignment authenticates the Envelope Sender's domain, not the author of the Message. The domains in the From header field continue to be authenticated by DKIM and DMARC at the message level.¶

A server that forwards Messages to another domain, such as a mailing list or a forwarding service, uses an Envelope Sender in a domain for which it can produce aligned signatures. As in SMTP, such a server typically rewrites the Envelope Sender so that delivery status notifications are returned to it.¶

8.5. Third-Party Senders

A domain can authorize a third party, such as an email service provider, to send Messages with Envelope Senders in its domain. Because HMTP keys are published in the same way as DKIM keys, the same delegation methods apply:¶

Delegation of a selector:

The domain publishes a CNAME record at a selector name that points to a key record maintained by the provider, for example:¶

esp1._domainkey.example.com. 3600 IN CNAME (
    example-com.keys.esp.example. )

¶

The provider signs with "keyid" set to "esp1" and "domain" set to "example.com", which is the Sending Domain. The domain can revoke the authorization at any time by removing the CNAME record.¶

Publication of a provider key:

The domain publishes, under a selector of its own, a public key whose private key is held by the provider.¶

Provider domain:

The provider uses Envelope Senders in its own domain and signs as that domain. The reputation of the Sending Domain then accrues to the provider rather than to its customer.¶

9.1. Problem Details

When a request fails as a whole, the server responds with a 4xx or 5xx status code and a problem details object [RFC9457] with the media type "application/problem+json". When the Message is not accepted for an individual Envelope Recipient, the reason is given as a problem details object in the "problem" member of the Recipient Result Object (Section 6.3); in that case, the "status" member MAY be omitted and is ignored if present.¶

Problem types defined for HMTP have URIs of the form urn:ietf:params:hmtp:error:<name> and are registered as described in Section 16.7.4. Servers MAY use other problem type URIs as permitted by [RFC9457].¶

This document defines the following extension members of problem details objects:¶

smtpStatus:

REQUIRED in problem details objects sent by HMTP servers. An enhanced mail system status code [RFC3463] in the form "class.subject.detail". The class MUST be 4 (persistent transient failure) or 5 (permanent failure). In a response, the class determines whether the failure is temporary or permanent, also for problem types that are unknown to the recipient of the problem details object. In a delivery status report, the "action" member determines whether delivery has failed, and the class 4 can also describe a failure after which the reporting server has given up (Section 9.4.2).¶

smtpReply:

OPTIONAL. An SMTP reply code [RFC5321] that corresponds to the failure. It is used when the failure is reported over SMTP, for example by a gateway (Section 10.3) or in a delivery status notification (Section 9.3). If it is absent, the reply code from Table 2 is used for registered problem types, and 451 or 550 otherwise, depending on the class of "smtpStatus".¶

The "detail" member SHOULD be suitable for inclusion in a delivery status notification sent to the Envelope Sender. The language of human-readable members can be indicated with the Content-Language header field.¶

Responses with the status codes 429 (Too Many Requests) [RFC6585] and 503 (Service Unavailable) SHOULD include a Retry-After header field.¶

The following example shows a request that was rejected as a whole:¶

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en

{
  "type": "urn:ietf:params:hmtp:error:sender-not-aligned",
  "title": "Envelope Sender not aligned with Sending Domain",
  "status": 403,
  "detail": "example.org is not aligned with example.com.",
  "smtpStatus": "5.7.1",
  "smtpReply": 550
}

9.2. Mapping to SMTP Status Codes

Table 2 lists the problem types defined by this document, whether they apply to a whole request ("Request"), to an individual Envelope Recipient ("Recipient"), or to both, and the HTTP status code, enhanced status code, and SMTP reply code to be used with them. Where two codes are given, the first is used for a temporary and the second for a permanent failure.¶

The meaning of each problem type is as follows:¶

invalid-request:

The request content is not a valid Request Object, the Message does not conform to [RFC5322], or another requirement of this document is not met.¶

unsupported-capability:

The request lists a capability that the server does not support.¶

id-conflict:

The Transfer Identifier has already been used for a request with different content (Section 6.4). The problem details object contains the results of the earlier request.¶

request-in-progress:

A request with the same Transfer Identifier in the same scope is still being processed (Section 6.4). The sender retries the request later at the same host (Section 4.2).¶

signature-invalid:

The request has no valid HMTP signature (Section 8.3).¶

key-unavailable:

The key record could not be retrieved because of a temporary DNS failure.¶

digest-mismatch:

The Content-Digest header field does not match the content of the request.¶

sender-not-aligned:

The Envelope Sender is not aligned with the Sending Domain (Section 8.4).¶

authentication-required:

A submission request or identities request carries no credentials.¶

authentication-failed:

The credentials of a submission request or identities request are not valid. This problem type corresponds to the SMTP enhanced status code 5.7.8 defined in [RFC4954].¶

sender-not-authorized:

The Client is not authorized to use an originator address of the Message (Section 7.2).¶

request-too-large:

The content of the request exceeds the "maxRequestSize" limit. The sender can transfer part of the Message by reference instead.¶

message-too-large:

The size of the Message exceeds a limit of the server or of a recipient mailbox.¶

too-many-recipients:

The number of Envelope Recipients exceeds the "maxRecipients" limit. The sender MUST NOT repeat the request unchanged; it splits the Envelope Recipients into several requests with new Transfer Identifiers.¶

rate-limited:

The sender has exceeded a rate limit of the server.¶

server-unavailable:

The server is temporarily unable to process requests.¶

content-unavailable:

Referenced content could not be retrieved (Section 5.2.1).¶

content-mismatch:

The size or digest of referenced content does not match its Content Reference. This problem type corresponds to the enhanced status code for message integrity failures defined in [RFC3463].¶

loop-detected:

The Message has passed through too many servers (Section 6.5).¶

policy-rejected:

The Message was rejected by the local policy of the server, for example on the basis of the reputation of the Sending Domain or the content of the Message.¶

unknown-recipient:

The recipient mailbox does not exist.¶

invalid-address:

The address of the Envelope Recipient is syntactically invalid (Section 5.1). Only this Envelope Recipient is rejected; the other Envelope Recipients of the request are not affected.¶

domain-not-served:

The server does not accept Messages for the domain of the Envelope Recipient and has no agreement to relay them, or, for a delivery status report, does not serve the domain of the "envelopeSender" member (Section 9.4.3).¶

mailbox-disabled:

The recipient mailbox exists but does not accept Messages.¶

mailbox-full:

The recipient mailbox has exceeded its storage limit.¶

routing-failed:

The server was unable to route the Message toward the recipient, for example because the recipient domain supports neither HMTP nor, for a server that supports fallback, SMTP.¶

delivery-expired:

The server has given up retrying the delivery to the recipient (Section 6.4), and no more specific problem type is available. It is used in delivery status reports and DSN messages with the action "failed" (Section 9.3) and corresponds to the enhanced status code for an expired delivery time defined in [RFC3463].¶

conversion-required:

Delivery requires a conversion of the Message that the server does not perform, for example because an SMTP server used for fallback does not support an extension that the Message requires, or because the request uses a must-understand capability that cannot be forwarded over SMTP (Section 10.1).¶

tls-required:

The Envelope requests REQUIRETLS, and the requirement cannot be satisfied on the path to the recipient. The enhanced status code is defined in [RFC8689].¶

9.3. Delivery Status Notifications

When a Message cannot be delivered after it has been accepted, or when a delivery status notification (DSN) is requested on success or delay, a DSN is generated as specified in [RFC3461] and [RFC3464]. The DSN parameters of the Envelope (Section 5.1) have the same semantics as the corresponding SMTP parameters. In particular:¶

• A Sending Server generates a DSN for an Envelope Recipient that was rejected by the Receiving Server or for which it has given up retrying (Section 6.4). The Receiving Server does not generate a DSN for a recipient that it rejected in its response.¶

• A Receiving Server generates a DSN for an Envelope Recipient for which it accepted the Message but later failed to deliver it, including when the retrieval of referenced content fails after the response (Section 5.2.1).¶

• A DSN is sent to the Envelope Sender of the original Message, with an empty Envelope Sender. No DSN is generated for a Message whose Envelope Sender is empty.¶

• A server that relays a Message passes the DSN parameters on to the next hop, whether that hop uses HMTP or SMTP.¶

• If the domain of the Envelope Sender supports delivery status reports, the information is sent as a report instead of a DSN message, as described in Section 9.4. All HMTP servers MUST continue to accept DSN messages, which are ordinary Messages.¶

The fields of the DSN are filled in as follows:¶

• The "Reporting-MTA" field contains the host name of the reporting server with the type "dns".¶

• The "Remote-MTA" field, if present, contains the TargetName of the HMTP Endpoint or, after a fallback to SMTP (Section 10), the host name of the SMTP server, with the type "dns".¶

• The "Status" field contains the enhanced status code from the "smtpStatus" member of the problem details object. A server that gives up after retries uses the "failed" action together with the enhanced status code of the last temporary failure, which has the class 4, or, if no more specific code is available, the code 4.4.7 of the "delivery-expired" problem type. As described in [RFC3463], the class 4 then denotes a persistent transient failure that has caused the abandonment of delivery attempts.¶

• The "Diagnostic-Code" field uses the diagnostic type "smtp" and contains the SMTP reply code, the enhanced status code, and the "detail" member of the problem details object, if any.¶

• The "Original-Recipient" and "Original-Envelope-Id" fields are derived from the "orcpt" and "envid" members of the Envelope.¶

If the Envelope requests the return of the full Message ("ret" is "full") and the Message is very large, the DSN MAY contain only the header section of the Message.¶

DSNs are ordinary Messages and are transferred using HMTP or SMTP like any other Message.¶

Date: Thu, 01 Jan 2026 12:00:03 +0000
From: Mail Delivery System <mailer-daemon@hmtp.provider.example>
To: alice@example.com
Subject: Delivery Status Notification (Failure)
Message-ID: <dsn.Xk4mP9qR2sT7@hmtp.provider.example>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
        boundary="dsn-b1"

--dsn-b1
Content-Type: text/plain; charset=us-ascii

Your message could not be delivered to the following recipient:

  dave@example.org
  550 5.1.1 Recipient address rejected

--dsn-b1
Content-Type: message/delivery-status

Reporting-MTA: dns; hmtp.provider.example
Original-Envelope-Id: QQ314159
Arrival-Date: Thu, 01 Jan 2026 11:59:58 +0000

Original-Recipient: rfc822;dave@example.org
Final-Recipient: rfc822;dave@example.org
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.org
Diagnostic-Code: smtp; 550 5.1.1 <dave@example.org>: Recipient
 address rejected

--dsn-b1
Content-Type: text/rfc822-headers

Received: from [198.51.100.7] ([198.51.100.7])
        by hmtp.provider.example with HMTPA id S-20260101-0043;
        Thu, 01 Jan 2026 11:59:58 +0000
Date: Thu, 01 Jan 2026 11:59:57 +0000
From: Alice <alice@example.com>
To: Dave <dave@example.org>, Erin <erin@example.org>
Subject: Quarterly report
Message-ID: <20260101115957.4f2a@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

--dsn-b1--

{
  "id": "nH8sK2dL5fQ9wE3rT6yU1i",
  "from": "",
  "to": [{"address": "alice@example.com"}]
}

9.4. Delivery Status Reports

DSN messages are designed to be read by people and are difficult to process automatically, because the information has to be extracted from a multipart Message. When both the reporting server and the domain of the Envelope Sender support HMTP, the same information can instead be sent as a delivery status report: a JSON document that is transferred directly to the "reports" endpoint of that domain.¶

Delivery status reports are OPTIONAL. A server that does not support them sends DSN messages as described in Section 9.3, and every HMTP server MUST continue to accept DSN messages. A report carries the same information as a DSN message and is subject to the same rules on when it is generated: a report is sent only where [RFC3461] and Section 9.3 call for a DSN.¶

NOTE: '\' line wrapping per RFC 8792

POST /hmtp/v1/reports HTTP/1.1
Host: hmtp.provider.example
Content-Type: application/json
Content-Digest: sha-256=:...:
Signature-Input: hmtp=("@method" "@target-uri" "content-type" \
  "content-digest");created=1767269400;expires=1767269700;\
  keyid="hmtp2026";domain="example.net";alg="ed25519";tag="hmtp"
Signature: hmtp=:...:

{
  "id": "Rp7xK1mN4qT8vZ2cW5bH9d",
  "envelopeSender": "bounces+7f3a@example.com",
  "reportingServer": "mx.example.net",
  "transferId": "3q2-7wEXAMPLEd9Kc1fQ0g",
  "transferDomain": "example.com",
  "messageId": "<20260101115500.9c1d@example.com>",
  "arrivalDate": "2026-01-01T12:00:01Z",
  "recipients": [
    {
      "finalRecipient": "bob@example.net",
      "action": "failed",
      "problem": {
        "type": "urn:ietf:params:hmtp:error:mailbox-full",
        "title": "Mailbox full",
        "detail": "The mailbox bob@example.net is over quota.",
        "smtpStatus": "5.2.2",
        "smtpReply": 552
      },
      "lastAttempt": "2026-01-01T12:10:00Z"
    }
  ]
}

HTTP/1.1 204 No Content

10.1. When to Fall Back

The rules in this section apply when the next hop for an Envelope Recipient is determined by discovery. Forwarding a Message to a next hop that is determined by local configuration is not a fallback and is described in Section 3.3.¶

A Sending Server that supports SMTP MAY deliver a Message to an Envelope Recipient using SMTP only if all of the following conditions hold:¶

1. Discovery (Section 4) has determined that the domain of the Envelope Recipient does not support HMTP.¶

2. The Sending Server has no unexpired downgrade policy with the mode "enforce" for that domain (Section 10.2).¶

3. Every must-understand capability that the request uses (Section 5.4) can be forwarded over SMTP: its specification defines how the capability is handled when the Message is forwarded over SMTP, for example by mapping it to an SMTP extension or by completing its function before the Message is forwarded.¶

If the first two conditions hold but the third does not, the Message can be delivered neither over HMTP nor over SMTP. The delivery to the affected Envelope Recipients fails with the "conversion-required" problem type, and the Sending Server generates a delivery status notification (Section 9.3). The third condition also applies when the next hop is determined by local configuration (Section 3.3).¶

A Sending Server MUST NOT fall back to SMTP after a temporary failure of discovery or of an HMTP request, such as a DNS timeout, a connection or TLS failure, or a response with a 5xx or 429 status code. It retries the delivery using HMTP as described in Section 6.4. A Sending Server MUST NOT fall back to SMTP after an HMTP request has been rejected permanently.¶

When it falls back, the Sending Server delivers the Message as specified in [RFC5321], with the following requirements:¶

• It locates the SMTP server using MX records as specified in Section 5.1 of [RFC5321]. If the domain publishes a null MX record [RFC7505], the Message cannot be delivered.¶

• It retrieves all referenced content and reconstructs the Message before the transfer, because SMTP cannot carry Content References.¶

• It transmits the Envelope using the parameters of the corresponding SMTP extensions: the BODY parameter for "body" [RFC6152] [RFC3030], the SMTPUTF8 parameter for "smtpUtf8" [RFC6531], the RET, ENVID, NOTIFY, and ORCPT parameters for the DSN parameters [RFC3461], and the REQUIRETLS parameter for "requireTls" [RFC8689]. Values are encoded as "xtext" where [RFC3461] requires it.¶

• It MUST NOT convert the Message. If the SMTP server does not support an extension that the Message requires, such as 8BITMIME, BINARYMIME, or SMTPUTF8, the delivery to the affected Envelope Recipients fails with the "conversion-required" problem type. If "requireTls" is true and the requirements of [RFC8689] cannot be met, the delivery fails with the "tls-required" problem type.¶

• Members of capabilities that are not must-understand are not transferred over SMTP. If a must-understand capability is mapped to an SMTP extension that the SMTP server does not support, the delivery fails with the "conversion-required" problem type, as for other extensions that the Message requires.¶

• If the SMTP server does not support the DSN extension, the Sending Server behaves as specified in [RFC3461] for relaying to a server that does not support it.¶

• Where a failure reported by the SMTP server needs to be expressed as a problem details object, for example in a delivery status report, the Sending Server constructs it as described in Section 9.2.1.¶

• It SHOULD use STARTTLS [RFC3207] and SHOULD apply MTA-STS [RFC8461] or DANE [RFC7672] when the domain publishes them.¶

{
  "id": "Xk4mP9qR2sT7vW1yZ3bC5d",
  "from": "alice@example.com",
  "to": [
    {
      "address": "dave@example.org",
      "dsn": {
        "notify": ["failure", "delay"],
        "orcpt": "rfc822;dave@example.org"
      }
    },
    {"address": "erin@example.org"}
  ],
  "dsn": {"ret": "hdrs", "envid": "QQ314159"},
  "body": "8bitmime"
}

; _hmtp.example.org. IN SVCB  ->  NXDOMAIN
example.org.  3600 IN MX 10 mx.example.org.

NOTE: '\' line wrapping per RFC 8792

S: 220 mx.example.org ESMTP
C: EHLO hmtp.provider.example
S: 250-mx.example.org
S: 250-8BITMIME
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
   (TLS handshake; the certificate of mx.example.org is validated)
C: EHLO hmtp.provider.example
S: 250-mx.example.org
S: 250-8BITMIME
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<alice@example.com> BODY=8BITMIME RET=HDRS \
   ENVID=QQ314159
S: 250 2.1.0 Sender OK
C: RCPT TO:<dave@example.org> NOTIFY=FAILURE,DELAY \
   ORCPT=rfc822;dave@example.org
S: 550 5.1.1 <dave@example.org>: Recipient address rejected
C: RCPT TO:<erin@example.org>
S: 250 2.1.5 Recipient OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Received: from [198.51.100.7] ([198.51.100.7])
C:         by hmtp.provider.example with HMTPA id S-20260101-0043;
C:         Thu, 01 Jan 2026 11:59:58 +0000
C: Date: Thu, 01 Jan 2026 11:59:57 +0000
C: From: Alice <alice@example.com>
C: To: Dave <dave@example.org>, Erin <erin@example.org>
C: Subject: Quarterly report
C: Message-ID: <20260101115957.4f2a@example.com>
C: MIME-Version: 1.0
C: Content-Type: text/plain; charset=utf-8
C: Content-Transfer-Encoding: 8bit
C:
C: (body of the Message)
C: .
S: 250 2.0.0 Ok: queued as 7HG2Lk
C: QUIT
S: 221 2.0.0 Bye

10.2. Downgrade Policy

Without DNSSEC, an attacker who can modify DNS responses can remove the SVCB records of a domain and thereby cause Sending Servers to fall back to SMTP. A downgrade policy allows a domain to instruct Sending Servers that have once reached it over HMTP not to fall back to SMTP, in a way similar to HTTP Strict Transport Security [RFC6797] and MTA-STS [RFC8461].¶

The policy is expressed in the "policy" member of the Capabilities Document (Section 4.3), which is a JSON object with the following members:¶

mode:

REQUIRED. The string "enforce" or "none".¶

maxAge:

REQUIRED. The number of seconds for which a Sending Server applies the policy, as a non-negative integer. The value MUST NOT exceed 31557600 (one year). Sending Servers MUST treat larger values as 31557600.¶

Whenever a Sending Server has located a host through discovery for a domain and has successfully retrieved the Capabilities Document of the host, it updates its policy state for that domain as follows:¶

• If the document contains a policy with the mode "enforce", the Sending Server records that the policy applies to the domain until "maxAge" seconds after the time of retrieval.¶

• If the document contains a policy with the mode "none", or no policy, the Sending Server removes any recorded policy for the domain.¶

While an unexpired policy with the mode "enforce" is recorded for a domain, the Sending Server MUST treat a discovery result indicating that the domain does not support HMTP as a temporary failure and MUST NOT fall back to SMTP. It retries delivery as described in Section 6.4 and, when it gives up, generates a DSN.¶

Because the Capabilities Document belongs to a host, its policy applies to all domains that use the host. A domain that intends to stop using HMTP first publishes, through its host, a policy with the mode "none" or a "maxAge" of 0, and keeps its SVCB records published for at least the previously advertised "maxAge" before removing them.¶

A Sending Server that does not support SMTP fallback does not need to record policies.¶

10.3. SMTP to HMTP Gateways

An SMTP server can relay Messages that it receives over SMTP to an HMTP Endpoint. Such a gateway acts as a Sending Server and constructs the Envelope from the SMTP transaction:¶

• "from" and the "address" members of the Recipient Objects are taken from the MAIL FROM and RCPT TO commands;¶

• "body", "smtpUtf8", and "requireTls" are taken from the BODY, SMTPUTF8, and REQUIRETLS parameters;¶

• the DSN parameters are taken from the RET, ENVID, NOTIFY, and ORCPT parameters, after decoding "xtext".¶

The Message is the message received over SMTP, including the Received header field that the gateway prepends as an SMTP server. A gateway SHOULD record the results of the authentication checks it performed on the SMTP transaction, such as SPF, DKIM, and DMARC, in an Authentication-Results header field [RFC8601].¶

A gateway signs its requests with a key of its own domain. For outbound Messages of the domain that operates the gateway, the Envelope Sender is aligned as usual. A gateway that relays Messages from other domains, such as an inbound filtering service or a backup server, cannot produce aligned signatures for them. It is used under a local agreement with the Receiving Server, as described in Section 8.4.¶

A gateway MAY relay the Message over HMTP before it replies to the SMTP DATA or BDAT command. In that case, it translates the result of the HMTP request into the SMTP reply, using the "smtpReply" and "smtpStatus" members of the problem details object, and the mapping in Table 2. Otherwise, it accepts the Message, relays it later, and reports failures through DSNs.¶

12.1. Information Available to Receivers

When it evaluates a transfer request, a Receiving Server can use the following information in addition to the content of the Message:¶

• the Sending Domain, authenticated by the signature of the request (Section 8.3), and its alignment with the Envelope Sender (Section 8.4);¶

• the selector of the signing key, which a domain can use to separate different streams of mail, such as transactional and bulk mail, or the mail of different customers of a provider;¶

• the IP address from which the request was received, which identifies an intermediary rather than the Sending Server when the request passes through a proxy;¶

• the results of the DKIM and DMARC evaluation of the Message;¶

• the Envelope, including the Envelope Sender and the number of Envelope Recipients.¶

SPF [RFC7208] authorizes hosts to use a domain in SMTP sessions and is not used for HMTP requests, whose sender is authenticated by the signature. Because a Sending Server can operate behind proxies and content delivery networks, Receiving Servers SHOULD NOT evaluate SPF against the IP address of an HMTP request. SPF continues to apply to SMTP hops.¶

12.2. Reputation of Sending Domains

A valid signature establishes which domain is responsible for a request. It does not indicate that the request is legitimate. Domains can be registered at low cost, so an attacker can sign requests with newly registered domains. Receiving Servers SHOULD therefore treat Sending Domains without history with caution, for example by applying lower rate limits, or by deferring part of their mail with the "rate-limited" or "policy-rejected" problem types and a temporary enhanced status code.¶

A Sending Domain is responsible for all Envelope Senders that are aligned with it (Section 8.4), including those in its subdomains, and the reputation earned with such mail applies to the Sending Domain. When a provider signs with its own domain on behalf of its customers (Section 8.5), the reputation accrues to the provider, which is then responsible for abuse by its customers. When a customer delegates a selector to a provider, the reputation accrues to the domain of the customer. The restrictions on signatures of registry suffixes described in Section 14 also apply to reputation.¶

12.3. Rejection and Backscatter

Because the Receiving Server reports the result for each Envelope Recipient in its response (Section 6.3), it can reject an unwanted Message during the request. A Receiving Server SHOULD reject a Message that it does not intend to deliver in its response, rather than accepting it and generating a delivery status notification later. Later notifications create additional traffic and, for Messages that reached the Receiving Server through a relay, can be sent to an Envelope Sender that did not send the Message.¶

The "detail" member of a problem details object for a policy rejection SHOULD allow a legitimate sender to understand the reason for the rejection, but does not need to reveal the internal rules of the filtering system.¶

12.4. Abuse of Content References

An attacker can include Content References to URIs of a third party in many requests and thereby cause Receiving Servers to send retrieval requests to that party. The checks of size and digest prevent such content from being delivered, but not the retrieval requests themselves. Receiving Servers SHOULD limit the number and rate of retrievals per Sending Domain and per target host. Because each request is signed, such abuse can be attributed to the Sending Domain.¶

Content References can also be used to deliver malicious content. Because a Message is reconstructed completely before it is delivered (Section 5.2.1), Receiving Servers can apply their content checks to referenced content in the same way as to inline content.¶

12.5. Abuse of Submission

Compromised Client credentials are a common source of abusive mail. Submission Servers SHOULD apply rate limits per account, SHOULD monitor accounts for unusual sending patterns, and SHOULD support bearer tokens with a limited lifetime (Section 7.1). Because a Submission Server signs the Messages that it relays with keys of its Sending Domain, abuse by its users affects the reputation of that domain.¶

12.6. Abuse Reports

Complaints about abusive Messages, such as reports in the Abuse Reporting Format [RFC5965], are sent as ordinary Messages and are not affected by this document. Delivery status reports (Section 9.4) are not intended for complaints. A structured endpoint for abuse reports could be defined as a capability (Section 5.4).¶

14.1. Transport Security

All HMTP requests, including the retrieval of the Capabilities Document and of referenced content, use TLS with certificate validation. No plaintext mode exists. TLS protects the confidentiality and integrity of each hop, but not of the Message end to end: every server that handles a Message has access to its content, as in SMTP. End-to-end protection requires OpenPGP or S/MIME.¶

14.2. DNS and Downgrade Attacks

The TLS certificate of the HMTP Endpoint is validated against the TargetName obtained from DNS. If DNS responses are not authenticated, an attacker who can modify them can redirect HMTP requests to a host under its control, for which it can obtain a valid certificate, or can remove the SVCB records so that a Sending Server falls back to SMTP. This is the same exposure that MX records have without DNSSEC. Domains SHOULD sign their zones with DNSSEC, and Sending Servers SHOULD validate DNS responses.¶

The downgrade policy (Section 10.2) protects against the removal of SVCB records after a Sending Server has reached a domain once, but not on first contact and not against redirection to another host. The rule that temporary failures never cause a fallback to SMTP (Section 10.1) prevents an attacker from forcing a downgrade by blocking HTTPS connections.¶

14.3. Signatures and Replay

Signatures cover the method, the target URI, the media type, and the digest of the content, and are therefore bound to the Envelope, the Message, and the Receiving Server. A captured request cannot be replayed to another Receiving Server, because the target URI differs. A replay to the same Receiving Server is limited by the validity period of the signature, which is at most 300 seconds, and within that period by the Transfer Identifier, which causes the Receiving Server to return the stored response instead of delivering the Message again. Verifiers need reasonably accurate clocks.¶

14.4. Key Management

The security of HMTP depends on the protection of the private keys of the Sending Domain. A compromised key allows an attacker to send requests on behalf of the domain until the key record is revoked. Domains SHOULD rotate keys regularly as described in Section 8.1.¶

When a key is shared between DKIM message signing and HMTP request signing, a compromise affects both uses. The data that HMTP signs, the signature base defined by [RFC9421], has a different structure from the data signed by DKIM, which makes it difficult to use a signature from one protocol in the other. Nevertheless, keys dedicated to HMTP with the service type "hmtp" are RECOMMENDED. RSA keys shorter than 2048 bits, which [RFC8301] still permits for DKIM, are not permitted for HMTP.¶

14.5. Sender Alignment

Alignment permits a domain to sign for its subdomains. A Receiving Server SHOULD NOT accept signatures of domains that are registry suffixes, such as top-level domains, as authenticating the Envelope Sender, because such domains do not operate mail services for the domains registered under them.¶

An HMTP signature authenticates the Sending Domain and its alignment with the Envelope Sender. It does not authenticate the author of the Message. Receiving Servers MUST NOT present the Sending Domain to users as the author of the Message.¶

14.6. Content References

Retrieving referenced content causes the Receiving Server to send requests to URIs chosen by the sender. A Receiving Server MUST NOT retrieve content from IP addresses that are not globally routable, such as loopback, private, and link-local addresses, unless it is explicitly configured to do so, in order to prevent attacks on internal services. It SHOULD apply limits to the number of redirections, the duration of retrievals, and the number of concurrent retrievals per Sending Domain.¶

The integrity of referenced content is protected by its digest, which is covered by the signature of the request. The size of referenced content is declared in advance, so a Receiving Server can reject oversized Messages before retrieving them and can stop a retrieval that exceeds the declared size.¶

URIs of referenced content act as bearer capabilities: anyone who learns them can retrieve the content until it is removed. Senders SHOULD use URIs that contain sufficient randomness to be unguessable, SHOULD remove content after its "expires" timestamp, and MAY require signed retrieval requests (Section 8.2.1). Receiving Servers MUST NOT disclose these URIs to recipients of the Message.¶

14.7. Denial of Service

HMTP servers are exposed to resource exhaustion through large requests, many concurrent requests, slow transmission of requests, and Messages with many segments or recipients. Servers SHOULD advertise and enforce limits (Section 4.3), SHOULD apply rate limits per Sending Domain and per IP address, and MAY verify the signature before receiving the content of the request.¶

14.8. Client Authentication

Credentials used with the "basic" scheme are passwords and are subject to guessing and phishing. Servers SHOULD support bearer tokens, SHOULD support application-specific passwords for the "basic" scheme, and SHOULD limit the rate of failed attempts. Bearer tokens SHOULD be restricted to the Submission Server as their audience, and Clients MUST NOT send them to other servers.¶

A Submission Server MUST authenticate every submission request and MUST verify the sender addresses (Section 7.2). A transfer endpoint MUST NOT accept Messages for domains it does not serve, except under a local relay agreement. Otherwise, the server would act as an open relay.¶

14.9. Delivery Status Reports

A report is authenticated by the domain of the reporting server, but that domain is not necessarily related to the Envelope Sender or to the Envelope Recipients, because a Message can pass through servers of several domains. An attacker can therefore send forged reports about Messages that it did not handle, for example to cause a sender to remove a valid address from a mailing list. Receivers of reports SHOULD accept only reports that they can correlate with a Message they sent (Section 9.4.3). Senders that act on reports automatically SHOULD use unguessable values of "envid", so that only servers that have handled the Message can produce a matching report. The same considerations apply to DSN messages, which are not authenticated at all; reports are an improvement in that they identify the reporting domain.¶

14.10. Transfer Identifiers

Transfer Identifiers are scoped to the Sending Domain or to the authenticated account, so a third party cannot cause a legitimate request to be suppressed as a duplicate without being able to sign requests for the same scope. For the same reason, the results of an earlier request that accompany the "id-conflict" problem type (Section 6.4) are disclosed only to a sender in the same scope. Within a scope that is shared by several senders, such as a domain and its email service providers, the randomness of Transfer Identifiers also prevents one sender from predicting the identifiers of another. The limit on the length of Transfer Identifiers bounds the storage that a Receiving Server needs for them.¶

Transfer Identifiers prevent duplicate delivery only among hosts that share the stored Transfer Identifiers (Section 4.2). If a host accepts a Message and becomes unreachable before the Sending Server receives the response, the Sending Server retries the request at another host of the domain. A host that does not share the stored Transfer Identifiers, such as a backup host operated by a third party, accepts the retry as a new request and relays the Message to the domain with its own signature, that is, with a Transfer Identifier in the scope of its own Sending Domain. The Message is then delivered twice. This risk is comparable to the duplication that a lost reply to the DATA command causes in SMTP. Domains that use such backup hosts accept this risk. Final delivery agents can reduce its impact, for example by detecting duplicate Message-ID header fields.¶

16.1. Underscored and Globally Scoped DNS Node Name

IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]:¶

16.2. Well-Known URI

IANA is requested to add the following entry to the "Well-Known URIs" registry [RFC8615]:¶

URI Suffix:

hmtp¶

Change Controller:

IETF¶

Specification Document(s):

Section 4.3 of RFC XXXX¶

Status:

permanent¶

Related Information:

None¶

16.3. DKIM Service Type

IANA is requested to add the following entry to the "DKIM Service Types" registry [RFC6376]:¶

16.4. HTTP Signature Metadata Parameter

IANA is requested to add the following entry to the "HTTP Signature Metadata Parameters" registry [RFC9421]:¶

Name:

domain¶

Description:

The domain name under which the key identified by the "keyid" parameter is published, as a DKIM key record, at the name <keyid>._domainkey.<domain>.¶

Reference:

Section 8.2 of RFC XXXX¶

16.5. Mail Transmission Types

IANA is requested to add the following entries to the "Mail Transmission Types" registry in the "Mail Parameters" registry group:¶

16.6. URN Sub-namespace

IANA is requested to register the following entry in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry [RFC3553]:¶

Registry name:

hmtp¶

Specification:

RFC XXXX¶

Repository:

The "HTTP Mail Transfer Protocol (HMTP)" registry group defined in this document. URNs of the form urn:ietf:params:hmtp:error:<name> identify problem types registered in the "HMTP Problem Types" registry.¶

Index value:

The name of a problem type, as registered in the "HMTP Problem Types" registry.¶

16.7. HMTP Registry Group

IANA is requested to create a new registry group titled "HTTP Mail Transfer Protocol (HMTP)" containing the registries defined in the following subsections. For all of them, the registration policy is Specification Required [RFC8126]. The designated experts verify that the specification is publicly available, that the registered name does not conflict with an existing entry, and that the specification is consistent with the extension rules of Section 5.4.¶

17.1. Normative References

[RFC2045]

Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/rfc/rfc2045>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3030]

Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, DOI 10.17487/RFC3030, December 2000, <https://www.rfc-editor.org/rfc/rfc3030>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC3461]

Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, <https://www.rfc-editor.org/rfc/rfc3461>.

[RFC3463]

Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, DOI 10.17487/RFC3463, January 2003, <https://www.rfc-editor.org/rfc/rfc3463>.

[RFC3464]

Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, <https://www.rfc-editor.org/rfc/rfc3464>.

[RFC3553]

Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/rfc/rfc3553>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC4033]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/rfc/rfc4033>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5321]

Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/rfc/rfc5321>.

[RFC5322]

Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/rfc/rfc5322>.

[RFC5598]

Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <https://www.rfc-editor.org/rfc/rfc5598>.

[RFC5890]

Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/rfc/rfc5890>.

[RFC6152]

Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, DOI 10.17487/RFC6152, March 2011, <https://www.rfc-editor.org/rfc/rfc6152>.

[RFC6376]

Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/rfc/rfc6376>.

[RFC6409]

Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <https://www.rfc-editor.org/rfc/rfc6409>.

[RFC6531]

Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, <https://www.rfc-editor.org/rfc/rfc6531>.

[RFC6532]

Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/rfc/rfc6532>.

[RFC6585]

Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, <https://www.rfc-editor.org/rfc/rfc6585>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

[RFC7493]

Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/rfc/rfc7493>.

[RFC7617]

Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <https://www.rfc-editor.org/rfc/rfc7617>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8463]

Levine, J., "A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)", RFC 8463, DOI 10.17487/RFC8463, September 2018, <https://www.rfc-editor.org/rfc/rfc8463>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/rfc/rfc8552>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[RFC8689]

Fenton, J., "SMTP Require TLS Option", RFC 8689, DOI 10.17487/RFC8689, November 2019, <https://www.rfc-editor.org/rfc/rfc8689>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9111]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/rfc/rfc9111>.

[RFC9113]

Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/rfc/rfc9113>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[RFC9457]

Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, <https://www.rfc-editor.org/rfc/rfc9457>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

[RFC9525]

Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, <https://www.rfc-editor.org/rfc/rfc9525>.

[RFC9530]

Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, <https://www.rfc-editor.org/rfc/rfc9530>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

17.2. Informative References

[AWS-SES]

Amazon Web Services, "Amazon Simple Email Service API Reference: SendEmail", <https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_SendEmail.html>.

[HALON]

Halon Security AB, "HTTP submission", <https://docs.halon.io/manual/http_submission.html>.

[OCI-EMAIL]

Oracle, "Email Delivery", <https://docs.oracle.com/en-us/iaas/Content/Email/home.htm>.

[RFC2034]

Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 1996, <https://www.rfc-editor.org/rfc/rfc2034>.

[RFC2046]

Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/rfc/rfc2046>.

[RFC3207]

Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <https://www.rfc-editor.org/rfc/rfc3207>.

[RFC4865]

White, G. and G. Vaudreuil, "SMTP Submission Service Extension for Future Message Release", RFC 4865, DOI 10.17487/RFC4865, May 2007, <https://www.rfc-editor.org/rfc/rfc4865>.

[RFC4954]

Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, <https://www.rfc-editor.org/rfc/rfc4954>.

[RFC5965]

Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, DOI 10.17487/RFC5965, August 2010, <https://www.rfc-editor.org/rfc/rfc5965>.

[RFC6522]

Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, <https://www.rfc-editor.org/rfc/rfc6522>.

[RFC6533]

Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, <https://www.rfc-editor.org/rfc/rfc6533>.

[RFC6797]

Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012, <https://www.rfc-editor.org/rfc/rfc6797>.

[RFC7208]

Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/rfc/rfc7208>.

[RFC7489]

Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/rfc/rfc7489>.

[RFC7505]

Levine, J. and M. Delany, "A "Null MX" No Service Resource Record for Domains That Accept No Mail", RFC 7505, DOI 10.17487/RFC7505, June 2015, <https://www.rfc-editor.org/rfc/rfc7505>.

[RFC7672]

Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, <https://www.rfc-editor.org/rfc/rfc7672>.

[RFC8098]

Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, February 2017, <https://www.rfc-editor.org/rfc/rfc8098>.

[RFC8301]

Kitterman, S., "Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)", RFC 8301, DOI 10.17487/RFC8301, January 2018, <https://www.rfc-editor.org/rfc/rfc8301>.

[RFC8305]

Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/rfc/rfc8305>.

[RFC8461]

Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/rfc/rfc8461>.

[RFC8551]

Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.

[RFC8601]

Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, <https://www.rfc-editor.org/rfc/rfc8601>.

[RFC8620]

Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 2019, <https://www.rfc-editor.org/rfc/rfc8620>.

[RFC8621]

Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, August 2019, <https://www.rfc-editor.org/rfc/rfc8621>.

[RFC8792]

Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/rfc/rfc8792>.

[RFC9051]

Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, <https://www.rfc-editor.org/rfc/rfc9051>.

[RFC9114]

Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

[RFC9580]

Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024, <https://www.rfc-editor.org/rfc/rfc9580>.

A.1. Discovery

A Sending Server that has a Message for "bob@example.net" queries DNS and retrieves the Capabilities Document of the target host:¶

_hmtp.example.net.  3600 IN SVCB 1 mx.example.net. alpn=h2,h3

GET /.well-known/hmtp HTTP/1.1
Host: mx.example.net

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=86400

{
  "versions": {
    "1": {
      "endpoints": {
        "transfer": {
          "uri": "/hmtp/v1/transfer",
          "reports": "/hmtp/v1/reports"
        }
      }
    }
  },
  "limits": {
    "maxMessageSize": 10737418240,
    "maxRequestSize": 26214400,
    "maxRecipients": 500
  },
  "policy": {
    "mode": "enforce",
    "maxAge": 2592000
  }
}

A.2. Transfer with Referenced Content

The Sending Server transfers a Message with a large attachment by reference. The Receiving Server accepts the Message and retrieves the attachment after responding, which it indicates with the status code 202 (Accepted). The Sending Server keeps the attachment available until its "expires" timestamp:¶

NOTE: '\' line wrapping per RFC 8792

POST /hmtp/v1/transfer HTTP/1.1
Host: mx.example.net
Content-Type: application/json
Content-Digest: sha-256=:q1M8rT4vYw7Zb2Nd5Kf0Hs9Lx3Jc6Pg1Ue8Ra4Wi2Oo=:
Signature-Input: hmtp=("@method" "@target-uri" "content-type" \
  "content-digest");created=1767268800;expires=1767269100;\
  keyid="hmtp2026";domain="example.com";alg="ed25519";tag="hmtp"
Signature: hmtp=:Zm9vYmFyZXhhbXBsZXNpZ25hdHVyZXZhbHVlbm90cmVh\
  bGx5dmFsaWRqdXN0aWxsdXN0cmF0aXZlb25seWZvcg==:

{
  "envelope": {
    "id": "Hq9vR2xLm4Tz8Kc1Wb6Nd0",
    "from": "alice@example.com",
    "to": [{"address": "bob@example.net"}],
    "body": "7bit"
  },
  "message": {
    "segments": [
      {"data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..."},
      {
        "uri": "https://files.example.com/f/9b1c4e7a",
        "size": 734003200,
        "digest": {
          "sha-256": "Yk3qV0sJpRm9T2cFhWxN6dL1bA8eQu7ZgKi4oPyXwE0="
        },
        "expires": "2026-01-08T12:00:00Z",
        "encoding": "base64"
      },
      {"data": "DQotLWIxLS0NCg=="}
    ],
    "size": 1004426786
  }
}

HTTP/1.1 202 Accepted
Content-Type: application/json

{
  "queueId": "8Jk2Pq7Xv1",
  "recipients": [
    {"address": "bob@example.net", "result": "accepted"}
  ]
}

A.3. Submission

A Client submits a Message with Basic authentication. The Submission Server accepts responsibility for both recipients and reports the outcome of the final delivery through DSNs:¶

POST /hmtp/v1/submission HTTP/1.1
Host: hmtp.provider.example
Authorization: Basic YWxpY2U6czNjcjN0LWFwcC1wYXNzd29yZA==
Content-Type: application/json

{
  "envelope": {
    "id": "c5N1qW8eR3tY6uI9oP2aS4",
    "from": "alice@example.com",
    "to": [
      {"address": "bob@example.net"},
      {"address": "dave@example.org"}
    ]
  },
  "message": {
    "data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..."
  }
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "queueId": "S-20260101-0042",
  "recipients": [
    {"address": "bob@example.net", "result": "accepted"},
    {"address": "dave@example.org", "result": "accepted"}
  ]
}

A.4. Retried Request

The connection is lost before the Sending Server receives the response to the request in Section 6.1. The Sending Server sends the identical request again with a new signature. The Receiving Server recognizes the Transfer Identifier and returns the stored response without delivering the Message again:¶

HTTP/1.1 200 OK
Content-Type: application/json

{
  "queueId": "4Y7mKq2ZtR",
  "recipients": [
    {"address": "bob@example.net", "result": "accepted"},
    {
      "address": "carol@example.net",
      "result": "rejected",
      "problem": {
        "type": "urn:ietf:params:hmtp:error:unknown-recipient",
        "title": "Unknown recipient",
        "smtpStatus": "5.1.1",
        "smtpReply": 550
      }
    }
  ]
}

A.5. Delivery Status Report

The Receiving Server "mx.example.net" has accepted a Message from "alice@example.com" for two recipients. The Recipient Object of "dan@example.net" requests notification on success, and the Recipient Object of "bob@example.net" requests notification on delay. The Envelope requests the return of the header section ("ret" is "hdrs"). After four hours, the Message has been delivered to "dan@example.net", while delivery to "bob@example.net" is still being retried. "mx.example.net" reports both events in one report to the "reports" endpoint of "example.com" (Section 4.3.3). The report for "dan@example.net" contains no problem details object, because the action is "delivered":¶

NOTE: '\' line wrapping per RFC 8792

POST /hmtp/v1/reports HTTP/1.1
Host: hmtp.provider.example
Content-Type: application/json
Content-Digest: sha-256=:...:
Signature-Input: hmtp=("@method" "@target-uri" "content-type" \
  "content-digest");created=1767286800;expires=1767287100;\
  keyid="hmtp2026";domain="example.net";alg="ed25519";tag="hmtp"
Signature: hmtp=:...:

{
  "id": "Dq3rT6yU9iO2pA5sD8fG1h",
  "envelopeSender": "alice@example.com",
  "reportingServer": "mx.example.net",
  "transferId": "Lw2eR5tY8uI1oP4aS7dF0g",
  "transferDomain": "example.com",
  "envid": "QQ271828",
  "messageId": "<20260101130000.5e7b@example.com>",
  "arrivalDate": "2026-01-01T13:00:02Z",
  "recipients": [
    {
      "finalRecipient": "dan@example.net",
      "originalRecipient": "rfc822;dan@example.net",
      "action": "delivered",
      "lastAttempt": "2026-01-01T16:59:58Z"
    },
    {
      "finalRecipient": "bob@example.net",
      "action": "delayed",
      "problem": {
        "type": "urn:ietf:params:hmtp:error:mailbox-full",
        "title": "Mailbox full",
        "detail": "The mailbox bob@example.net is over quota.",
        "smtpStatus": "4.2.2",
        "smtpReply": 452
      },
      "lastAttempt": "2026-01-01T17:00:00Z",
      "willRetryUntil": "2026-01-06T13:00:02Z"
    }
  ],
  "returnedContent": {
    "data": "UmVjZWl2ZWQ6IGZyb20g..."
  }
}

HTTP/1.1 204 No Content

The server of "example.com" correlates the report with its Message through the "envid" member. If "alice@example.com" is read with a mail client, the server converts the report into a DSN message as described in Section 9.4.4: the recipient "dan@example.net" receives the "Status" field "2.0.0", the recipient "bob@example.net" the "Status" field "4.2.2", and the "returnedContent" member becomes a "text/rfc822-headers" part.¶