Reference
DNS record types a website depends on
A website and its email rest on about fifteen DNS record types: A and AAAA for addresses, CNAME for aliases, NS and SOA for the zone itself, MX for mail, TXT for SPF, DMARC and DKIM, CAA for certificate issuance, DS and DNSKEY for DNSSEC, PTR for reverse lookups, SRV for services, and the newer HTTPS and SVCB records. Each has a number assigned by IANA and an RFC that defines its content, and a missing or contradictory record is one of the few failures that takes a whole domain offline at once.
| Type | Number | What it holds | Defined in | Queried by the scan |
|---|---|---|---|---|
| A | 1 | An IPv4 address for the name. | RFC 1035 | Yes: the apex, and every mail exchanger host. |
| AAAA | 28 | An IPv6 address for the name. | RFC 3596 | Yes: the apex, and every mail exchanger host. |
| CNAME | 5 | An alias: the name is another name, and resolution continues there. A name with a CNAME holds no other data. | RFC 1035 | Yes: the chain is followed for the apex and the www hostname. |
| NS | 2 | An authoritative nameserver for the zone. | RFC 1035 | Yes: compared with the nameservers the registry publishes. |
| SOA | 6 | The start of authority: the zone's primary nameserver, contact, serial number and timers. | RFC 1035 | No. |
| MX | 15 | A mail exchanger for the domain, with a preference number. | RFC 1035 | Yes: presence, resolution of each host, redundancy and reverse DNS. |
| TXT | 16 | Free-form text strings; carries SPF, DMARC, DKIM keys, MTA-STS, TLS-RPT and BIMI records, and domain verification tokens. | RFC 1035 | Yes: the apex and the email-authentication names. Only the record kind of apex TXT values is kept, never their payload. |
| PTR | 12 | A pointer from an address back to a name, published in the reverse zone. | RFC 1035 | Yes: for the site's addresses and the mail exchangers'. |
| SRV | 33 | The host and port of a named service, with priority and weight. | RFC 2782 | Yes: for a fixed list of well-known service names. |
| CAA | 257 | Which certificate authorities may issue certificates for the domain. | RFC 8659 | Yes: the apex. |
| DS | 43 | A hash of the zone's key, published in the parent zone; it is what links the zone into the DNSSEC chain of trust. | RFC 4034 | Yes: its presence is what marks the zone as signed. |
| DNSKEY | 48 | A public key used to verify the zone's DNSSEC signatures. | RFC 4034 | Yes: presence only; key material is not kept. |
| TLSA | 52 | A certificate or public-key association for a TLS service (DANE), valid only in a DNSSEC-signed zone. | RFC 6698 | No. |
| SVCB | 64 | Service binding: alternative endpoints and connection parameters for a service. | RFC 9460 | No. |
| HTTPS | 65 | The SVCB form for HTTPS origins: supported protocols such as HTTP/3, alternative endpoints, and hints, including at the zone apex. | RFC 9460 | No. |
The records that decide whether a site answers
A and AAAA are what a browser finally needs: an address to connect to. A name either carries them directly or reaches them through a CNAME, which says the name is an alias of another.
A CNAME excludes every other record on the same name. That is why the zone apex cannot carry one — the apex must hold NS and SOA records — and why a CNAME published next to an A record is a conflict that different resolvers can settle differently.
NS records name the servers that answer for the zone, and they are published twice: in the zone itself and at the registry. When the two lists disagree, some resolvers ask servers that no longer hold the zone.
The HTTPS record, defined in RFC 9460, lets a zone announce that an origin supports HTTP/3 or other connection parameters before the first request, and gives the apex a way to point at another host without a CNAME.
The records that decide whether email and certificates work
MX names the servers that accept mail for the domain, in preference order. Each host it names must resolve through A or AAAA: RFC 2181 forbids an MX target that is an alias, and an MX pointing at a name that does not resolve loses mail.
TXT is a container rather than a meaning. SPF is a TXT record at the domain, DMARC one at `_dmarc`, a DKIM key one at `selector._domainkey`, and MTA-STS and TLS-RPT use `_mta-sts` and `_smtp._tls`. A TXT lookup returns every TXT record published at that name, and the reader picks the one that starts with the right version tag.
CAA lists the certificate authorities allowed to issue for the domain. An authority is required to check it before issuing, so a CAA record that forgets the authority a site actually uses makes the next renewal fail.
DS and DNSKEY are the two halves of DNSSEC: the key in the zone and its hash at the parent. A DNSKEY without a matching DS means the zone is signed but nobody can verify it; a DS without a valid key makes validating resolvers refuse the whole domain.
What a scan queries, and how
Every lookup goes through DNS over HTTPS to public resolvers. For the apex the scan asks for A, AAAA, NS, MX, CAA, DS, DNSKEY and TXT, follows the CNAME chain of the apex and of `www`, queries SRV for a fixed list of well-known services, and asks for PTR on the addresses it found.
The findings come from several checks: `dns.resolution` and `dns.ipv6` for the addresses, `dns.cname` and `dns.conflicts` for aliases, `dns.nameservers` and `dns.nameserver_consistency` for NS, `dns.caa`, `dns.dnssec`, `dns.ptr`, `dns.srv` and `dns.ttl`, and `dns.propagation`, which compares the answers of several public resolvers.
TXT payloads can carry verification tokens and keys, so from the apex only the kind of each record — the part before its first separator — is kept in the report.
SOA, TLSA, SVCB and HTTPS are not queried. Their absence from a report says nothing about whether the zone publishes them.
Frequently asked questions
- Why can't the apex of a domain be a CNAME?
- Because a name with a CNAME may hold no other record, and the apex must hold the zone's NS and SOA records. DNS providers offer vendor-specific alias records to work around it, and the HTTPS record type from RFC 9460 gives the protocol its own way to point the apex elsewhere.
- Where are SPF and DMARC stored in DNS?
- Both are TXT records. SPF is published at the domain itself and starts with v=spf1; DMARC is published at the _dmarc name under the domain and starts with v=DMARC1. The old dedicated SPF record type is no longer used.
- What does the number next to a record type mean?
- It is the type code carried in DNS messages, assigned by IANA. Tools display the mnemonic, such as MX, but on the wire an MX query asks for type 15 and a CAA query for type 257.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website