ZK Email

• Name: ZK Email
• URL: https://zk.email/
• Category: email-proof / DKIM-verification middleware / zero-knowledge identity-and-auth infrastructure
• Summary: ZK Email turns DKIM-signed email into reusable proofs. The important part is not the email login demo layer. It is the stack underneath: DKIM-key discovery and registry policy, proof generation, verifier contracts, and application-specific parsing. Useful middleware, not a generic identity answer.
• 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.
• Sources:
  • https://zk.email/
  • https://docs.zk.email/
  • https://docs.zk.email/introduction
  • https://docs.zk.email/architecture/
  • https://docs.zk.email/architecture/on-chain
  • https://docs.zk.email/architecture/security-considerations
  • https://github.com/zkemail
  • https://raw.githubusercontent.com/zkemail/zk-email-verify/main/README.md
  • https://raw.githubusercontent.com/zkemail/zk-email-verify/main/packages/contracts/README.md

Internal linkages

• Best contrasts: tlsnotary and reclaim-protocol.
• Different provenance object: email-provider signatures plus DKIM-registry policy, not witnessed HTTPS transcripts.

Control surface

• The leverage sits in DKIM-key sourcing and rotation, registry policy, proving mode, verifier-contract defaults, and how much downstream app logic standardizes around email-native proofs.

• Read ZK Email as proof middleware with an email-specific trust surface, not as a generic login wrapper.

• Last reviewed: 2026-06-14 UTC