How the Domain Trust Score is calculated

What we check

The NS records the parent zone publishes, compared with the NS records inside the zone itself.

Why it matters

These are two separate record sets and nothing forces them to agree. When they drift, some resolvers follow the parent and some follow the zone, so a nameserver you thought you retired keeps answering for a share of the internet.

How to fix it

Make the in-zone NS RRset and the delegation at your registrar list exactly the same hostnames. Change the zone first, wait out the old TTL, then change the registrar.

CertaDNS can automate this with Managed DNS.

What we check

How many nameservers are published for the zone.

Why it matters

A single nameserver is a single point of failure for every service on the domain. RFC 1034 has asked for at least two since 1987, and most registries require it.

How to fix it

Add a second nameserver on different infrastructure and publish it in both the in-zone NS RRset and the registrar delegation.

CertaDNS can automate this with Managed DNS.

What we check

Whether the published nameservers resolve to addresses in different network prefixes.

Why it matters

Two nameservers in the same /24 fail together. Diversity is what makes the second one worth having.

How to fix it

Place your nameservers in different networks, ideally with different providers or on an anycast fleet with multiple points of presence.

CertaDNS can automate this with Managed DNS.

What we check

Each published nameserver queried directly for the zone's SOA, checking it answers and sets the AA flag.

Why it matters

A delegated nameserver that does not answer, or answers without authority, is a lame delegation. Resolvers still try it, so a share of your queries take a timeout before failing over — which is what people describe as the site being 'slow sometimes'.

How to fix it

Remove nameservers that no longer host the zone from the delegation, or fix the zone's configuration on those servers so they are authoritative for it.

CertaDNS can automate this with Managed DNS.

What we check

Whether the zone apex publishes a Start of Authority record.

Why it matters

The SOA is what makes a zone a zone. Without it the zone is not properly formed and secondary transfers and negative caching have nothing to work from.

How to fix it

Publish an SOA at the zone apex. Any authoritative DNS provider creates one for you.

CertaDNS can automate this with Managed DNS.

What we check

The refresh, retry, expire and minimum fields of the SOA against the ranges in RFC 1912 §2.2.

Why it matters

The expire value decides how long your secondaries keep serving after they lose contact with the primary. Set it too low and a brief outage takes the whole domain off the internet; the minimum field sets negative-cache TTL, so setting it high means a typo'd record stays broken for hours after you fix it.

How to fix it

Reasonable starting values: refresh 3600–86400, retry 600–7200, expire 1209600 (two weeks), minimum 300–3600.

CertaDNS can automate this with Managed DNS.

What we check

The SOA serial reported by each nameserver, queried directly and compared.

Why it matters

Disagreeing serials mean a secondary did not get the last change. It will keep serving the old answer until the next successful transfer, so a fraction of your users see stale records with no error anywhere.

How to fix it

Check that NOTIFY reaches every secondary and that each one is permitted to transfer the zone. A serial that never advances usually means the primary is not bumping it on change.

CertaDNS can automate this with Managed DNS.

What we check

A DS record at the parent, a matching DNSKEY in the zone, and a digest that links them.

Why it matters

Without DNSSEC, a resolver has no way to tell your answers from forged ones. With a DS at the parent but no working key in the zone, validating resolvers fail closed and your domain disappears for them entirely — which is worse than being unsigned.

How to fix it

Enable DNSSEC at your DNS provider, then publish the DS record at your registrar. Always in that order: a DS record pointing at a key that does not exist takes the domain down for every validating resolver.

CertaDNS can automate this with Managed DNS.

What we check

Whether the zone publishes a CAA record naming which certificate authorities may issue for it.

Why it matters

Without CAA, any public CA will issue a certificate for your domain to anyone who can pass its validation. CAA narrows that to the authorities you actually use.

How to fix it

Publish a CAA record at the apex naming your CA, e.g. `example.com. CAA 0 issue "letsencrypt.org"`. Add every CA you use, including any your CDN or load balancer issues through, before you rely on it.

CertaDNS can automate this with Managed DNS.

What we check

An AXFR attempted against each published nameserver.

Why it matters

A nameserver that hands the full zone to anyone who asks publishes your entire internal naming — every host, every staging environment, every service you did not mean to advertise. It is the single most useful thing an attacker can be given for free.

How to fix it

Restrict AXFR to your secondary nameservers' addresses, and prefer TSIG over address-based ACLs.

CertaDNS can automate this with Managed DNS.

What we check

A TXT record at the apex beginning with v=spf1.

Why it matters

