| Internet-Draft | ZI2 Certified | April 2026 |
| Kadjo | Expires 24 October 2026 | [Page] |
This document specifies the ZI2 Certified Email Server Attestation Protocol, a mechanism for cryptographic attestation of email origin at the mail server level. Unlike existing email authentication protocols (SPF, DKIM, DMARC), which operate at the domain level, ZI2 Certified operates at the server-instance level, enabling definitive identification of the specific server that dispatched a given email message. The protocol introduces two custom mail headers (X-ZI2-Certified and X-ZI2-Verified), a DNS TXT record publication format, a graduated trust model with four levels, and an integration interface for AI-based email classification systems. The protocol operates complementarily to existing email authentication infrastructure and does not require modification of SPF, DKIM, or DMARC.¶
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 24 October 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The current email authentication ecosystem relies on three principal protocols: SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489]. Each of these protocols operates at the domain level, answering questions about whether a domain authorized the sending of a message. None of these protocols, individually or in combination, answer a more fundamental question: "Did this specific server actually send this email?"¶
This distinction is critical in multi-tenant mail server environments, where a single server hosts multiple domains under a shared IP address and MTA process. In such environments, domain-level authentication cannot distinguish between legitimate email from one co-hosted domain and spoofed email purporting to originate from another co-hosted domain. An attacker who compromises one domain's DNS records or DKIM keys can forge emails that pass SPF, DKIM, and DMARC validation for any domain on the shared server.¶
This document specifies a server-level cryptographic attestation protocol that:¶
ZI2 Certified does not modify, replace, or interfere with SPF, DKIM, DMARC, ARC [RFC8617], BIMI, MTA-STS, or DANE [RFC7671]. It operates as a complementary attestation layer that addresses the server-level authentication gap left by existing domain-level protocols. Existing protocols SHOULD continue to be deployed alongside ZI2 Certified.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174].¶
The protocol uses Ed25519 [RFC8032] for signing (approximately 128 bits of security, deterministic signatures, 32-byte public keys, 64-byte signatures), SHA-256 [RFC6234] for body hash computation, and Base64 [RFC4648] for encoding.¶
Upon initial deployment, the certifying server MUST generate an Ed25519 key pair. The private key MUST be stored with restricted filesystem permissions and MUST NOT be transmitted outside the server boundary. The key identifier MUST follow the format "zi2-cert-YYYY-MM".¶
The certifying server MUST construct a canonical certification payload containing: protocol version, lowercase sender address, lowercase recipient address, Unix timestamp, Message-ID, server hostname, Base64 SHA-256 hash of the complete message body, and Base64 128-bit random nonce. The payload MUST be signed with Ed25519 and injected as the X-ZI2-Certified header.¶
The verifying server MUST check for the X-ZI2-Certified header, retrieve the public key (from local store, trust store cache, direct exchange, DNS TXT, or HTTPS endpoint), reconstruct the canonical payload, and verify the Ed25519 signature. Additional checks include timestamp freshness (24-hour window), body hash integrity (SHA-256 of complete body), and optional nonce uniqueness.¶
The X-ZI2-Certified header uses tag=value format: v (version), t (timestamp), sid (server ID), bh (body hash), n (nonce), sig (Ed25519 signature), kid (key identifier). All tags are REQUIRED.¶
The X-ZI2-Verified header uses: result (pass/fail/missing/expired/tampered), level (0-3), reason (machine-readable code), sid, ts (verification timestamp).¶
A certifying server MUST publish a DNS TXT record at _zi2cert.<domain> for each hosted domain. Format: "v=ZI2CERT1; k=ed25519; p=<base64_key>; kid=<key_id>". All domains on the same server share the same public key because attestation is server-level. During key rotation, two records MAY coexist.¶
Level 3 (ABSOLUTE): Intra-server verification using local key store. Level 2 (VERIFIED): Key obtained via direct server-to-server exchange. Level 1 (DNS): Key obtained via DNS TXT record. Level 0 (UNKNOWN): No certification present or verification failed.¶
Level 3 is unique to this protocol. When both sender and recipient domains are co-hosted, verification uses the same key pair that generated the certification, providing mathematical certainty with no external dependencies.¶
Key compromise impact is bounded by the 24-hour freshness window and key rotation interval. DNS poisoning affects Trust Level 1 only; DNSSEC [RFC4033] SHOULD be deployed. Header injection is mitigated by Ed25519 signature verification. Replay attacks are mitigated by nonce, timestamp, and Message-ID binding. Body modification by intermediaries causes body hash mismatch. Ed25519 is vulnerable to quantum computing; post-quantum algorithms may be adopted via the version and algorithm tags.¶
This document requests registration of header fields X-ZI2-Certified and X-ZI2-Verified, DNS underscore label _zi2cert, and well-known URI zi2-cert.json.¶