DNS is the lookup that turns a domain into everything a browser or a mail server needs to know about it: where to connect, where to send mail, and who is allowed to send mail claiming to be from it. The checker above reads that answer from two independent public resolvers — Google’s and Cloudflare’s — because the case worth catching is exactly the one where they disagree.

The record types, briefly

• A — the IPv4 address a hostname points to.
• AAAA — the IPv6 address, the newer address space most sites now also publish.
• MX — which mail servers accept email for this domain, and in what priority order.
• TXT — free-form text; in practice mostly domain verification codes, SPF and DMARC policies.
• NS — which nameservers are authoritative for the domain — the ones everyone else’s resolvers ultimately ask.
• CNAME — an alias: this name is really that other name, resolve it and follow.
• SOA — the zone’s own bookkeeping: the primary nameserver, an admin contact, and the refresh and retry timers other nameservers use.

Why the same domain can answer differently

DNS is deliberately cached at every layer — your OS, your router, your ISP’s resolver, and the public resolver you asked — each holding an answer until its TTL (time to live) expires. Change a record and the old answer keeps circulating in whichever cache has not yet expired it, which is what “propagation” means: not a signal travelling anywhere, but stale copies aging out at different times.

Querying two independent resolvers is a real test of this, in a way one resolver never can be. If Google and Cloudflare already agree, the change is not just propagated to you — it is propagated, full stop. If they disagree, you are mid-change, and the number worth knowing is the TTL on the old record: that is the longest it can take from here.

SPF: who is allowed to send your mail

SPF (Sender Policy Framework) is a TXT record naming the servers allowed to send email as your domain:

v=spf1 include:_spf.google.com ~all

• Exactly one SPF record per domain — two is invalid and receiving servers are told to treat SPF as a permanent error, which is worse than having none.
• include: pulls in another provider’s server list, and each one is a DNS lookup. RFC 7208 caps SPF evaluation at ten total lookups; past that, SPF fails closed regardless of who actually sent the mail.
• The ending mechanism says what to do with mail from anyone not listed: -all (fail — reject), ~all (soft fail — usually delivered, flagged), ?all (neutral), +all (pass everyone, which defeats the point of having SPF at all).

DMARC: what to do when SPF or DKIM fails

DMARC sits on top of SPF and DKIM and answers the question neither of them does: what should happen to a message that fails authentication, and who should hear about it.

v=DMARC1; p=quarantine; rua=mailto:reports@example.com

p=none only collects reports — a safe starting point while you confirm your own mail passes cleanly. p=quarantine sends failures to spam. p=reject refuses them outright. The usual path is none, watch the reports for a few weeks, then quarantine, then reject — moving straight to reject on day one risks losing legitimate mail you did not know needed fixing.

Reverse DNS (PTR)

A PTR record is the other direction: given an IP address, what hostname claims it. Mail servers check this on incoming connections, and a missing or mismatched PTR is one of the fastest ways to be flagged as spam — it is set by whoever controls the IP block (usually your hosting provider), not by your own DNS zone.

Frequently asked

How long does a DNS change take to apply everywhere?

Up to the old record’s TTL, from the moment each cache last fetched it — commonly minutes to 24–48 hours. Lowering the TTL a day before a planned change is the standard way to make the change itself faster to take effect.

Why do I have both an A and a CNAME warning?

A name cannot be both — RFC 1034 forbids a CNAME coexisting with any other record type for the same name. Something is misconfigured if a resolver reports both.

Does this tool see what my computer sees?

Not exactly — it asks Google’s and Cloudflare’s resolvers from Bold Pilot’s server, not your own ISP’s resolver. If your computer still shows an old answer after this tool shows the new one, the stale copy is in a cache closer to you (your router or your ISP) and will clear on its own once its TTL expires.

Is there a paid part to this?

No. DNS-over-HTTPS is a free, public, keyless API — the same lookup a browser makes when you turn on “secure DNS”. Nothing here costs Bold Pilot anything to run, which is why it costs you nothing either.