DNS Helper

Example setups

The other pages explain one record at a time. This one shows them together, as two complete setups for the same fictional domain, example.com: a basic one that covers what most domains need, and one with everything switched on. Every record links to the page that explains it. The names, addresses and providers are all reserved for documentation, so nothing here points at anything real, and keys and tokens are shortened. TTLs are left out, your panel's default is fine for all of them.

"(apex)" stands for the domain itself, which your panel may want as an empty field, @ or the full name, see the Interface page. Neither setup uses a wildcard record, for the reason given there.

Basic: a website and mail at a provider

A site on a web host and mailboxes at a mail provider. This is the setup most domains need, and every line in it is worth having.

The two NS records are chosen at the registrar rather than typed into the zone, and an SOA record exists as well, managed by your DNS provider, see Zone file & SOA. The DMARC record starts at p=none, collecting reports before anything is blocked, which is the usual first step. The values from the mail provider (the MX target, the SPF include and the DKIM key) come from that provider's own instructions.

Fancy: everything switched on

This one is modelled on the DNS behind this site and its sibling, hostingdetails.eu, and it is more than a typical domain needs. It assumes the zone is signed with DNSSEC, which the TLSA records depend on; DNSSEC itself is switched on at your DNS provider and registrar, not typed in as records. A few records are additions, not part of that real setup, so that every record page on this site appears once; the text says which.

The website

Here www has its own A and AAAA records instead of a CNAME, the other common way to make it match the apex. The HTTPS record tells browsers up front that the site speaks HTTP/2. The TXT record is a site verification for a search engine, next to the SPF record further down: one name can carry several TXT records.

Mail, with its own server

Mail goes to the domain's own server first, with the provider's server as a backup at a lower priority. Two DKIM selectors are published at the same time, the way a key is rotated: the new one goes live next to the old one, and the old one is removed once nothing signs with it any more. DMARC is at its strictest, for subdomains and for names that do not exist as well, and sends its reports to another domain, which has to agree to receive them, see the last table.

Mail transport and the logo

MTA-STS is two parts: the TXT record, and a policy file served over HTTPS from the mta-sts host. TLS-RPT asks for reports about failed encrypted deliveries, and BIMI points at the logo, which only shows because DMARC is at p=reject.

Certificates and DANE

CAA allows one certificate authority, refuses wildcard certificates, and says where to report a refused request. The TLSA records pin the certificate authority's intermediates (2 1 1), shortened here to two per name; in practice there is one record for every current and announced intermediate of that certificate authority. Pinning your own key instead (3 1 1) is stricter, and more work, see the TLSA / DANE page.

Subdomains

The www and mta-sts names never send mail, and their own SPF record says so. Everything from static down is an addition for illustration: a subdomain that receives no mail either, said with a null MX; _acme-challenge delegated with a CNAME, so certificates can be renewed automatically with DNS-01 even when the DNS provider has no API; an SRV record for a Matrix server; and lab handed over to other name servers.

The other side: the domain that collects reports

These records live on example.net, the domain the DMARC and TLS-RPT reports above are sent to.

The first record is the one that matters: without it, mail servers ignore the request to send example.com's DMARC reports to example.net. A domain collecting reports for many others publishes one of these per domain. The rest says that example.net itself never sends mail: an SPF record with nothing allowed, and an empty DKIM key for every possible selector.

Checking a real domain against all of this is what Expert Tools and the Security Scan on hostingdetails.eu are for.