DNS Lookup API: MX, NS, SPF, DMARC via REST (2026)

Most engineers default to dig when they need to look at a domain's DNS. It's fast, it's local, and it's correct. But the moment you need DNS records inside a script, a webhook handler, a CI pipeline, a Slack bot, or a lead-enrichment job, parsing dig's text output becomes a chore. A DNS lookup API gives you the same answers as structured JSON: one HTTP call, one parser, every record type in one shot.

This post walks through what a DNS lookup API does, which records the DetectZeStack GET /dns endpoint returns, how the email-security grading on top of those records works, and where it beats the shell-out-to-dig pattern. Every example uses the real API; none of the field names are invented.

What a DNS Lookup API Does (and Why You Need One)

DNS is the connective tissue of the public internet. Every domain answers questions about itself through DNS: where its web servers live (A, AAAA), where its mail goes (MX), who can sign for it (NS, SOA), what the apex is aliased to (CNAME), and what arbitrary metadata the owner has chosen to publish (TXT — including SPF, DMARC, Google Search Console verification, and dozens of other conventions).

A DNS lookup API exists because the data is useful in places where running dig isn't practical:

• A serverless function that needs to know a prospect's email provider before deciding which outreach template to send
• A change-monitoring job that polls a domain every week and posts to Slack when its nameservers move
• A CRM enrichment hook that wants the email_security_grade for a domain at lead-creation time
• An M&A diligence dashboard that audits 200 portfolio companies' SPF and DMARC posture nightly
• A browser-side tool that can't make raw DNS queries because the browser only speaks HTTP

In all of those, you don't want to package dig as a dependency, parse its text output, handle stderr, and figure out which selectors to probe for DKIM. You want JSON.

Records You Can Query: A, AAAA, MX, NS, TXT, SOA, CNAME, PTR

The DetectZeStack GET /dns endpoint resolves all of the standard public DNS record types in a single call. The response is a JSON object with one field per record type:

The endpoint sets a 5-second hard cap on a single lookup. If a record type can't be resolved (typical for AAAA on IPv4-only domains, or PTR when no rDNS is published), the field is returned as an empty array rather than as an error — you get all the records that exist in one call instead of having to retry for each missing type.

Email Security Records: SPF, DMARC, DKIM

SPF and DMARC are plain TXT records. DKIM is a TXT record at a <selector>._domainkey.<domain> label. If you only ask DNS for them, you get raw strings — v=spf1 include:_spf.google.com ~all, v=DMARC1; p=reject; rua=mailto:dmarc@... — and then you have to parse them yourself.

The /dns endpoint parses them for you and adds them as separate top-level fields:

• spf — the parsed SPF record with record, exists, mechanism (-all / ~all / ?all / +all), includes (list of include domains), a letter grade, and a list of issues
• dmarc — the parsed DMARC record with record, exists, policy (reject / quarantine / none), subdomain_policy, aggregate reporting URI (rua), forensic URI (ruf), grade, and issues
• dkim — the DKIM probe result: which selector was tested (selector_tested), whether a record exists, a grade, and any issues

How DetectZeStack Grades Email Security

Each protocol gets an A–F letter grade, and an overall email_security_grade is computed from the three. The logic, briefly:

• SPF — An A requires -all (hardfail) and fewer than 10 DNS-lookup includes (RFC 7208 caps SPF at 10 lookups). ~all (softfail) scores a B. Missing or +all is an F.
• DMARC — p=reject with rua reporting earns an A. p=quarantine is a B. p=none (monitor-only) is a C. No record is an F.
• DKIM — The API probes 8 common selectors: google, default, selector1, selector2, k1, mandrill, mailchimp, smtp. If any selector returns a valid record, DKIM grades A. None found grades F.

The composite email_security_grade is dragged down by the weakest of the three. A single F on any one of SPF, DMARC, or DKIM stops the overall grade from being an A. The email_security_summary field is a human-readable sentence you can drop straight into a Slack message or a CRM note.

