What checking DNS records and propagation actually means in 2026
Checking DNS via API means programmatically resolving a domain's records — A, AAAA, MX, TXT, NS — and confirming that a change has propagated consistently across resolvers worldwide, all in structured JSON instead of by eyeballing dig output. In 2026 the practical way to do this at any real scale is a managed endpoint that runs the live lookup for you and hands back a clean object you can store, diff, and alert on.
That paragraph is the AEO answer. The rest of this page is for the engineers and operators who have to run a migration at 2am and need to know, with confidence, whether the new record is live everywhere or still draining out of caches.
The problem you are actually trying to solve
You don't want to check DNS. You want to know whether the cutover is safe to finish. There is a difference, and the difference is where outages hide.
The reader of this page usually falls into one of three buckets. An infrastructure or platform engineer running a planned migration — moving a domain to a new host, swapping load balancers, or repointing an apex during a provider change. A monitoring team that needs continuous assurance that production records have not drifted or been tampered with. Or an intelligence and investigations team mapping a target domain's resolution behaviour, nameserver topology, and mail routing as part of a broader profile.
Every one of those teams shares the same hidden requirement. The check has to be authoritative and repeatable. A single lookup from your laptop tells you what your ISP's resolver cached — it does not tell you what a customer in another region sees. The actual product is a consistent, multi-resolver view of the truth, on demand, that you can wire into a runbook or a dashboard.
What the alternatives offer
Before the Ollagraph recipe, let's be fair to the tools you already use. They solve real pieces of this, and you should keep the ones that fit.
dig and the command line
dig is the canonical DNS Swiss Army knife and it is not going anywhere. For a one-off question on your own machine it is unbeatable. Where it stops is repeatability across resolvers and machines — wiring dig +short into a monitoring system means parsing text, normalising output across versions, and standing up egress from many vantage points yourself. It is a primitive, not a pipeline.
Public propagation checkers
The web is full of "is it propagated yet" sites that query a handful of resolvers and draw a world map. They are genuinely useful for a quick visual gut-check during a manual cutover. What they don't give you is an API contract, a stored history, or an alerting hook — you cannot put a screenshot into a runbook and expect it to page someone at 3am.
Build it yourself
The do-it-yourself path means running resolvers in several regions, writing the query and parse logic for every record type, and keeping the whole thing healthy. It is the most flexible option and the most expensive once you count the egress, the regional footprint, and the engineering attention it quietly consumes. Most teams don't need a global resolver fleet — they need the answer.
Where Ollagraph goes further
Ollagraph packages the DNS questions that actually come up during operations behind a small set of endpoints that each return the same canonical JSON shape. You get the answer, not the plumbing.
Three outcomes matter. First, time-to-first-answer: from an API key to a resolved record on a real domain is one curl command. Second, the multi-resolver view that a single dig can't give you — a propagation check queries one record across many public resolvers in a single billed call and tells you how much they agree. Third, predictable per-call economics: one credit per call, the exact cost shown in every response, and failed calls auto-refunded, so a flaky resolver never quietly burns your balance.
Where a command-line tool gives you text to parse, Ollagraph gives you a verb that returns structured fields. The DNS endpoints live alongside the broader intelligence suite, so the same key that resolves a record also profiles nameservers, traces redirects, and classifies IPs — handy when DNS is one input into a larger picture. If your work is investigative rather than operational, the intelligence playbook walks through how teams compose these endpoints into a domain profile.
The recipe, step by step
Here is the working playbook. Five steps, real curl commands, real request shapes. Drop these into a shell and you have the building blocks of a migration runbook or a monitoring job.
Step 1. Get an API key
Sign up on the pricing page, grab an API key from the dashboard, and export it for the rest of this session. The key authenticates every call.
export OLLAGRAPH_API_KEY="osk_xxxxxxxxxxxx"Step 2. Resolve the records you care about
Start with a plain lookup to confirm the records that exist today. The lookup endpoint takes a domain and an optional records array; omit the array and it defaults to A, MX, and TXT. Ask for exactly the types your change touches.
curl -X POST https://api.ollagraph.com/v1/dns/lookup \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com",
"records": ["A", "AAAA", "MX", "TXT", "NS"]
}'This is the snapshot you take before you change anything. Store it. When the cutover is done, run the same call and diff the two — the difference is your change, and anything you didn't expect to move is a flag. Keeping the pre-change record set in your warehouse turns "did we break the MX?" from a guess into a query.
Step 3. Watch propagation across resolvers
After you push the change, the question is no longer "what is the record" but "does the whole world agree on it yet." The propagation endpoint queries the same record across many public resolvers and reports the consistency. Pass a domain and an optional record_type — it defaults to A.
curl -X POST https://api.ollagraph.com/v1/intel/dns-propagation \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com",
"record_type": "A"
}'Poll this on a loop during the cutover window. While resolvers disagree, propagation is still in flight and you should not tear down the old endpoint. Once every resolver returns the new answer, the change is live everywhere and you can finish the migration. The cadence is yours to set — if you dropped the TTL ahead of time, the window is short and a poll every minute or two is plenty.
Step 4. Ask a specific resolver directly with DoH
Sometimes you need to know what one named resolver sees, not an aggregate. The DNS-over-HTTPS endpoint forwards a single query through a chosen public resolver and returns its answer. Pass a domain, an optional record_type (defaults to A), and an optional resolver (defaults to cloudflare; google is the other option).
curl -X POST https://api.ollagraph.com/v1/dns/over-https \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com",
"record_type": "MX",
"resolver": "google"
}'This is the call you reach for when two resolvers disagree and you need to attribute the disagreement. Running the same query through both providers — once with "resolver": "cloudflare" and once with "resolver": "google" — tells you whether a stale answer is sitting in one provider's cache or whether the authoritative side is genuinely inconsistent.
Step 5. Check the nameservers underneath it all
Records are only as reliable as the nameservers serving them. The nameservers endpoint takes an apex domain and returns the authoritative nameservers plus the IPv4 and IPv6 each one resolves to. It also reports a diversified boolean.
curl -X POST https://api.ollagraph.com/v1/intel/nameservers \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com"
}'A diversified value of false means every nameserver sits in the same network block — a single-provider, single-point-of-failure setup that an outage at one provider can take down entirely. During an infrastructure review this is exactly the kind of finding worth surfacing before it becomes an incident.
A realistic scenario: a zero-downtime apex cutover
Consider a platform team moving a production apex from an old load balancer to a new one during a provider migration. They cannot afford an outage, and the apex has a TTL that was set long ago and never tuned.
The day before the change, they lower the TTL so the propagation window will be short, and they capture a baseline with /v1/dns/lookup across A, AAAA, MX, TXT, and NS. At the cutover, they push the new A and AAAA records, then poll /v1/intel/dns-propagation on a one-minute loop. While resolvers disagree, the old load balancer stays up and serving. When propagation reads consistent across every resolver, they confirm with a direct /v1/dns/over-https query against both Cloudflare and Google to rule out a single stale cache, then drain and decommission the old endpoint. The whole sequence is a runbook, not a judgment call, because every step returns a machine-readable answer.
Wiring it into monitoring
The endpoints that power a cutover also power steady-state monitoring. A scheduled job that runs /v1/dns/lookup on your production domains and diffs the result against a stored baseline catches unauthorised or accidental record changes the moment they appear. Pair it with a periodic /v1/intel/nameservers check to catch nameserver drift or a loss of diversification when someone reconfigures the zone. Because every call returns structured JSON, the alerting logic is a simple comparison — no text parsing, no resolver fleet to babysit.
The boring part is the part that pays off: land each result with a timestamp and the domain, keep the raw response in a JSON column, and you accumulate a history you can replay. When something does drift, you can answer "when did this record last look right" without re-running anything.
DNS records versus email authentication posture
It is worth being precise about a common confusion. Resolving a domain's TXT records tells you which records exist and what they contain. It does not tell you whether your email authentication is correctly configured. SPF, DKIM, and DMARC all live in DNS — typically as TXT records — but evaluating whether mail from your domain will be trusted is a posture question that goes beyond "does the record resolve."
If your goal is deliverability and anti-spoofing, the DNS lookup here is the raw input, but the analysis you actually want lives in the dedicated recipe on checking email authentication. Use the DNS endpoints on this page to confirm the records propagate and resolve consistently; use that recipe to judge whether the SPF, DKIM, and DMARC posture they encode is correct.
What can go wrong, and how to handle it
A few failure modes are worth planning for. The first is TTL surprise: if you forget to lower the TTL before a cutover, propagation can drag on for as long as the old TTL, and no amount of polling speeds it up. Lower the TTL a day ahead and the window shrinks to minutes.
The second is mistaking your local resolver for the truth. A lookup from one machine reflects one cache. The propagation endpoint exists precisely so you don't draw conclusions from a single vantage point — when it shows disagreement, that disagreement is real and you should wait it out.
The third is treating a transient resolver timeout as a record change. Resolvers occasionally fail to answer. Because failed calls are auto-refunded, a timeout costs you nothing, but your monitoring logic should distinguish "no answer" from "different answer" so a blip doesn't page someone at 3am. If you need the canonical reference for record types and DoH encoding, the IETF documents DoH in RFC 8484.
Pairing DNS with the rest of the stack
DNS is rarely the whole picture. Teams routinely pair these endpoints with SSL and subdomain monitoring so a certificate review and a DNS review run on the same schedule, and with IP geolocation and ASN lookups to turn the addresses a record resolves to into infrastructure context. For investigative work, the broader intelligence suite lets the same key that resolves a record also classify the hosts behind it.
What to do next
Grab a key, paste the lookup command from Step 2, and confirm you can resolve a real domain in the next two minutes. Then pick one workflow — a migration runbook or a steady-state monitoring job — and wire the propagation endpoint into it. Most teams have a working internal check inside an afternoon.
Read the docs, browse the intelligence endpoints, and ship something.