Summary: ZK Email is best understood not as a single wallet or login product, but as a middleware stack that turns ordinary DKIM-signed email into reusable zero-knowledge proofs for onchain and offchain verification. Its current docs and repos make several layers explicit that many email login or identity products flatten together: email-provider signing, DKIM-key discovery and registry/oracle policy, proof generation, verifier contracts, and application-specific parsing or action logic. That makes ZK Email a useful comparison point for zkTLS systems, credential middleware, account-recovery rails, and email-native wallet/auth flows: the real control surfaces are which email properties become standardized proofs, who controls DKIM key registration and rotation, whether proving runs client-side or on shared servers, and how much downstream trust shifts from websites to registries, relayers, and verifier contracts.
What it does:
Lets users prove properties of DKIM-signed emails, such as sender domain, recipient, or selected body/subject content, without revealing the whole email
Provides SDK packages, circuits, helper libraries, and Solidity verifier contracts for developers building email-based proof flows
Maintains onchain DKIM public-key registry patterns, including a base registry and a user-overrideable registry model for safer key updates and recovery flows
Supports application patterns including email-wallet control, smart-account recovery, login with email-backed session authorization, Proof-of-Twitter-style attestations, and JWT-backed transaction building
Exposes an infrastructure-and-SDK direction through the GitHub org and docs, where developers can define new proof types and integrate different proving backends such as Circom, Noir, and SP1
Key claims:
The official architecture docs describe ZK Email as a way to authenticate DKIM signatures and prove specific email-content properties without exposing the full email, using existing email infrastructure rather than a new messaging network.
The onchain docs make the core split very clear: offchain proof generation, onchain verifier contracts, application-specific business-logic contracts, and an onchain DKIM public-key registry that replaces live DNS lookups at verification time.
The contracts docs are analytically useful because they expose DKIM-key management as a first-class control surface. DKIMRegistry.sol handles domain-key hashes and revocation, while UserOverrideableDKIMRegistry.sol adds a more defensive path where user signatures and time delays can constrain key changes.
The security docs surface the main trust boundaries instead of hiding them: ZK Email still depends on correct DKIM implementation by email providers, secure DNS or DKIM-key sourcing, and the soundness of the proving system, even though it reduces how much downstream apps need to trust centralized verifiers.
The GitHub organization shows this is more than a single demo app. The project spans verifier packages, contracts, a registry/SDK path for new proof types, account-recovery flows, email-wallet flows, and multiple proving backends, which makes it more useful to catalog as proof middleware than as just email auth.
ZK Email belongs in the active corpus because it exposes a lower-layer email-proof primitive that sits beside, not inside, zkTLS systems. The provenance object is a DKIM-signed email plus registry/oracle policy, not a witnessed HTTPS transcript.
The strongest comparison questions for later work are: when should apps rely on email-provider signatures instead of TLS-transcript proofs, how much power sits in DKIM-key registry/oracle operators, and whether email-native proofs become a reusable credential rail or remain tightly coupled to a few wallet/recovery flows.
Whitepaper: No single canonical ZK Email whitepaper dominated this pass. The clearest current primary materials were the official docs, architecture and security pages, GitHub organization overview, verifier/contracts READMEs, and app-specific documentation. The main repo also exposes a Zenodo DOI for the software release, but the docs and active repos were more operationally useful for understanding the system today; see ../whitepapers/zkemail-primary-sources-2026-05-12.md.