SPF is how a receiver checks whether the server that delivered a message is one you authorised. Without it, one of the two things DMARC can align on is simply missing.

How to fix it

Publish a TXT record at the apex listing your senders, e.g. `v=spf1 include:_spf.google.com -all`. If the domain sends no mail at all, publish `v=spf1 -all`, which is a stronger statement than publishing nothing.

CertaDNS can automate this with Email Authentication.

What we check

How many TXT records at the apex begin with v=spf1.

Why it matters

RFC 7208 §4.5 says a domain with more than one SPF record is a permerror. Receivers do not pick the better one — SPF simply fails, which usually breaks DMARC alignment at the same time.

How to fix it

Merge every SPF record into one TXT record. Two providers each telling you to 'add this record' is how this happens; combine their mechanisms instead.

CertaDNS can automate this with Email Authentication.

What we check

Every include, a, mx, ptr, exists and redirect term, resolved recursively and counted.

Why it matters

RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups. Go over and conforming receivers return permerror, which fails SPF for your legitimate mail — not just for spoofers. Adding one more SaaS sender is usually what tips a domain over.

How to fix it

Remove includes for services you no longer use, then flatten what remains into explicit ip4/ip6 ranges. Flattening is a maintenance commitment: your providers' addresses change, and a stale flattened record fails closed.

CertaDNS can automate this with Email Authentication.

What we check

The terminal mechanism of the SPF record.

Why it matters

`+all` authorises the entire internet to send as your domain, which is worse than having no SPF record. `?all` (neutral) tells receivers to treat the result as if there were no policy, so it buys nothing.

How to fix it

End the record with `-all` (hard fail) once you are confident every sender is listed, or `~all` (soft fail) while you are still finding them. Never `+all`.

CertaDNS can automate this with Email Authentication.

What we check

A set of selectors in common use by the major providers, probed at <selector>._domainkey.

Why it matters

DKIM survives forwarding, where SPF does not, so it is usually the mechanism keeping DMARC aligned for mailing-list and forwarded mail.

How to fix it

Enable DKIM signing at each sending provider and publish the public key they give you at the selector they name.

CertaDNS can automate this with Email Authentication.

What we check

A TXT record at _dmarc.<domain> beginning with v=DMARC1.

Why it matters

DMARC is the part that ties SPF and DKIM to the address a human actually sees, and the only part that tells receivers what to do on failure. Without it, SPF and DKIM mostly generate information nobody acts on.

How to fix it

Publish `v=DMARC1; p=none; rua=mailto:you@example.com` at _dmarc.<domain> to start collecting reports, then tighten the policy once the reports show your legitimate senders passing.

CertaDNS can automate this with Email Authentication.

What we check

The p= tag of the DMARC record.

Why it matters

p=none asks receivers to do nothing. It is the right place to start and the wrong place to stop: a domain sitting at p=none is exactly as spoofable as one with no DMARC at all, it just generates reports about it.

How to fix it

Move to p=quarantine, then p=reject, once your aggregate reports show your real senders passing. Do not jump straight to reject on a domain you have not been monitoring — you will bounce your own mail.

CertaDNS can automate this with Email Authentication.

What we check

The rua= tag of the DMARC record.

Why it matters

Aggregate reports are the only view you get of who is sending as your domain and whether they pass. Without rua you cannot safely tighten the policy, because you have no way to know what you are about to break.

How to fix it

Add `rua=mailto:dmarc@example.com` to the DMARC record. Send it somewhere that can parse the XML — the raw reports are not readable by hand at any volume.

CertaDNS can automate this with Email Authentication.

What we check

The pct= tag of the DMARC record.

Why it matters

pct= applies the policy to a sample of your mail. It is a useful ramp while rolling out enforcement and a liability if you forget it there — pct=10 at p=reject means nine in ten spoofed messages are still delivered.

How to fix it

Remove the pct= tag, or set it to 100, once the rollout is finished.

CertaDNS can automate this with Email Authentication.

What we check

The sp= tag, and whether subdomains inherit an enforcing policy.

Why it matters

Subdomains inherit the organisational policy unless sp= overrides it. An sp=none under an enforcing p= leaves every subdomain spoofable — and attackers prefer subdomains precisely because they look more plausible than a look-alike domain.

How to fix it

Either remove sp= so subdomains inherit your p= value, or set sp= to the same level of enforcement.

CertaDNS can automate this with Email Authentication.

What we check

When rua points at a different domain, the authorisation record that domain must publish.

Why it matters

