Release notes

spaceship is unverified. To promote it (do this when you have a live Spaceship panel open):

1. Open the panel and click + Add record for one record of each type (MX / SRV / TXT / CNAME) — the manual form, not the zone-import preview.
2. Confirm three things:
   • The exact field labels in the add form (is it Host or Hostname? etc.).
   • SRV host — one field or split? Resolved 2026-07-14: Spaceship's public API models SRV with a single combined name (_caldavs._tcp), not a split service/protocol — so the combined form we ship is correct (see the spaceship notes below). The import-preview split was a UI display quirk.
   • Whether CNAME/MX targets need a trailing dot (the import preview stored one).
3. Fix records.json if anything differs, then remove the UNVERIFIED — prefixes from the four spaceship headers, and delete the unverified notes in README.md and the spaceship section below.

Details and reasoning are in the spaceship notes.

godaddy is unverified. To promote it (do this when you have a live GoDaddy panel open):

1. Open DNS → DNS Records → Add New Record and pick each Type (MX / SRV / TXT / CNAME) in turn.
2. Confirm three things:
   • The exact field labels in the add form (the SRV form screenshot shows Type / Service / Protocol / Name / Value / Priority / Weight / Port; check the MX/TXT/CNAME forms match Type / Name / Priority / Value etc.).
   • Apex Name is entered as @ (what we ship), not left blank.
   • Whether CNAME/MX/SRV targets (Value) need a trailing dot.
3. Fix records.json if anything differs, then remove the UNVERIFIED — prefixes from the four godaddy headers, and delete the unverified notes in README.md and the godaddy section below.

Details and reasoning are in the godaddy notes.

ionos is unverified. To promote it (do this when you have a live IONOS panel open):

1. Open Domains & SSL → gear next to the domain → DNS → ADD RECORD and pick each Type (MX / SRV / TXT / CNAME) in turn. CNAME is reached via Manage Subdomains → gear on the subdomain → DNS instead.
2. Confirm three things:
   • The exact field labels in the add form (the SRV form screenshot shows Type / Service / Protocol / Host name / Points to / Priority / Weight / Port; check MX/TXT match Host name / Points to / Value and CNAME uses Hostname / Point to).
   • Apex Host name is entered as @ (what we ship) for MX/TXT, not left blank.
   • Whether the SRV Protocol dropdown offer matches TCP and whether any target needs a trailing dot (the CNAME doc says enter it without one).
3. Fix records.json if anything differs, then remove the UNVERIFIED — prefixes from the four ionos headers, and delete the unverified notes in README.md and the ionos section below.

ionos.example.com is already correctly configured on IONOS, so it is a ready-made target: verify_thundermail_dns.py ionos.example.com should report 13/13.

Details and reasoning are in the ionos notes.

ovh is unverified. To promote it (do this when you have a live OVHcloud panel open):

1. Open Web Cloud → DNS zones → your domain → DNS zone → Add an entry and pick each type (MX / SRV / TXT / CNAME) in turn.
2. Confirm three things:
   • The exact field labels in each wizard (the TXT/SPF wizard screenshot shows Sub-domain / TTL / Value; the MX and SRV wizards were not screenshotted — verify their labels and, for SRV, whether Priority/Weight/Port/Target are separate fields or one combined string).
   • Apex Sub-domain is left empty (what we ship), not @.
   • Whether MX and SRV targets need a trailing dot (we ship one on all FQDN targets, since the docs say OVH appends your domain to an unpunctuated target; the CNAME trailing dot is documented, MX/SRV is inferred).
3. Fix records.json if anything differs, then remove the UNVERIFIED — prefixes from the four ovh headers, and delete the unverified notes in README.md and the ovh section below.

ovh.example.com is already correctly configured on OVH (NS ns200.anycast.me), so it is a ready-made target: verify_thundermail_dns.py ovh.example.com should report 13/13, and --resolver ns200.anycast.me queries OVH authoritatively.

Details and reasoning are in the ovh notes.

digitalocean is unverified. To promote it (do this when you have a live DigitalOcean panel open):

