DNS records

Nixt Server tells you exactly what to publish. init prints every record for the first domain, and versealx-server dns prints them again for any domain at any time. After you publish them, versealx-server doctor checks what is actually in DNS against what the server needs.

The examples on this page use example.com as the mail domain, mail.example.com as the server’s host name, and 192.0.2.10 and 2001:db8::10 as its public addresses.

Printing the records

sudo -u versealx versealx-server dns example.com --config /etc/versealx-server/versealx-server.toml

Leave out the domain to print the records for every domain the server hosts, each group headed by ; <domain>. The records come from the same place init takes them, so the two commands always agree. A domain the server does not host is refused with example.com is not a domain of this server.

dns reads the store directly, so it works whether or not the server is running.

Trying records before you publish them

Before you change your registrar’s zone, you can check the records you plan to publish. Type them in, and every check the server makes of the domain says what it would say with them. Your records replace what DNS has now for their names and types, and everything else is read from DNS as usual. Nothing is published.

On the console, use the Try records before publishing card on the domain’s page. Write one record a line: its type, its name and its value, such as TXT _dmarc.example.com v=DMARC1; p=reject. The types you can try are TXT, MX (the value is the preference and the host), A and AAAA. From the command line:

sudo -u versealx versealx-server admin try dns example.com \
  --record 'TXT _dmarc.example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com' \
  --record 'MX example.com 10 mx.example.com'

Through the API, send POST /tenants/{tenant}/try/dns with domain and records, each a name, a type and a value. You can try up to 50 records at once, all at or under the domain.

The records

This is what dns prints for a node that delivers mail directly. Lines that begin with ; are notes, not records.

  mail.example.com. IN A <this host's public address>   ; AAAA too, if it has one
  example.com. IN MX 10 mail.example.com.
  example.com. IN TXT "v=spf1 mx -all"
  ; only this host sends. Add `include:<relay>` before `-all` if you ever
  ;   send through one, or everything you send will fail SPF, and then
  ;   DMARC alignment, and the large receivers will refuse it
  ;   (RFC 7208 §2.6.4)
  _dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"   ; start at p=none, read the reports, then tighten
  _versealx-verify.example.com. IN TXT "versealx-verify=<token>"
  ; the RSA key below is two quoted strings, which is how a zone file
  ;   holds a value longer than 255 characters. A web form with a single
  ;   value field wants the text between the quotes instead, joined, with
  ;   the quotes and the space between them taken out
  <selector>r._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=<first part>" "<rest of the key>"
  <selector>e._domainkey.example.com. IN TXT "v=DKIM1; k=ed25519; p=<key>"
  _mta-sts.example.com. IN TXT "v=STSv1; id=20260914120000"
  mta-sts.example.com. IN CNAME mail.example.com.
  _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
  _submissions._tcp.example.com. IN SRV 0 1 465 mail.example.com.
  _submission._tcp.example.com. IN SRV 1 1 587 mail.example.com.
  _imaps._tcp.example.com. IN SRV 0 1 993 mail.example.com.
  _imap._tcp.example.com. IN SRV 1 1 143 mail.example.com.
  _pop3s._tcp.example.com. IN SRV 0 1 995 mail.example.com.
  _pop3._tcp.example.com. IN SRV 1 1 110 mail.example.com.
  _jmap._tcp.example.com. IN SRV 0 1 443 mail.example.com.
  ; and a PTR for this host's address pointing back at mail.example.com

After the domains, dns prints the host’s DANE record (see DANE (TLSA)) and ends with:

; Check what is published with: versealx-server doctor
; The `_mta-sts` id only has to change when the policy does (RFC 8461 §3.1),
;   so if one is already published and the policy has not changed, leave it.

For a domain that is not marked verified yet, dns adds a note with the command that marks it.

Summary

Each record in detail

Address records

mail.example.com. IN A 192.0.2.10
mail.example.com. IN AAAA 2001:db8::10

The host name must resolve to the address other servers and mail apps reach. doctor warns if the name resolves only to an address the internet does not route to — a 10.x, 172.16–31.x, 192.168.x or 100.64–127.x address, for example. That is expected if your own resolver answers with a private address (split-horizon DNS), but the public DNS must give the public address.

MX

example.com. IN MX 10 mail.example.com.

Other servers deliver mail for example.com to the host the MX names. If the MX still names your previous provider, mail keeps going there. doctor reports BAD when the MX names some other host.

If you add a second MX host, also list it in [mta_sts] mx, or senders that hold your MTA-STS policy will not deliver to it.

SPF

example.com. IN TXT "v=spf1 mx -all"

v=spf1 mx -all says that only the hosts your MX record names may send mail as example.com. That is right for a server that delivers mail itself.

When the server sends through a relay, the mail leaves from the relay’s addresses, so the record must name the relay too. init --relay smtp.relay.example.net prints:

example.com. IN TXT "v=spf1 mx include:relay.example.net -all"
; `include:` above is the relay's own list of sending addresses. Check
;   the name against what your provider documents — some publish it at
;   a different one — and start at `~all` if you would rather watch the
;   reports before rejecting

The include: uses the relay host’s parent domain. Check your provider’s documentation for the name it publishes its sending addresses under.

doctor compares the record with how the node actually sends. It reports BAD when a relay is configured and the record does not include it, and warn when the record includes a relay but none is configured.

DMARC

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none asks receivers to report but not to act. Read the reports for a few weeks, then move to p=quarantine and p=reject. Every domain the server hosts accepts mail at dmarc@ and tlsrpt@ even without an account of that name, and files the reports it receives there. See Email authentication.

Ownership token

_versealx-verify.example.com. IN TXT "versealx-verify=<token>"