RFC 7489 §7.1: to send reports to a mailbox on another domain, THAT domain must publish `<your-domain>._report._dmarc.<their-domain>` allowing it. Without that record, conforming receivers silently drop the reports — so the usual symptom is DMARC that looks configured and produces nothing.

How to fix it

Publish `<your-domain>._report._dmarc.<their-domain> TXT "v=DMARC1"` on the destination domain, or point rua at a mailbox on your own domain.

CertaDNS can automate this with Email Authentication.

What we check

The MX RRset at the apex, and whether each named host resolves.

Why it matters

An MX pointing at a hostname that no longer resolves silently loses inbound mail. Senders retry for a few days and then bounce it.

How to fix it

Publish MX records pointing at hostnames that resolve to your mail servers. MX targets must be hostnames with address records — never an IP, never a CNAME.

CertaDNS can automate this with Managed DNS.

What we check

A connection to each MX host on port 25, checking whether STARTTLS is advertised.

Why it matters

Without STARTTLS, mail to you crosses the internet in plaintext. Every mainstream provider offers it; a server that does not is usually an old appliance nobody has looked at in years.

How to fix it

Enable STARTTLS on your mail servers with a valid certificate for the MX hostname.

What we check

The _mta-sts TXT record and the policy file at mta-sts.<domain>/.well-known/mta-sts.txt.

Why it matters

STARTTLS on its own is trivially stripped: an attacker in the path removes the offer and the sending server falls back to plaintext without complaint. MTA-STS is what makes that fallback a delivery failure instead.

How to fix it

Publish a _mta-sts TXT record and serve a policy file over HTTPS at mta-sts.<domain>. The policy host needs its own valid certificate, and both have to stay in sync when your MX hosts change.

CertaDNS can automate this with Email Authentication.

What we check

The mode field of the published policy.

Why it matters

In testing mode failures are reported and the mail is delivered anyway, so the downgrade attack still works. Only enforce mode actually closes it.

How to fix it

Set `mode: enforce` in the policy file once TLS-RPT shows no legitimate senders failing, and bump the policy id so senders pick up the change.

CertaDNS can automate this with Email Authentication.

What we check

The mx: entries in the policy file, compared with the live MX RRset.

Why it matters

A sender that honours your policy will refuse to deliver to an MX host the policy does not list. So an MX change that is not mirrored into the policy file does not degrade delivery — it stops it, for exactly the senders doing the right thing.

How to fix it

Update the mx: entries in the policy file whenever your MX records change, and bump the policy id in the TXT record so senders re-fetch it.

CertaDNS can automate this with Email Authentication.

What we check

A TXT record at _smtp._tls.<domain>.

Why it matters

TLS-RPT is how senders tell you they could not deliver securely. Without it, an MTA-STS policy that is quietly breaking delivery looks exactly like one that is working.

How to fix it

Publish `v=TLSRPTv1; rua=mailto:tlsrpt@example.com` at _smtp._tls.<domain>.

CertaDNS can automate this with Email Authentication.

What we check

The BIMI record at default._bimi, the logo it points to, and that logo against the SVG Tiny PS profile.

Why it matters

BIMI puts your logo beside your mail in supporting inboxes. It does nothing until DMARC is at enforcement, which is why this is only assessed once that is true.

How to fix it

Publish a BIMI record pointing at a square SVG Tiny PS logo. Gmail and Apple Mail additionally require a Verified Mark Certificate, which is bought from a certificate authority.

CertaDNS can automate this with BIMI.

What we check

A sample of typo and keyword variants of your domain, checked for whether they resolve.

Why it matters

A variant that resolves has infrastructure behind it — the step between someone parking a typo and someone using it. Some of these will be your own defensive registrations, and DNS gives us no way to tell which: ownership is a registrar question, not a DNS one. That is why this is reported and not scored.

How to fix it

Work out which of these are yours. For the rest, the useful move is watching them rather than chasing them — a look-alike that suddenly gains a certificate or a mail server is about to be used, and that transition is the signal worth alerting on.

CertaDNS can automate this with Brand Monitoring.

What we check

The same sample, checked for MX records.

Why it matters

A look-alike with an MX can send mail as itself and receive the replies. That is a phishing campaign with the hard part already done, and the usual target is your customers or your finance team rather than you. As above, some of these will be your own.

How to fix it

For the ones that are not yours: report them to the registrar and the hosting provider, and add them to whatever blocklist your own mail filtering uses. Speed matters more than thoroughness here — these get registered and used within days, so knowing on day one is worth more than a complete inventory on day thirty.

CertaDNS can automate this with Brand Monitoring.