dotvitals

The domain apex is a CNAME, which the DNS does not allow

HighConfirmeddns.records.apex-cname

What this check looks for

Your domain's root name points at another name instead of at an address. The DNS forbids this, and the usual symptom is that email stops arriving while the website appears to work.

Why it matters

The apex must carry SOA and NS records, and a CNAME may not coexist with any other record. Resolvers handle the conflict differently: some ignore your MX records entirely, so mail is silently delivered to whoever the CNAME target's MX points at, or bounced.

When the check passes, your report says: “The domain apex uses address records, as the DNS requires”.

What it costs your score

When this check fails it removes 15 points from your DNS score, before the status, confidence and repeat multipliers are applied. DNS carries a weight of 10 in the overall score.

It shares the dns.records.address family ceiling of 30 points: however many findings that family produces, together they cannot remove more than that from DNS. One underlying problem showing up in several places is still one problem.

Severity
high
Default confidence
confirmed
Status when triggered
fail
Deduction
15 points
Family cap
dns.records.address · 30
Category
DNS
Module
Dns records
Fix owned by
dns host
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Replace the apex CNAME with an A/AAAA record, or with your provider's ALIAS/ANAME record type.

A CNAME at the apex breaks MX lookups and any other record you publish there.

  1. Note the current CNAME target ‹cname target› before deleting anything.

  2. If your DNS host offers ALIAS, ANAME or CNAME flattening, change the record type to that and keep the same target — this is the intended replacement.

  3. If it does not, resolve ‹cname target› to its addresses and publish those as A and AAAA records, and set a reminder to re-check them if the target is not a fixed address.

  4. Re-publish any MX, TXT or CAA records that were being ignored while the CNAME was present.

How to confirm it worked

  • dig +short CNAME ‹domain› — expect no answer

  • dig +short MX ‹domain› — expect your mail servers

The configuration to publish
{{domain}}. 3600 IN A {{ipv4}}

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Generic DNS
‹domain›. 3600 IN A ‹ipv4›
Cloudflare
Cloudflare flattens a root CNAME automatically. DNS → Records → edit the root CNAME and confirm the orange cloud is on, or replace it with an A record.
Technical detail

A CNAME record was found at the apex ‹domain›, pointing at ‹cname target›. RFC 1034 §3.6.2 and RFC 2181 §10.1 are explicit: if a CNAME is present at a name, no other data may be. The apex always has SOA and NS, so the combination is invalid however many providers accept the configuration. Providers that advertise "CNAME at root" implement it as ALIAS/ANAME/flattening, which resolves the target and publishes an A record — that is a different record type and it is the correct fix.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the dns records checkerBuild the fix

Other dns records checks