Overview
SwornMail
An operator publishes a signed, verifiable claim that a range of IPv6 address space is one accountable entity, staked on their domain name. Receivers get a stable reputation unit instead of 264 addresses they cannot reason about.
Status. SwornMail is an Internet-Draft, not an IETF standard, and has no IETF consensus. The -01 wire format is frozen and backed by 62 published conformance vectors and two independent implementations. There are no public deployments.
What it does
An operator publishes two DNS TXT records: a key record carrying a signing key, and a policy record naming the prefixes they stand behind and the granularity at which they are willing to be judged.
A receiver, at connection time and before message data, establishes which operator is accountable for the connecting address and confirms the address really falls inside a prefix that operator attested. On sworn=pass it keys reputation on (operator domain, unit prefix) rather than on an individual address.
Two deployment modes
Mode 1, DNS-only. Publish the records; nothing in your mail software changes. The receiver discovers the operator from the connecting address. This is the baseline the protocol is designed around and it is deployable today.
Mode 2, signed token. An SMTP extension carries a compact COSE-signed token verified statelessly at connection time, for stronger source authenticity. It requires software that speaks the extension — notably, a milter cannot advertise it, because milters run after the command phase.
What it deliberately does not do
Reading this list first will save you time, because several of these are the first thing people assume SwornMail is for.
- It does not authenticate messages. That is DKIM’s job. SwornMail attests the connection’s address space and says nothing about any message carried over it.
- It does not authorise a sender for a domain. That is SPF’s job, and it needs a claimed identity to check against. SwornMail asserts something about the address space itself, which is why it works for a sender whose domain you have never seen.
- Attestation is not endorsement. Publishing a record does not ask anyone to trust you; it says who to hold responsible. Receivers and reputation services decide what that is worth.
- It never makes treatment worse. Absence or failure of SwornMail must not be treated as worse than a receiver’s existing default for unattested IPv6. A failed verification identifies no accountable party — see reputation semantics.
- It is not a reputation service. The protocol produces a stable key to keep reputation on. What anyone does with that key is outside its scope.
Where to go next
Deploy as an operator
Generate a key, generate records, publish, verify. Starts in observe-only mode by default.
DNS records
Every tag, its meaning, whether it is required, and what makes a record malformed.
Verification and results
The five result values, what causes each, and the rules a receiver must follow when acting on them.
Implementations
Go reference and CLI, independent Rust verifier, Postfix milter, rspamd module, conformance vectors.
The draft is normative; this site is not. These pages exist to be read quickly. Where they and the Internet-Draft disagree, the draft is correct and the page is a bug — please report it.