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 key instead of 264 addresses they cannot reason about.
Status. SwornMail is specified in an Internet-Draft that has not yet been submitted to the IETF. It is not a standard and has no IETF consensus. The -01 wire format is frozen and backed by 85 published conformance vectors, two independent verifiers and an rspamd module. 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 ask 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, observed /64) — the connecting address’s own /64 — rather than on an individual address, and widens that only with independent evidence that the operator controls more. See reputation semantics.
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. The current revision marks it experimental, so receivers should give it low weight until there is operational experience.
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.
- It does not publish allocation sizes. RFC 9977 lets the holder of an address block publish how large its end-sites are. SwornMail answers a different question: which mail operator accepts accountability for a prefix, stated at connection time.
- 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, for reputation or for delivery. 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.