canva.com

com into the IP addresses mail servers and verification metadata your browser mail client and SaaS integrations actually need. This report is a point-in-time snapshot from CheckFast's runtime recursive resolver. It does not prove authoritative answers or worldwide propagation and another resolver may retain a different cached value until its TTL expires. For IPv4 we found 4 found. IPv6 is answered at 8 found.

Inbound mail routes through 5 found. Authoritative DNS is delegated to 4 authoritative. The TXT layer carries everything else a domain advertises about itself: SPF for mail-sender authorisation DMARC reporting addresses Google and Microsoft verification tokens for Search Console and Entra ID BIMI logo references and any SaaS platform tokens accumulated over time. TXT records found include: 71 found.

We surface all of these alongside the core A AAAA and MX records so you can read the full DNS posture in a single view and spot conflicts duplicate entries or leftover tokens from services you no longer use.

A common pattern on small and medium sites is one A record one MX host and two nameservers on the same provider — technically functional but dangerously fragile. Best practice is at minimum two A records pointing to hosts in different availability zones or a CDN-fronted anycast entry that sheds load across regions.

At least two MX hosts in different priority classes — for example priority 10 and a backup at priority 20 — give inbound mail somewhere to queue if the primary is unreachable. com from resolving at all. com already publishes AAAA records giving IPv6-native clients a direct path.

TTL strategy matters more than most teams realise: a TTL of 300 seconds means DNS changes propagate globally in five minutes — ideal during a migration or incident response — but generates roughly twelve times more recursive resolver queries per hour than a 3600-second TTL.

The disciplined pattern is to lower TTLs to 300 before any planned change then raise them back to 3600–86400 once the change is stable so resolvers cache efficiently without locking you in during the next migration.

com is not yet DNSSEC-signed meaning the zone's answers cannot be cryptographically verified by resolvers. Without DNSSEC a sophisticated attacker positioned between a resolver and your nameserver can substitute forged DNS answers redirecting users or automated services to a lookalike host with no visible browser warning.

If you operate a high-trust workload — financial services government healthcare or anything that settles transactions — DNSSEC moves from a best-practice to a compliance baseline; FedRAMP PCI-DSS and NIST SP 800-81r2 all reference it explicitly.

We also surface the SOA record so you can monitor zone integrity: the SOA serial should increment on every zone change and a secondary nameserver with a stale serial means its AXFR or IXFR replication pipeline is broken causing it to serve outdated records to every resolver that reaches it.

Use the Run live again button any time you publish a new TXT verification token add or change an MX host switch hosting providers or complete a DNSSEC key rollover — the snapshot here will capture the new state and surface propagation gaps across the authoritative nameserver set.

Most domains we audit run the bare minimum: a single DNS provider two nameservers on the same network one A record pointing at one server no IPv6 and no DNSSEC. com disappears from the internet entirely because a name that won't resolve has nothing to fail over to. Users see a server not found error bots return a crawl error and search engines log the URL as temporarily unreachable.

The domains at the top of the reliability distribution look different: they run anycast nameservers from two independent providers on separate autonomous systems (for example Route 53 paired with NS1 or Cloudflare paired with a secondary zone service) publish AAAA records so IPv6-native clients get native routing sign the zone with DNSSEC end-to-end and set long TTLs on stable records so the resolver cache absorbs most queries without hitting the authoritative nameservers at all.

com: (1) add a second nameserver provider on a different autonomous system so no single provider outage can black-hole the domain; (2) add AAAA records — most cloud providers and hosting platforms support IPv6 with a single configuration change; (3) right-size TTLs — 300 seconds while actively changing records 3600 or higher once stable; (4) enable DNSSEC at the registrar last once the zone is stable and verify the DS record chain propagates correctly up to the TLD registry.

Re-run this report after each change and consider a DNS monitor to alert when the scheduled DNS audit becomes degraded or unavailable. Review the stored result to identify the specific record or DNSSEC issue.