1. Open Networking → Domains → your domain → Create a record and pick each type (MX / SRV / TXT / CNAME) in turn.
2. Confirm three things:
   • The exact field labels in each form (the SRV dialog screenshot shows Hostname / Will direct to / Port / Priority / Weight; the MX / TXT / CNAME labels come from the docs — verify Mail provider's mail server, TXT Value, and Is an alias of).
   • Apex Hostname is @ (what we ship), not blank.
   • Whether MX and CNAME targets need a trailing dot (we ship one on all FQDN targets; the SRV trailing-dot is confirmed live, MX/CNAME is inferred from DigitalOcean's general "appends your domain to an unpunctuated target" behaviour).
3. Fix records.json if anything differs, then remove the UNVERIFIED — prefixes from the four digitalocean headers, and delete the unverified notes in README.md.

digitalocean.example.com is DigitalOcean-hosted (NS ns1/ns2/ns3.digitalocean.com), so it is a ready-made target: --resolver ns1.digitalocean.com queries DigitalOcean authoritatively. Its 5 SRV records are currently broken — the target was entered without a trailing dot, so it came back as mail.thundermail.com.digitalocean.example.com — which both confirms the trailing-dot rule and makes fixing them a good end-to-end test of the emitted digitalocean SRV fixes.

porkbun is unverified. To promote it (do this when you have a live Porkbun panel open):

1. Open the DNS button under your domain → Manage DNS Records → + Add Record and pick each type (MX / SRV / TXT / CNAME) in turn.
2. Confirm three things:
   • The exact value-field label per type (we ship Answer for MX/SRV/TXT and Target for CNAME; the UI labels it contextually — IPv4 Address, Target, Answer / Value).
   • Apex Host is left blank (what we ship), not @; and MX/SRV show a separate Priority field with Weight/Port/Target packed into the SRV Answer.
   • Whether targets tolerate no trailing dot (we ship targets verbatim, no dot) — confirmed live for MX/CNAME on porkbun.example.com; re-confirm for SRV once SRV records exist there.
3. Fix records.json if anything differs, then remove the UNVERIFIED — prefixes from the four porkbun headers, and delete the unverified notes in README.md.

porkbun.example.com is Porkbun-hosted (NS curitiba/fortaleza/maceio/salvador.ns.porkbun.com), so it is a ready-made target: --resolver curitiba.ns.porkbun.com queries Porkbun authoritatively. Its MX/TXT/CNAME records are already correct (8/13); its 5 SRV records aren't added yet, so adding them there is a good end-to-end test of the emitted porkbun SRV fixes.

metanet-plesk is unverified. To promote it (do this with a live METANET Plesk panel open):

1. Open Websites & Domains → your domain → DNS-Einstellungen → Eintrag hinzufügen and pick each type (MX / SRV / TXT / CNAME) in the Eintragstyp dropdown.
2. Confirm three things:
   • The exact German MX and CNAME field labels (we ship Mail-Exchange-Server and Kanonischer Name from Plesk's docs; only the SRV and TXT forms were screenshotted).
   • Priorität is a dropdown for MX too, and it offers an entry for 10.
   • Targets are stored verbatim without a trailing dot (confirmed live for MX/SRV on thundermail.metanet.example.com; re-confirm for CNAME).
3. Fix records.json if anything differs, then remove the UNVERIFIED — prefixes from the metanet-plesk MX/SRV/CNAME headers (TXT ships without one — its form is documented), and delete the unverified notes in README.md.

thundermail.metanet.example.com is METANET-hosted (NS ns1/ns2.hera.metanet.ch), so it is a ready-made target: --resolver ns1.hera.metanet.ch queries METANET authoritatively. It is at 12/13 — its _imaps._tcp SRV target was entered as the zone apex instead of mail.thundermail.com, so fixing that one is a good end-to-end test of the emitted metanet-plesk SRV fixes.

bunny (bunny.net)

Added 2026-07-13. First drafted from a record-list screenshot (the bunny.example.com zone), then corrected and verified the same day against bunny.net's official docs (DNS records). The confirmed conventions:

• The add-record dialog is a single form with a Type dropdown (not per-type sections like Cosmotown) and fields Hostname / Type / TTL / Value.
• Hostname is left empty for the root domain (the subhost pattern) — never @; bunny lists apex records under the full domain name.
• There is one Value field with no separate Priority / Weight / Port fields, so MX and SRV put the whole record string in Value ({match}) — e.g. MX 10 mail.thundermail.com, SRV 0 1 443 mail.thundermail.com. The record-list screenshot corroborated this (MX displayed as 10 mail.thundermail.com).
• The record list's Weight column is bunny's A/AAAA load-balancing "Routing Weight" (0-100, under Advanced Settings), not the SRV weight — so it does not factor into any of the Thundermail records.

Corrections made from the initial screenshot-only draft: the field is Hostname (not "Name"); MX/SRV use a single Value (not separate Priority/Weight/Port); dropped the unverified CNAME "no trailing dot" note.

Live validation (2026-07-13): ran the CLI against the real bunny.net-hosted bunny.example.com (delegated to kiki/coco.bunny.net) → 13/13 passed, exit 0. Driven by Zendesk ticket 6750. Every value bunny.net serves matches the expected strings byte-for-byte, including MX 10 mail.thundermail.com and SRV 0 1 443 mail.thundermail.com — confirming the single-Value-field ({match}) remediation produces exactly what the panel stores.

spaceship (spaceship.com) — unverified

Added 2026-07-13 for Zendesk ticket 6672. Marked unverified because the two sources only partly cover it:

• A zone-import preview screenshot from the real cosmotown.example.com zone (CONTRIBUTING artifact type 2, and specifically the import view — not the higher-priority manual add-record form, type 1).
• Spaceship's official docs (Required DNS records for Spacemail), which document Spacemail's own records (mx1.spacemail.com, …), a different record set — so they confirm the panel's column labels but not the Thundermail entries.

What the sources agree on and we encoded:

• Columns are Host / Type / Value / TTL (docs call Host "Hostname"); the panel auto-appends the domain to Host and uses @ for the root (not blank).
• MX has a separate Priority field alongside the target Value.
• SRV breaks out Priority / Weight / Port / Target as separate fields.
• The provider headers themselves carry an UNVERIFIED prefix so CLI/web users see the caveat inline.

Still unverified against a live manual add-record form:

• Exact field labels in the add form (vs. the import preview).
• Whether CNAME/MX targets need a trailing dot (the import view showed them stored with one).

SRV host — resolved 2026-07-14. The import view split the SRV host into _caldavs + _tcp (service + protocol) fields, which cast doubt on the combined _caldavs._tcp we ship. Reading Spaceship's public API DNS model settles it: the API represents an SRV record with a single combined name (e.g. _caldavs._tcp) plus separate priority / weight / port, with no split service/protocol — confirmed against docs.spaceship.dev and the dns.ts schema in the community MCP server hlebtkachenko/spaceship-mcp (generic name / value / priority / weight / port per record). So the combined _caldavs._tcp is correct at the data level and the split was a display quirk of the import view. (Contrast godaddy, whose manual add form genuinely splits Service and Protocol into separate inputs — a UI-layout difference, not a difference in the stored record.)

A community Spaceship MCP server (wraps the REST API; auth via SPACESHIP_API_KEY / SPACESHIP_API_SECRET) can drive a functional verification — create the 13 Thundermail records via its ss_dns_save tool on a live Spaceship-hosted domain, then verify_thundermail_dns.py <domain> --resolver <Spaceship NS> --provider spaceship should report 13/13 (same approach that validated bunny against bunny.example.com). That would confirm the record values and the combined-name decision, but the API is a different surface than the manual web form, so it still wouldn't nail the form's field labels (item 1) or the trailing-dot UI behavior (item 3) — a screenshot of the live add form remains the way to fully promote.

To promote to verified: capture the manual add-record form for one record of each type, confirm the field sets, then drop the UNVERIFIED prefixes in records.json and the note here and in README.md.

godaddy (godaddy.com) — unverified

Added 2026-07-14 for internal ticket 6850 (6850_GODADDY_CUSTOM_DOMAIN). Marked unverified: the conventions come from GoDaddy's official help articles plus a screenshot of the live SRV add-record form, but haven't been confirmed end-to-end by adding all 13 records on a live GoDaddy-hosted domain. Sources: MX, TXT, SPF, CNAME, SRV.

What the docs + screenshot establish and we encoded:

• The add-record dialog is a single form with a Type dropdown (like bunny / spaceship, not per-type sections like Cosmotown). Path: Domain Portfolio → domain → DNS → DNS Records → Add New Record.
• Name is entered as @ for the root domain (GoDaddy uses @, not a blank field — the {host} pattern, unlike bunny/cosmotown's blank apex).
• MX has a separate Priority field; Value is the mail host alone.
• SRV is the most decomposed of any provider: the form breaks the _service._protocol label into separate Service (_jmap) and Protocol (_tcp) fields, plus Name (@ at the apex), Value (target), and separate Priority / Weight / Port. This is the first provider to need it, so it added {service} / {protocol} / {srvhost} tokens to the shared interpreter in both verify_thundermail_dns.py and app.js (derived by splitting the SRV host label on .; kept in sync per CLAUDE.md).
• SPF is added as a plain TXT record (GoDaddy's SPF help article is just a TXT with an SPF value), so it uses the TXT field set.
• The provider headers carry an UNVERIFIED — prefix so CLI/web users see the caveat inline.

Still unverified against a live end-to-end add: the exact MX/TXT/CNAME field labels (only the SRV form was screenshotted), and whether any target Value needs a trailing dot. To promote: add one record of each type on a live GoDaddy-hosted domain, confirm 13/13 via --resolver <the domain's GoDaddy authoritative NS>, then drop the UNVERIFIED prefixes in records.json and the notes here and in README.md.

ionos (ionos.com) — unverified

Added 2026-07-16 for internal ticket 6911 (6911_IONOS_DNS_REDACTED_DOT_COM, domain ionos.example.com). Marked unverified: the conventions come from six IONOS help articles plus a screenshot of the live SRV add-record form, but haven't been confirmed end-to-end by adding all 13 records on a live IONOS-hosted domain. Sources (IONOS Help): Using a Domain with Another Provider's Mail Servers (Editing MX Records), Managing TXT Records, Managing SRV Records, Configuring a DMARC Record for a Domain, Configuring a CNAME Record for a Subdomain, Using IONOS SPF to Improve Email Delivery.

What the docs + screenshot establish and we encoded:

• The add-record dialog is a single form with a Type dropdown (like godaddy / bunny / spaceship, not per-type sections like Cosmotown). Path: Domains & SSL → gear next to the domain → DNS → ADD RECORD.
• Host name is entered as @ for the root domain for MX/TXT (the {host} pattern, not blank like bunny/cosmotown).
• MX has a separate Priority field; Points to is the mail host alone.
• SRV is decomposed like GoDaddy — the form splits _service._protocol into Service (_jmap) and Protocol fields — but with two IONOS-specific twists: (1) Protocol is a TCP/UDP/TLS dropdown, so {protocol} (which yields _tcp) would not match an option; it is hard-coded to TCP because all five checked SRV records are _tcp. (2) The form has both a Host name (record location → {srvhost}, @ at the apex) and a separate Points to (target), one field more than GoDaddy's SRV form. This reuses the {service} / {srvhost} tokens already added for godaddy, so no interpreter change was needed.
• SPF is a plain TXT record. IONOS enables its own "IONOS SPF" by default and may already have added a TXT (v=spf1 include:_spf-us.ionos.com ~all); the TXT header notes that the user must replace/merge it so only one SPF record remains.
• CNAME is reached via Manage Subdomains → gear on the subdomain → DNS (not the main DNS tab), and its fields are labelled Hostname / Point to (vs Host name / Points to elsewhere); the target is entered without a trailing dot.
• The provider headers carry an UNVERIFIED — prefix so CLI/web users see the caveat inline.

Still unverified against a live end-to-end add: the exact MX/TXT/CNAME field labels (only the SRV form was screenshotted), the SRV Protocol dropdown values, and whether any target needs a trailing dot. To promote: ionos.example.com is already correctly configured on IONOS, so confirm 13/13 with verify_thundermail_dns.py ionos.example.com, eyeball the emitted ionos fix strings against the live panel, then drop the UNVERIFIED prefixes in records.json and the notes here and in README.md.

ovh (ovhcloud.com) — unverified

Added 2026-07-16 for internal ticket 6837 (6837_OVH_DNS_PROVIDER_REDACTED, sample domain ovh.example.com). Marked unverified: the conventions come from three OVHcloud help articles plus a screenshot of the live TXT/SPF add-entry wizard, but the MX and SRV wizard field layouts were not screenshotted and haven't been confirmed end-to-end. Sources (OVHcloud Documentation): Editing an OVHcloud DNS zone (docs.ovhcloud.com/en/guides/web-cloud/domains/dns-zone-edit), Everything you need to know about DNS zone, How to improve email security with an SPF record (docs.ovhcloud.com/en/guides/web-cloud/domains/dns-zone-spf).

What the docs + screenshot establish and we encoded:

• Records are added through a 3-step "Add an entry to the DNS zone" wizard reached from the DNS zone table (Web Cloud → DNS zones → domain → DNS zone → Add an entry), not a flat single form. Step 1 picks the type (A/AAAA/NS/CNAME; CAA/TXT/NAPTR/SRV/…; MX/SPF/DKIM/DMARC).
• Apex Sub-domain is left empty — the wizard shows the .yourdomain suffix beside the field and appends it automatically (the {subhost} pattern, like bunny/cosmotown, not @).
• ⚠️ FQDN targets need a trailing dot. The docs are explicit for CNAME/URL targets ("if you do not punctuate it, your domain name will be automatically added to the end"), so all ovh MX/SRV/CNAME targets are emitted with a trailing . (encoded as {target}.). OVH is the first provider to require this. The CNAME dot is documented; the MX/SRV dot is inferred from the same rule and still needs live confirmation.
• SRV keeps the _service._protocol label combined in Sub-domain ({host}, e.g. _jmap._tcp) — OVH does not split Service/Protocol like godaddy/ionos, so the existing tokens suffice and no interpreter change was needed.
• SPF uses the plain TXT path; the header steers users away from OVH's "Add an OVHcloud SPF record" button (which injects include:mx.ovh.com).
• The provider headers carry an UNVERIFIED — prefix so CLI/web users see the caveat inline.

Still unverified against a live end-to-end add: the exact MX and SRV wizard field labels (only the TXT/SPF wizard was screenshotted), whether the SRV wizard uses separate Priority/Weight/Port/Target fields, and whether MX/SRV targets truly need the trailing dot. To promote: ovh.example.com is already correctly configured on OVH, so confirm 13/13 with verify_thundermail_dns.py ovh.example.com (or --resolver ns200.anycast.me), eyeball the emitted ovh fix strings against the live panel, then drop the UNVERIFIED prefixes in records.json and the notes here and in README.md.

metanet-plesk (metanet.ch, Plesk panel) — unverified

Added 2026-07-28 for internal ticket 7194 (7194_METANET_PLESK, sample domain thundermail.metanet.example.com), tracked in #13. The first Plesk-based panel we support, and the first German-language one. Sources: METANET's Plesk: DNS-Verwaltung help page plus a screenshot of the live Ressourceneintrag bearbeiten SRV form on thundermail.metanet.example.com. Marked unverified because the MX and CNAME field labels come from Plesk's docs rather than a live add-record form.

What the docs + screenshot establish and we encoded:

• Records are added through a single form with an Eintragstyp (entry type) dropdown (like bunny/godaddy/hover/digitalocean/porkbun, not per-type sections like Cosmotown). Path: Websites & Domains → your domain → DNS-Einstellungen → Eintrag hinzufügen. Offered types: NS, A, AAAA, CNAME, MX, PTR, TXT, SRV, DS, CAA.
• Field labels are emitted in German with an English gloss — Zielhost (Target host) — because that is what the user sees in the panel. Every other provider uses its panel's English labels.
• Domainname is left empty at the apex (the {subhost} pattern, like bunny/cosmotown/ovh/porkbun, never @); the form prints .yourdomain. beside the box.
• ⚠️ SRV splits the label into Service-Name + Protokoll — without the leading underscore. Both fields carry the hint "Beispiel: SIP (ohne Unterstrich)", and the live form shows imaps / tcp typed bare. The existing {service}/{protocol} tokens yield _imaps/_tcp (which is what GoDaddy/IONOS/Hover want), so this added two new interpreter tokens, {bareservice} and {bareprotocol} (in both verify_thundermail_dns.py and app.js, with a parity fixture). The SRV Domainname reuses Hover's {srvsubhost} (blank at the apex).
• ⚠️ Priorität and Relative Gewichtung are dropdowns, not text inputs. Priority 0 is offered (sehr hoch (0)), but the weight dropdown only offers 0/5/10…50, so Thundermail's weight: 1 is unenterable. This is what prompted the new exact_ignore_weight match mode on value_templates.SRV: priority/port/target still match exactly (the #10 protection is intact) but any weight passes, since weight only matters between competing targets at the same priority and we publish one target per service. The metanet-plesk SRV block therefore emits the literal dropdown entry niedrig (0) for the weight instead of {weight}. Whether the published Thundermail weight should change to 0 is #14.
• Weight, Port and Target are three separate fields (Relative Gewichtung / Zielport / Zielhost), so SRV uses the individual tokens like namecheap/hover, not a packed {value}.
• Targets are stored verbatim — no trailing dot needed. Confirmed live: four of the five SRV records on thundermail.metanet.example.com hold exactly mail.thundermail.com. and the MX holds 10 mail.thundermail.com., i.e. Plesk adds the root dot itself and does not append the zone name (unlike ovh/digitalocean).
• TXT values are auto-quoted by the panel — METANET's docs spell this out ("the entry type TXT automatically sets the including quotation marks"), so values are emitted unquoted, like cosmotown. The field is TXT-Eintrag.
• Two-step save. New/changed entries are flagged with an exclamation mark and go live only when Aktualisieren (Update) is clicked on the yellow pending-changes banner; edits can be batched. All four headers say so, since users otherwise assume the tool is wrong when a freshly "added" record still fails.
• Escape hatch documented in the headers: METANET sells a paid Premium Service: Individuelle DNS-Einstellungen — email support@metanet.ch with the records and their staff enter them. Unlike cosmotown (whose panel has no SRV section at all, forcing a support hand-off), this is optional here: every record type is self-serviceable.
• The MX/SRV/CNAME headers carry an UNVERIFIED — prefix so CLI/web users see the caveat inline; TXT ships without one, since its form is documented with a screenshot.

Naming: the key is metanet-plesk rather than plesk because the form layout is stock Plesk but the verbatim-target and auto-quoting behaviours were confirmed only on METANET's build — generalise to plesk if another Plesk host shows up.

Still unverified against a live end-to-end add: the German MX and CNAME field labels, whether the MX Priorität dropdown offers 10 (METANET's own default template ships MX 10 mail.<domain>., so it should), and the CNAME trailing-dot behaviour. To promote: thundermail.metanet.example.com is at 12/13 (only the misconfigured _imaps._tcp target is outstanding), so fix that record using the emitted metanet-plesk SRV instructions, confirm 13/13 with verify_thundermail_dns.py thundermail.metanet.example.com --resolver ns1.hera.metanet.ch, eyeball the emitted fix strings against the live panel, then drop the UNVERIFIED prefixes in records.json and the notes here and in README.md.