Signed Email Authentication Layer (SEAL)

Internet-Draft	SEAL	April 2026
Ahearn	Expires 18 October 2026	[Page]

Abstract

This document defines the Signed Email Authentication Layer (SEAL), a cryptographically signed identity envelope carried within a new message header field, SEAL-Envelope. SEAL provides a stable, forwarding-resilient identity assertion that binds the origin domain to a specific message instance using the SEAL-MSGID header, which contains a SEAL-protected copy of the [RFC5322] Message-ID present at message creation time. After SEAL-MSGID is set, intermediaries may modify or discard the visible [RFC5322] Message-ID header without affecting SEAL validity. SEAL also records the canonical [RFC5322] From header value in the envelope, enabling detection of From rewriting without affecting SEAL validity. SEAL is designed to complement current approaches such as DKIM, DMARC, and ARC by reducing their dependency on mutable message components and by providing a canonical, tamper-evident identity layer that can remain valid across many common transformations.¶

Status of This Memo

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

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

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

This Internet-Draft will expire on 18 October 2026.¶

Copyright Notice

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

1. Introduction

Email authentication today relies primarily on SPF, DKIM, and DMARC. These mechanisms provide meaningful protections but share a fundamental architectural limitation: they bind identity to message components that are inherently mutable. SPF validates only the connecting IP address, not the author identity. DKIM signs selected headers and the message body, both of which are routinely modified by forwarders, mailing lists, and security appliances. DMARC depends on alignment with SPF and DKIM and therefore inherits their fragility.¶

The Signed Email Authentication Layer (SEAL) introduces a new identity layer for email that reduces dependence on mutable message components. SEAL defines a canonical, tamper-evident identity envelope that is signed by the originating domain and carried in a dedicated header, SEAL-Envelope. The envelope asserts the sender's identity, the intended recipient scope, a validity window, and a stable message identifier derived from the [RFC5322] Message-ID and carried in the SEAL-MSGID header.¶

SEAL depends on the SEAL-MSGID header and the scope field for message binding. The SEAL-MSGID header is populated by the sender with the [RFC5322] Message-ID value at the time the message is created. After SEAL-MSGID is set, intermediaries may modify or discard the [RFC5322] Message-ID header without affecting SEAL validity. All other [RFC5322] headers and the message body may also be modified in transit without affecting SEAL signature verification. Because SEAL does not sign or depend on mutable headers or the message body, it can remain valid across many forms of forwarding and transformations that commonly break DKIM, subject to the scope and msgid constraints recorded in the envelope.¶

SEAL is intended to function alongside DKIM and ARC, each addressing a different part of the authentication problem. DKIM and ARC provide content-binding and chain-of-custody information, while SEAL moves the identity assertion into a separate, tamper-evident envelope that remains stable across many forms of forwarding and header rewriting. Together, these mechanisms offer complementary assurances without overlapping responsibilities.¶

This document is written using the xml2rfc v3 vocabulary [RFC7991].¶

3. Terminology

This section defines terminology used throughout this document.¶

: Origin domain -- The domain that generates and signs the SEAL envelope and publishes the corresponding public key in DNS.¶
: SEAL envelope -- The canonical JSON object defined by this document that carries the identity assertion and associated metadata, and that is signed by the origin domain.¶
: Receiver -- A system that receives an email message and is capable of parsing and verifying the SEAL-Envelope header.¶
: Forwarder -- An intermediary that receives a message and re-sends it, potentially modifying the [RFC5322] header block or message body.¶
: Recipients -- The recipient identifiers the sender addresses the message to at send-time (e.g., mailbox, domain, mailing list address). This term does not include the expanded set of delivery mailboxes produced by intermediaries such as mailing lists, aliases, or forwarding systems.¶
: Scope -- A field in the SEAL envelope that indicates the recipients for whom the SEAL assertion is valid.¶
: Message identifier (msgid) -- The value of the SEAL-MSGID header, which is set by the sender to the [RFC5322] Message-ID header value at message creation time and used to bind the SEAL envelope to a specific message instance.¶
: Author identity (from) -- The canonical [RFC5322] From header value as recorded in the SEAL envelope. This value is signed and immutable; intermediaries may rewrite the visible From header without affecting SEAL verification.¶

4. Problem Statement

DKIM [RFC6376] attempts to provide message integrity by signing selected headers and the message body. However, email is inherently mutable. Forwarders, mailing lists, and security appliances routinely modify headers and bodies in ways that invalidate DKIM signatures. ARC attempts to preserve authentication results across intermediaries, but it adds complexity and does not address the underlying issue that identity is tied to mutable data.¶

The core architectural problem is that DKIM binds identity to message components that are not stable. SEAL addresses this by binding identity to a separate, canonicalized envelope that is not part of the mutable header block and is therefore more resilient to common transformations.¶

5. SEAL Overview

SEAL defines a new identity envelope containing:¶

origin -- the domain asserting identity¶
scope -- the intended recipients¶
iat -- issued-at timestamp¶
exp -- expiration timestamp¶
msgid -- the value of the SEAL-MSGID header, which is set to the [RFC5322] Message-ID at message creation time¶
from -- the canonical [RFC5322] From header value at message creation time¶
alg -- signature algorithm identifier¶
eh -- hash of the canonical envelope excluding the "sig" field¶
sig -- signature over the canonical envelope¶

The envelope is serialized using a strict canonical JSON serialization. Before signing, the implementation computes the "eh" value as a hash of the canoni