Skip to content
SwornMail docs

Reference

DNS records

An operator publishes two kinds of record: one key record per selector, and one policy record for the operator. Both are TXT records under the _sworn label.

You do not have to hand-write these. sworn genrecord emits both, in zone-file and DNS-panel form, and validates every rule on this page before printing anything — see Deploy as an operator.

Key record

Published at a QNAME carrying the selector, so each fetch returns exactly one key and rotation never bloats a response.

2026a._sworn.mailer.example.com. IN TXT
    "v=SWORN1; k=ed25519; pk=<base64>"
TagRequiredMeaning
vRequired, must be firstVersion. Always SWORN1.
kRequiredAlgorithm identifier from the SwornMail Algorithm Registry. Initial entry: ed25519.
pkRequiredPublic key, base64 with padding (RFC 4648 §4).

The selector appears only in the QNAME. There is no s= tag.

Keys must be dedicated to SwornMail. A key published in a _sworn record must not be reused for any other protocol. The token’s content-type binding provides additional domain separation for signatures.

An algorithm you do not implement is none, never fail

A record whose k= names an algorithm the verifier does not implement must yield sworn=none. This is what lets an operator publish a future-algorithm selector alongside a current one without being penalised by older verifiers.

Policy record

Published once per operator. It enumerates the attested prefixes — for Mode 1 discovery and for third-party audit — and carries the operator-wide policy tags.

_prefixes._sworn.mailer.example.com. IN TXT
    "v=SWORN1; p=2001:db8:f00::/48,2620:12a:8000::/48; u=64"
TagRequiredMeaning
vRequired, must be firstVersion. Always SWORN1.
pRequiredComma-separated attested prefixes, each meeting the prefix constraints. At most 64; verifiers ignore anything beyond the 64th.
uOptional, default 64Reputation unit: the prefix length you ask receivers to aggregate at. Must be 1–64. A value outside that range makes the record malformed rather than being silently clamped, so you see the error instead of quietly getting different behaviour than you asked for.
tOptionalColon-separated flags. y means testing mode.
ruaOptionalAggregate report destination. mailto: only, with DMARC-style external-destination verification.

u, t and rua apply to both deployment modes.

Testing mode

Publish t=y and receivers report sworn=none policy.testing=y, carrying the would-be result as a separate property. You stake no reputation in either direction — not credit, not blame — and can watch how your traffic would be classified before accepting accountability for anything.

This is enforced, not advisory. A testing-mode operator reported as sworn=pass is a conformance bug: it would let a receiver mistake a testing deployment for a committed one, which makes the on-ramp a trap. The reference implementations treat it as such.

sworn genrecord publishes t=y by default. You leave testing mode deliberately, by re-running with --testing=false.

Parsing rules

These are the rules that decide whether a record is usable at all. Most of them exist so that an operator error surfaces as an error rather than as a silently different policy.

Prefix constraints

Every prefix in p= must be canonical — masked, with no host bits set — and within the ranges the protocol admits. A non-canonical or out-of-range prefix yields permerror; it is not adjusted for you.

Prefix lengths run from /32 to /64. Space outside global unicast, and ranges reserved for transition mechanisms, are refused.

Reverse-tree pointer

Optional, and only relevant to Mode 1. If you control your reverse zone, publishing a pointer there lets a receiver find you directly:

_sworn.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN TXT
    "v=SWORN1; d=mailer.example.com"

Without it, discovery falls back to your MTA’s forward-confirmed PTR. Either way the operator’s own policy record is fetched and checked; the pointer is a shortcut, not a source of authority.

Delegation

CNAMEs are permitted at both the <selector>._sworn and _prefixes._sworn labels, so key or prefix management can be delegated to a third party — the ESP case.

Delegation transfers real authority. Pointing <selector>._sworn at a third party gives them the ability to sign attestations that bind your domain’s reputation; pointing _prefixes._sworn at them gives them control of which prefixes you appear to stand behind. Remove the CNAME when the relationship ends.