1. Cite your sources
Every topic lists at least one source. If you add or change a claim, link the RFC, the W3C guidance, or the provider documentation behind it. No source, no merge.
2. Stay provider-agnostic
The spec describes outcomes, not one provider's implementation. “Publish a DMARC policy” is in scope. “Click this toggle in your ESP's dashboard” is not; link to the provider's own documentation instead.
3. Be honest about status
Required means mail breaks or excludes people without it. Recommended means a modern sender should do it. Optional means it depends.Avoid means it is outdated or harmful. If a status is wrong, fix it, with your reasoning in the pull request.
How to propose a change
- Open an issue describing the topic, gap, or fix.
- For a new topic, copy an existing file in
src/content/spec/<category>/and adjust the front matter. - Add a dated entry under
src/content/changelog/for any material change. - Run
npm run devlocally on port 31337 and check the page renders. Before you open the pull request, runnpm run build,npm run check,npm run mcp:typecheck, andnpm run mcp:dry-run. - Open a pull request. CI checks formatting and types, and builds the site and the MCP server.