ZK Email primary sources
Reviewed: 2026-05-12 UTC
Core project framing
- https://zk.email/
- Public project entrypoint and best quick overview of the main application surface.
- https://docs.zk.email/
- Official documentation root; best starting point for how the project currently wants developers to understand the system.
- https://docs.zk.email/introduction
- Concise high-level introduction that frames ZK Email as a documentation-first middleware stack rather than only a single app.
- https://github.com/zkemail
- GitHub organization overview; useful for seeing the breadth of the stack, including registry/SDK work, verifier packages, wallet/recovery flows, and proving-backend experimentation.
Mechanism and architecture
- https://docs.zk.email/architecture/
- Best concise architecture page for the core split between DKIM-signed emails, proof generation, onchain verification, and privacy-preserving selective disclosure.
- https://docs.zk.email/architecture/on-chain
- Best single page for the onchain decomposition into verifier contracts, application-specific contracts, and DKIM-key registry logic.
- https://raw.githubusercontent.com/zkemail/zk-email-verify/main/README.md
- Best repo-level source for package breakdown, supported proof patterns, audit references, and the project’s self-description as anonymous email-signature verification middleware.
- https://raw.githubusercontent.com/zkemail/zk-email-verify/main/packages/contracts/README.md
- Best concise source for the DKIM registry contracts and why DKIM-key registration / revocation is a first-class control surface.
Security and trust boundaries
- https://docs.zk.email/architecture/security-considerations
- Best current source for trust assumptions around DKIM, DNS, proving systems, replay/front-running concerns, and the project’s mitigation story around DKIM-key management.
Main takeaways from this pass
- ZK Email is more useful to catalog as email-proof middleware than as a single wallet or login app.
- The core provenance primitive is a DKIM-signed email plus registry/oracle policy, not a witnessed HTTPS transcript.
- The real control surface is not only proof generation; it also includes DKIM-key registration, revocation, rotation policy, and whether downstream apps trust a shared registry/oracle path.
- The project spans several adjacent product surfaces — verifier SDKs, contracts, email wallet flows, account recovery, login/session authorization, and JWT-triggered transaction building — but those are all downstream of the same email-proof primitive.
- Compared with zkTLS systems, ZK Email shifts the trust question toward email-provider signing, DKIM key management, and email-template parsing rather than transcript witnessing and attestor-network design.
- The docs and repos were more useful than any single formal paper for this pass because the operational architecture and trust boundaries are spread across architecture, contracts, and security pages.