TamingDNS for developers and agents

Every check on this site is callable. There are four ways in and they all run the same engine, so a script, an AI agent and a person clicking buttons get the same grade for the same domain. Requests carry no authentication header.

The four surfaces

  • REST: GET /api/v1/{check}?domain=…. Plain HTTP and JSON. Described by /openapi.json (OpenAPI 3.1).
  • MCP: JSON-RPC 2.0 over Streamable HTTP at /mcp. For Claude, Cursor, Raycast and anything else that speaks Model Context Protocol. Setup snippets are on that page.
  • WebMCP: tools registered in the page itself via document.modelContext.registerTool, so a browsing agent can call the tool it is already looking at instead of scraping the DOM.
  • Markdown: send Accept: text/markdown to the homepage or any article and you get Markdown rather than 300 KB of HTML. Articles also answer at /articles/{slug}.md.

Quickstart

One request, no setup:

curl -sS 'https://tamingdns.com/api/v1/dmarc?domain=example.com'

Checks that take a long input are POST-only:

curl -sS -X POST 'https://tamingdns.com/api/v1/email-headers' \
  -H 'Content-Type: application/json' \
  -d '{"headers":"Received: from ...\nFrom: [email protected]"}'

Point an agent at the whole API in one line: hand it https://tamingdns.com/openapi.json. Every operation there carries a unique operationId, typed parameters and a response schema, which is what a function-calling runtime needs.

The checks

REST operationId / MCP tool Arguments What it returns
/api/v1/spf check_spf domain SPF record, lookup count, terminal qualifier
/api/v1/dkim check_dkim domain, selector DKIM public key, length, revocation, test mode
/api/v1/dmarc check_dmarc domain DMARC policy, both discovery methods, RUA authorisation
/api/v1/mx check_mx domain MX hosts, PTR, FCrDNS, provider, transport security
/api/v1/mta-sts check_mta_sts domain MTA-STS record, policy fetch, certificate, MX coverage
/api/v1/tls-rpt check_tls_rpt domain TLS-RPT record, rua destinations, enforcement prerequisites
/api/v1/dane check_dane domain TLSA records per MX host and their DNSSEC status
/api/v1/dnssec check_dnssec domain DS / DNSKEY / RRSIG chain walk and the resolver AD matrix
/api/v1/bimi check_bimi domain BIMI record, SVG logo, VMC chain, DMARC prerequisite
/api/v1/email-headers analyze_email_headers headers (POST) Spoofing and phishing verdict from a raw header block

The REST path, the operationId and the MCP tool name are the same check. /api/v1/spf and MCP's check_spf hit one function and share one 60-second cache.

What comes back

One envelope, the same on every surface:

  • status: pass / warn / fail / info. The one-word answer.
  • grade: A to F, with grade_reasons[] explaining each deduction.
  • findings[]: stable codes such as POLICY_NONE or NEAR_LOOKUP_LIMIT, with severity and remediation. Full registry: /finding-codes.md.
  • records[]: the raw DNS records the verdict was computed from, so an agent can show its work.
  • analysis: per-check detail. The SPF include tree, the DMARC discovery ladder, the VMC chain.
  • error: present only when the check could not run at all.

A domain that fails a check still returns HTTP 200. "This domain has no SPF record" is the answer, not an error. HTTP goes 5xx only when the check itself could not be performed, and then the body carries error.retriable telling you whether repeating the call is worth it. Errors are JSON on every path, including 404s under /api/.

When to reach for this

Good fits: a user asks why their mail lands in spam; you need to know whether a domain's DMARC policy is enforced or only monitoring before advising a change; you are auditing a domain you are about to send from; a bounce mentions SPF, DKIM or DMARC and you need the record read correctly; someone pastes email headers and wants to know if the message is spoofed; you want to confirm a DNS change published before telling a client it is done.

Poor fits: bulk scanning of domain lists, anything needing write access to DNS, and mailbox-level deliverability testing. These checks read public DNS and public certificates, and never send or receive mail.

Practical details

Do I need an API key?

No. Every check is read-only and idempotent: it looks up public DNS records and grades them. There is nothing a key would protect.

What are the rate limits?

Per IP, a few dozen calls a minute: enough for interactive use and scheduled checks, not for bulk scanning. Results are cached 60 seconds per input, so a retry inside that window is free. If you need more for a legitimate use case, talk to us.

Is the API versioned?

The path carries /v1 and the envelope carries schema_version. New fields get added inside analysis; the top-level shape and the finding codes are the part treated as a contract.

Where are the machine-readable files?

/openapi.json (REST), /.well-known/mcp/server-card.json (MCP), /finding-codes.md (finding codes), /llms.txt and /llms-full.txt (site context for LLMs).