Why this exists
Email is a chain of formats, DNS records, relays, filters, clients, and human expectations. The IETF defines the message format, SMTP, and the authentication records. W3C publishes the accessibility guidance. Mailbox providers publish their own sender requirements, and every client renders HTML its own way. Almost nobody carries the whole picture.
This site collects those pieces into one provider-agnostic specification of observable outcomes. Each topic states what the requirement is, why it matters, how to implement it, common mistakes, and how to verify the delivered result.
Who it is for
- Engineers who build or audit the mail an application sends, and want one reference.
- Email and lifecycle teams who want to scope quality without inventing it from scratch.
- Agents that need a machine-readable description of what to check. See MCP.
What it is not
It is not an ESP comparison, a template framework, legal advice, or a guarantee of inbox placement. Standards define the floor; mailbox providers and recipients still make their own decisions.
Status levels
Every topic has a status. Use them as the default; context can justify exceptions.
- Required: leaving it out breaks delivery, authentication, or access for some recipients.
- Recommended: what modern mailbox providers, clients, and recipients expect.
- Optional: useful in some contexts, not all.
- Avoid: outdated, harmful, or unsafe.
Technologies that were evaluated and left out, such as BIMI and AMP for Email, are listed under Considered, with the reason and what would change the decision.
How it is built
A static site, generated with Astro. The content is plain Markdown under src/content/spec/. Sources are part of the schema: a topic without a source does not build.
Credits
The spec draws on, and credits on every topic that uses it:
- The IETF RFCs: message format, MIME, SMTP, SPF, DKIM, DMARC, MTA-STS, DANE, and one-click unsubscribe.
- W3C WAI and WCAG for accessibility.
- Can I email for client rendering support.
- M3AAWG and mailbox provider sender guidelines for deliverability.
- The EU and the UK ICO for privacy and consent; NIST and MITRE for security.
- The Website Specification, its sibling for the web.
Licensing
Content: CC BY 4.0. Code: MIT. Use it, fork it, ship it.
Contact
Maintained by Joost de Valk and contributors. For security reports, follow /.well-known/security.txt. For anything else, open an issue or read how to contribute.