A useful DNS audit for an AI agent should answer a narrow question: what do the domain's published mail-routing and sender-policy records say right now? It should not pretend to prove that a particular mailbox exists or that any message will land in the inbox.
I built a small, original, AI-assisted public-domain DNS preflight API as one more tool in a single-owner x402 merchant. It checks publicly visible MX, SPF, DMARC and A records. A free fictional sample shows the response shape; a real valid domain lookup is gated at 0.005 native Circle USDC per call on Base.
Disclosure before the details: this particular DNS product has zero independently confirmed paid orders as of this article. Two completely different existing API routes (an OpenAPI template and a synthetic CSV report) were bought by the same external NoHumans automated verification scout for a combined historical 0.015 native Circle Base USDC. Those one-time checks are real settled tokens and delivered outputs, but not recurring organic human clients, fiat revenue or known business profit.
Four concepts people accidentally treat as one
MX — routing intent. An MX record names an intended mail exchanger and its preference value. Multiple MX hosts do not prove that any individual recipient address exists, that the servers will accept your message or that they are reachable from every network. A domain may have special DNS setups, including cases where no MX is published; reporting the literal DNS findings is safer than instantly calling the address fake.
SPF — authorized sending infrastructure. Look at the domain's relevant TXT records for a value starting with v=spf1. SPF can contain include, ip4, ip6 and mechanism qualifiers. A syntactically recognizable SPF TXT record alone does not establish that an arbitrary From-address is authenticated; SPF operates on SMTP envelope identities and a receiving server's evaluated result. Multiple SPF records may themselves be a configuration error.
DMARC — the published domain policy. The _dmarc subdomain usually publishes a TXT record beginning with v=DMARC1, with a p= policy such as none, quarantine or reject. Publishing p=reject is a strong policy signal, but correct real-world enforcement depends on alignment and how the receiving mail service evaluates the message. The record is not a promise that all forged mail will be blocked.
A — IPv4 name resolution. An A record may be helpful context for the domain and its web host. It is not proof of an operational inbound mail server and cannot replace a proper mail-acceptance test.
A fifth concept: DKIM is not inferred from these four. DKIM public keys use selectors (selector._domainkey.example.org). You cannot reliably claim a domain signs all mail with DKIM just because MX/SPF/DMARC/A look sensible, nor can you infer the selector from any random address.
My free sample, then the real paid request
The reproducible fixture uses example.org and is clearly labeled synthetic; it makes no network claim about that domain.
curl -sS https://vm5-openapi-x402.onrender.com/v1/email-dns-sample
The live paid endpoint accepts a public domain, for example:
curl -i 'https://vm5-openapi-x402.onrender.com/v1/email-dns-preflight?domain=gmail.com'
That second command, without a buyer payment authorization, should yield HTTP 402, not the paid DNS report. The PAYMENT-REQUIRED header declares x402 v2, network eip155:8453, native Circle Base USDC asset 0x833589fcd6edb6e08f4c7c32d4f71b54bdA02913, and 5,000 atomic units = 0.005 USDC. Reading this price costs nothing; an actual buyer must explicitly authorize a separate wallet payment and retry through their own compatible x402 client.
A caller-supplied malformed domain is rejected before reaching the payment middleware, so it should return an unpaid client error rather than charging to explain invalid input. The service can also fail when authoritative DNS/upstream resolution is unavailable. Such a failure is not evidence that the domain is malicious, and the API should not charge when it cannot perform its work.
This distinction is important in unattended machine-to-machine commerce:
- Validate the shape and bounds of the input locally.
- Confirm that the requested operation is technically possible.
- Issue the precise 402 only for a legitimate request the service can fulfill.
- Verify buyer-authorized settlement and deliver the bounded output.
- Keep failed probes, free synthetic samples, listings and genuine paid calls in separate accounting categories.
That flow reduces a buyer's chances of spending money just to discover the request never had a chance of succeeding.
The JSON buyer actually needs
A useful preflight result should expose the queried domain and the public observations with explicit caveats. Consider fields such as the number of MX hosts, SPF presence, DMARC presence and policy, DNS lookup warnings, and the limits of the interpretation.
What it should not return is a blanket safe-to-email verdict, a guessed DKIM selector, a guaranteed mailbox existence claim or an assurance that any provider will accept a message. Do not send names, addresses, customer records, private DNS credentials, email contents or API keys. Public-zone domain lookup is enough for this service.
The original source, technical constraints and the entire paid route contract are public:
- Free fictional DNS result
- The live 0.005 USDC public DNS endpoint
- OpenAPI 3.1 schemas for all routes
- Machine-readable pricing and limits
- Source repository
The DNS tool is an as-is configuration observation, not a certification of identity, authentication enforcement, email deliverability or cybersecurity compliance. Actual upstream DNS answers may change. The code and this explanation were developed with disclosed AI assistance; no prior paid DNS client engagement or testimonial is asserted.
If you are building an agent that checks domains before calling an email API, which is more valuable in your workflow: the raw DNS record evidence, a machine-readable explanation of missing policy, or an explicit unknown/inconclusive outcome?
Top comments (0)