ZI2 Certified Email Server Attestation Protocol

Introduction

Problem Statement The current email authentication ecosystem relies on three principal protocols: SPF , DKIM , and DMARC . 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.

Scope This document specifies a server-level cryptographic attestation protocol that:

Generates a unique Ed25519 key pair per server instance.
Signs outbound email with a server-specific attestation header.
Publishes the server's public key via DNS TXT records, HTTPS well-known endpoints, and direct server-to-server exchange.
Verifies inbound email bearing the attestation header against the published public key.
Assigns graduated trust levels reflecting the strength of the verification method.
Integrates with AI-based email classification systems as a primary trust signal.

Relationship to Existing Protocols ZI2 Certified does not modify, replace, or interfere with SPF, DKIM, DMARC, ARC , BIMI, MTA-STS, or DANE . 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.

Terminology 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 and .

Certification: The process by which a sending mail server generates a cryptographic attestation of email origin and injects the attestation into the email as a structured header.
Verification: The process by which a receiving mail server validates a certification header by retrieving the sender server's public key and verifying the cryptographic signature.
Certifying Server: A mail server that generates and injects ZI2 Certified headers on outbound email originating from its locally-hosted domains.
Verifying Server: A mail server that validates ZI2 Certified headers on inbound email.
Trust Level: A graduated integer value (0 through 3) representing the confidence in the verification result based on the method of public key retrieval.
Key Identifier (kid): A unique string identifying a specific public/private key pair, formatted as "zi2-cert-YYYY-MM".
Server Identifier (sid): The fully-qualified domain name (FQDN) of the certifying server.
Intra-Server Email: Email transmitted between two domains hosted on the same physical or virtual server instance.

Protocol Specification

Cryptographic Primitives The protocol uses Ed25519 for signing (approximately 128 bits of security, deterministic signatures, 32-byte public keys, 64-byte signatures), SHA-256 for body hash computation, and Base64 for encoding.

Key Generation 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".

Outbound Certification 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.

Inbound Verification 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.

Header Format 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).

DNS Publication 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.

Trust Levels 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.

Security Considerations Key compromise impact is bounded by the 24-hour freshness window and key rotation interval. DNS poisoning affects Trust Level 1 only; DNSSEC 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.

IANA Considerations 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.