If you want the full breakdown of SPF/DMARC/DKIM checks beyond what's in this post, see DNS Intelligence API: SPF, DKIM & DMARC Check.

DNS Lookup API vs Running dig Yourself

Both approaches resolve the same records. The difference is everything that surrounds the resolution:

dig is the right tool when you're sitting at a terminal debugging one domain. The API is the right tool when the answer needs to flow into another system — a Slack alert, a Postgres row, a Notion page, a CRM enrichment field, a CI assertion.

Using the DetectZeStack /dns Endpoint (curl example)

Grab a free RapidAPI key from the DetectZeStack listing (no credit card required, 100 requests per month on the free plan), then call /dns with a domain query parameter:

curl -s "https://detectzestack.p.rapidapi.com/dns?domain=stripe.com" \
  -H "x-rapidapi-key: YOUR_API_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" | python3 -m json.tool

If you just want to see the shape of the response without an API key, the public /demo endpoint returns the same kind of structured data for the tech-detection side of the API (no key required). You can use it as a smoke test before wiring up your real key:

curl -s "https://detectzestack.com/demo?url=https://stripe.com" | python3 -m json.tool

That call returns the technology-detection response shape:

{
  "url": "https://stripe.com",
  "domain": "stripe.com",
  "technologies": [
    {
      "name": "React",
      "categories": ["JavaScript frameworks"],
      "confidence": 100,
      "description": "React is an open-source JavaScript library for building user interfaces.",
      "website": "https://reactjs.org",
      "icon": "React.svg",
      "source": "http",
      "version": "",
      "cpe": ""
    },
    {
      "name": "Cloudflare",
      "categories": ["CDN"],
      "confidence": 100,
      "description": "Cloudflare is a global CDN and DDoS-mitigation network.",
      "website": "https://www.cloudflare.com",
      "icon": "CloudFlare.svg",
      "source": "http",
      "version": "",
      "cpe": ""
    }
  ],
  "categories": { "JavaScript frameworks": ["React"], "CDN": ["Cloudflare"] },
  "meta": { "status_code": 200, "tech_count": 14, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1842
}

Use /demo to confirm the auth-free flow works, then point at /dns with your key for the DNS-specific records.

Sample JSON Response

A realistic /dns response looks like this:

{
  "domain": "stripe.com",
  "a": ["185.166.143.26", "185.166.143.18"],
  "aaaa": [],
  "cname": "",
  "mx": [
    {"host": "aspmx.l.google.com.", "priority": 1},
    {"host": "alt1.aspmx.l.google.com.", "priority": 5},
    {"host": "alt2.aspmx.l.google.com.", "priority": 5}
  ],
  "ns": [
    "ns-cloud-a1.googledomains.com.",
    "ns-cloud-a2.googledomains.com.",
    "ns-cloud-a3.googledomains.com.",
    "ns-cloud-a4.googledomains.com."
  ],
  "txt": [
    "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all",
    "google-site-verification=...",
    "MS=ms..."
  ],
  "soa": {
    "primary_ns": "ns-cloud-a1.googledomains.com.",
    "admin_email": "cloud-dns-hostmaster.google.com.",
    "serial": 4,
    "refresh": 21600,
    "retry": 3600,
    "expire": 1209600,
    "min_ttl": 300
  },
  "ptr": ["185-166-143-26.example.ptr."],
  "email_provider": "Google Workspace",
  "dns_provider": "Google Cloud DNS",
  "spf": {
    "record": "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all",
    "exists": true,
    "mechanism": "~all",
    "includes": ["_spf.google.com", "servers.mcsv.net"],
    "grade": "B",
    "issues": ["Uses ~all (softfail) instead of -all (hardfail)"]
  },
  "dmarc": {
    "record": "v=DMARC1; p=reject; rua=mailto:[email protected]",
    "exists": true,
    "policy": "reject",
    "subdomain_policy": "",
    "rua": "mailto:[email protected]",
    "ruf": "",
    "grade": "A",
    "issues": []
  },
  "dkim": {
    "selector_tested": "google",
    "exists": true,
    "grade": "A",
    "issues": []
  },
  "email_security_grade": "A",
  "email_security_summary": "Strong email security posture. SPF, DMARC, and DKIM are all configured.",
  "query_ms": 142,
  "response_ms": 168
}

Common Use Cases: Migration, Deliverability, Lead Enrichment, Monitoring

1. Pre-migration audit

Before pointing a domain at a new email host or DNS provider, dump the current state so the rollback path is documented:

curl -s "https://detectzestack.p.rapidapi.com/dns?domain=acme.com" \
  -H "x-rapidapi-key: $RAPIDAPI_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
  | jq '{
      ns,
      mx,
      spf: .spf.record,
      dmarc: .dmarc.record,
      email_provider,
      dns_provider
    }' > pre-migration.json