The token is made when the domain is added. It is not secret. versealx-server admin get tenants/1/domains/example.com shows it under verification. See Domain verification for what it controls and for the other two records that also prove ownership.

DKIM

<selector>r._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=<first part>" "<rest of the key>"
<selector>e._domainkey.example.com. IN TXT "v=DKIM1; k=ed25519; p=<key>"

Every domain has two signing keys: an RSA key (selector ending in r) and an Ed25519 key (selector ending in e). The server signs every message with both, so publish both. When keys are made without a selector name, the selector is built from the date they were made.

A 2048-bit RSA public key is longer than the 255 characters one DNS text string can hold, so the RSA record is printed as two quoted strings, which is how a zone file holds it. What to enter depends on your provider:

• A zone-file import, or a form that takes several strings: enter it as printed.
• A web form with a single value field: enter only the text between the quotation marks, joined into one piece, with the quotes and the space between them removed. The provider splits it for you. Pasting the quoted form into a single field publishes the quotation marks, and the key then verifies nowhere.

doctor looks up every selector the node signs with and compares the p= value with the key in the store:

MTA-STS

_mta-sts.example.com. IN TXT "v=STSv1; id=20260914120000"
mta-sts.example.com. IN CNAME mail.example.com.

The TXT record tells sending servers that example.com has an MTA-STS policy; the CNAME lets them fetch it from https://mta-sts.example.com/.well-known/mta-sts.txt, which the server answers. The certificate must cover mta-sts.example.com.

The id is any value that changes when the policy changes. dns prints a timestamp; if a record is already published and you have not changed the policy, leave it as it is.

init configures a testing policy. The policy is served only when a mode is set and only for a verified domain. doctor checks both directions:

TLS reporting

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

A sending server that cannot negotiate TLS with yours has no other way to tell you. The reports arrive at tlsrpt@example.com and are filed by the server.

BIMI

Only for a domain that publishes a brand logo:

default._bimi.example.com. IN TXT "v=BIMI1; l=https://mail.example.com/.well-known/bimi/example.com/logo.svg; a=https://mail.example.com/.well-known/bimi/example.com/evidence.pem"

The a= part is there only when a mark certificate is published with the logo. doctor and the domain’s DNS check compare what is published with what the server would write, and warn when another BIMI record at the same name would stop receivers from showing any logo.

SRV records

_submissions._tcp.example.com. IN SRV 0 1 465 mail.example.com.
_submission._tcp.example.com. IN SRV 1 1 587 mail.example.com.
_imaps._tcp.example.com. IN SRV 0 1 993 mail.example.com.
_imap._tcp.example.com. IN SRV 1 1 143 mail.example.com.
_pop3s._tcp.example.com. IN SRV 0 1 995 mail.example.com.
_pop3._tcp.example.com. IN SRV 1 1 110 mail.example.com.
_jmap._tcp.example.com. IN SRV 0 1 443 mail.example.com.

A mail app that finds these needs only the email address. The TLS services have priority 0 and the STARTTLS services priority 1, so apps prefer TLS from the first byte. Nixt Mail uses the _jmap._tcp record to offer signing in over JMAP. The ports in the records are the default ports; if you move a listener, change the record.

Autoconfig and Autodiscover names (optional)

The server answers Mozilla autoconfig at autoconfig.<domain> and Microsoft Autodiscover at autodiscover.<domain>. To use them, add names that point at the server and include them in the certificate:

autoconfig.example.com. IN CNAME mail.example.com.
autodiscover.example.com. IN CNAME mail.example.com.

See Connecting mail apps.

Reverse DNS (PTR)

10.2.0.192.in-addr.arpa. IN PTR mail.example.com.

The PTR record belongs to whoever owns the address. Ask your ISP or hosting provider to set it; your domain’s DNS provider cannot. doctor checks that the host name resolves, that each address (up to two) has a PTR, and that the PTR name resolves back to the same address:

DANE (TLSA)

_25._tcp.mail.example.com. IN TLSA 3 1 1 <SHA-256 of the certificate's public key>
; DANE, and only worth publishing on a DNSSEC-signed zone (RFC 7672 §2): it
;   pins the key the certificate now carries, so it has to be republished
;   whenever that key changes or DANE-validating senders will refuse mail

DANE is optional and needs a DNS provider that offers the TLSA record type on a DNSSEC-signed zone. The record pins the key your certificate carries (usage 3, selector 1, matching type 1). ACME renewals keep the key; to change it safely, see TLS certificates.

init does not print this record, because the certificate you start with is often not the one you keep. When the certificate cannot be read, dns prints a note instead of a record: a wrong TLSA record refuses mail rather than degrading.

Entering records at a DNS provider

Control panels differ, but the same mistakes come up:

• The host or name field usually takes only the part in front of your domain. Enter _dmarc, mail, _mta-sts or <selector>r._domainkey, and @ for the domain itself. A field that silently appends the domain turns _dmarc.example.com into _dmarc.example.com.example.com, which resolves and means nothing.
• Some panels need a setting before MX records take effect, such as choosing custom mail servers. Without it, mail keeps going where the previous setting pointed.
• Long TXT values: see DKIM above.
• SRV records are usually their own record type with separate fields for service, protocol, priority, weight, port and target.
• TLSA is not offered by every provider. Without it you cannot publish DANE; MTA-STS protects delivery to you instead.
• Switch on DNSSEC if your provider offers it. It lets other servers trust your records, is required for DANE, and lets “no such record” answers be cached.

After publishing

1. Run versealx-server doctor and fix what it reports. Records can take a while to appear.
2. When the ownership token is published, run versealx-server admin post tenants/1/domains/example.com/verify.
3. Run versealx-server dns again whenever you add a domain, rotate DKIM keys or change the certificate’s key.