The catalogue
Every check, by name.
No vendor publishes this list, which has always seemed odd — it is the only part of a validation claim you can actually check. Here is ours, generated from the code that implements it.
- 27 errors
- Blocks the apply. Nobody can override it, at any skill level.
- 25 warnings
- Must be read and accepted by name, and the acceptance is recorded.
- 4 infos
- Noted on the change and in the write-up. Does not interrupt.
56 checks
-
a-record-must-be-ipv4errorAn A record's value must be a dotted-quad IPv4 address.
-
aaaa-record-must-be-ipv6errorAn AAAA record's value must be an IPv6 address.
-
address-includes-cidr-or-porterrorCatches an address pasted with a prefix length or port still attached, which is a very common copy-and-paste error from firewall and hosting consoles.
-
apex-must-resolvewarningWarns when the apex would be left with no address record at all.
-
caa-blocks-issuancewarningWarns when a CAA set would block the CA the customer actually uses.
-
caa-record-formaterrorValidates CAA tag, flags and value per RFC 8659.
-
cname-chainwarningFlags a CNAME whose target is another CNAME in the same zone.
-
cname-must-not-coexisterrorA CNAME cannot coexist with any other record at the same name (RFC 1034 §3.6.2).
-
cname-must-not-point-to-itselferrorA CNAME pointing at its own name creates a resolution loop.
-
cname-not-at-apexerrorA CNAME cannot sit at the zone apex, because the apex must carry SOA and NS records.
-
cname-target-must-be-hostnameerrorA CNAME target must be a hostname, never an IP address.
-
create-over-existing-namewarningPoints out that a name being created already exists with a different value, which usually means the engineer meant to edit rather than add.
-
delegation-changewarningChanging NS records at the apex moves authority for the entire zone, and every NS value has to be the name of a nameserver.
-
delegation-target-must-not-be-cnameerrorNS and SRV targets must not be aliases, for the same reason as MX.
-
delete-target-existswarningWarns when a delete targets a record that is not present in the zone.
-
dkim-key-must-be-base64errorA DKIM public key must be valid base64, or verification fails silently.
-
dkim-record-formatwarningChecks DKIM records are published at a selector name and look like a key.
-
dmarc-enforcement-warningwarningWarns before an enforcing DMARC policy is published without a monitoring period.
-
dmarc-only-one-recorderrorOnly one DMARC record may exist at a name.
-
dmarc-record-formaterrorA DMARC record must live at _dmarc and begin with the version token.
-
duplicate-recordwarningCatches an identical record being created when one already exists.
-
ipv4-octet-leading-zeroerrorLeading zeros in an IPv4 octet are ambiguous: some resolvers read them as octal.
-
lower-ttl-before-migrationwarningReminds engineers to lower TTLs ahead of a migration rather than at the moment of cutover.
-
mail-transport-security-formatwarningRecognises MTA-STS and TLS-RPT records and checks their basic shape.
-
mail-without-spfwarningWarns when a change would leave a mail-accepting domain with no SPF record.
-
mx-duplicate-priorityinfoWarns when several MX records share a preference by accident.
-
mx-priority-embedded-in-valueerrorCatches an MX priority typed into the value, which is the single most common MX mistake.
-
mx-priority-rangeerrorMX preference must fit in the 16-bit field defined by RFC 1035.
-
mx-removal-stops-mailwarningWarns loudly when the last MX record for a domain is being removed.
-
mx-requires-manual-verificationwarningEvery MX value gets a human check. The brief mandates this and it is not configurable off.
-
mx-target-must-not-be-cnamewarningAn MX target that is itself a CNAME is explicitly disallowed by RFC 2181.
-
mx-target-must-not-be-iperrorAn MX target must be a hostname: not an IP address, and not a malformed name either.
-
null-mx-usageerrorRecognises the RFC 7505 "null MX" and checks it is used correctly.
-
orphaned-referencewarningWarns when a change silently orphans records that pointed at what is being removed.
-
private-address-in-public-zonewarningCatches a public DNS record pointing at a private address — an MSP classic, usually caused by copying an internal address out of a firewall or hypervisor console.
-
provider-supports-record-typeerrorRejects a change that uses a record type the target provider cannot store.
-
ptr-target-must-be-hostnameerrorA PTR target must be a hostname: not an IP address, and not a malformed name either.
-
record-name-should-be-relativeerrorCatches a fully qualified record name that would be appended to the zone again.
-
record-name-syntaxerrorThe record's own name must be a syntactically valid DNS name.
-
record-value-requirederrorEvery create and update must carry a value.
-
rrset-ttl-must-matchwarningEvery record in an RRset — same name, same type — must share a TTL (RFC 2181 §5.2).
-
soa-manual-editwarningThe SOA record is managed by the provider and should rarely be edited by hand.
-
spf-all-mechanismwarningFlags an SPF record with no all mechanism, or one that authorises everything.
-
spf-lookup-limitwarningSPF permits at most ten DNS-querying mechanisms; exceeding it fails the whole record.
-
spf-must-start-with-versionerrorAn SPF record must begin with the version token.
-
spf-ptr-mechanism-deprecatedwarningThe ptr mechanism is deprecated and slow; RFC 7208 advises against using it.
-
spf-single-recorderrorA domain must publish at most one SPF record.
-
spf-terms-after-all-ignoredwarningAnything after the SPF all mechanism is silently ignored.
-
srv-record-formaterrorValidates SRV naming and its numeric fields per RFC 2782.
-
trailing-dot-in-valueinfoFlags a value that arrives with a trailing dot. The platform stores targets unqualified and each adapter applies its own provider's convention, so a stray dot here usually means a copy-paste straight out of a zone file.
-
ttl-must-be-allowed-valueerrorSome providers accept only a fixed list of TTL values — ClouDNS is one — so an ordinary value such as 600 is rejected outright.
-
ttl-within-provider-limitserrorRejects a TTL the target provider will not accept, before the apply fails.
-
txt-string-lengthwarningA TXT string longer than 255 characters must be split into multiple quoted strings.
-
txt-unescaped-quotewarningTXT values containing unescaped quotes usually indicate a copy-paste problem.
-
very-low-ttlinfoFlags a very short TTL left in place after a migration.
-
wildcard-recordinfoFlags a wildcard record, which is easy to create and easy to forget about.
Nothing matches that. The rules are named after what they catch, so try the record type
(mx, txt) or the failure (apex, lookup).
Questions about the checks
What DNS validation checks does DNSMentor run?
DNSMentor runs 56 validation checks before any change is applied: 27 errors that block the change outright, 25 warnings that must be acknowledged by name, and 4 informational notes. They cover record syntax, address hygiene, zone structure, mail authentication (SPF, DKIM, DMARC), service records and TTL sanity.
Can DNS validation rules be overridden?
No error can be overridden, by anybody, at any skill level. Warnings can be accepted but must be read and acknowledged by name, and the acknowledgement is recorded in the audit trail against the person who gave it. One rule — manual verification of MX values — cannot be switched off under any configuration.
Why do checks run against the whole zone rather than the record being edited?
Because the most damaging DNS mistakes are records that are individually valid and only wrong in context. A second SPF record is a perfectly valid TXT record; what makes it fatal is the one already in the zone. DNSMentor evaluates the zone as it would exist after the change, which is the only way that class of fault can be caught.
Bring the zone you inherited.
The one nobody documented, at the client nobody wants to touch. Half an hour, and you will know what is in it.
No card. No trial clock. UK-hosted, and we will tell you which providers we have actually proven before you ask.
Last updated