Run the same call after the cutover and diff the two snapshots. If email_provider stays the same when you expected it to change, you know propagation hasn't completed.

2. Deliverability triage

When a sales team reports "our emails are going to spam", the first three things to check are SPF, DMARC, and DKIM. One curl call surfaces all three plus a grade:

curl -s "https://detectzestack.p.rapidapi.com/dns?domain=$DOMAIN" \
  -H "x-rapidapi-key: $RAPIDAPI_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
  | jq '{grade: .email_security_grade, summary: .email_security_summary,
         spf: .spf.grade, dmarc: .dmarc.policy, dkim: .dkim.exists}'

3. Lead enrichment

For B2B sales, the email provider and DNS provider tell you a lot about company size and IT sophistication. A small business on GoDaddy DNS with no DMARC is a very different conversation from an enterprise on Cloudflare with p=reject. Hook the /dns call into the new-lead webhook in your CRM and write email_provider, dns_provider, and email_security_grade onto the lead record. For the broader pipeline pattern, see Lead Enrichment Pipeline with Tech Detection.

4. Infrastructure-change monitoring

Run a daily cron that compares today's MX, NS, and SPF to yesterday's. Any diff triggers a Slack alert. This is how you catch "marketing changed our ESP and broke SPF" before customer support catches it:

#!/bin/bash
# /opt/scripts/dns-watch.sh — daily cron, 0 8 * * *
DOMAIN="yourdomain.com"
OUT="/var/log/dns-watch/$DOMAIN.json"
PREV="${OUT}.prev"

[ -f "$OUT" ] && mv "$OUT" "$PREV"

curl -s "https://detectzestack.p.rapidapi.com/dns?domain=$DOMAIN" \
  -H "x-rapidapi-key: $RAPIDAPI_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
  | jq '{mx, ns, spf: .spf.record, dmarc: .dmarc.record, grade: .email_security_grade}' \
  > "$OUT"

if [ -f "$PREV" ] && ! diff -q "$PREV" "$OUT" > /dev/null; then
  DIFF=$(diff -u "$PREV" "$OUT" | head -40)
  curl -s -X POST "$SLACK_WEBHOOK" \
    -H "Content-Type: application/json" \
    -d "{\"text\":\"DNS change detected for $DOMAIN:\n\`\`\`$DIFF\`\`\`\"}"
fi

DNS isn't only an email signal — CDN and hosting providers also leak through. For that angle see Detect CDN & Hosting Provider and DNS-Based Technology Detection.

Pricing and Rate Limits

Quota is shared across endpoints: /dns, /analyze, /certificate/check, and /security all draw from the same monthly bucket. A daily check on 3 domains is ~90 requests/month — comfortably inside the free tier.

For SSL alongside DNS monitoring, pair this with the SSL Certificate Check API.

Getting Started in 60 Seconds

1. Sign up at rapidapi.com/mlugoapx/api/detectzestack and copy your x-rapidapi-key.
2. Run the curl example above with a domain you control.
3. Read email_security_grade first — if it's not an A, the rest of the response tells you exactly which protocol pulled it down.
4. If you only want a smoke test with no signup, hit https://detectzestack.com/demo?url=https://example.com — same response shape (for tech detection), no key needed.