MCP DNS Record Checker

Enter a domain or subdomain to inspect its MCP (Model Context Protocol) signing keys published as v=MCPv1 TXT records. The MCP Registry expects records at the apex (e.g. stripe.com), but some operators publish them on a dedicated host instead (e.g. mcp.cloudflare.com).

Try a known publisher: microsoft.com · stripe.com · vercel.com · linear.app · figma.com · atlassian.com · auth0.com · newrelic.com · monday.com · amplitude.com · mcp.cloudflare.com

How this MCP record checker works

An MCP (Model Context Protocol) signing key sits in DNS as a TXT record. The MCP Registry, or any client that wants to verify domain ownership before trusting a server, fetches that key and checks signatures against it. The record uses the same tag-value layout you already know from SPF, DKIM and DMARC: 

example.com.  TXT  "v=MCPv1; k=ed25519; p=<base64-public-key>"

The Registry expects the record at the apex. Some operators publish on a dedicated subdomain instead. Cloudflare does this at mcp.cloudflare.com. Type either form above and the checker reads every TXT record at that name, pulls out the MCP entries, and validates each one against the spec.

What gets checked?

Two algorithms are defined. ed25519 takes a raw 32-byte key. ecdsap384 takes a 49-byte compressed point with a leading byte of 0x02 or 0x03, not the uncompressed 0x04 || x || y form that most openssl commands spit out by default.

The tool decodes the base64 payload, checks it matches the expected length for the declared algorithm, and computes a SHA-256 fingerprint over the raw published bytes so you can compare it against what your registry or build pipeline produced. Multiple keys at the apex are fine. They usually mean a rotation in progress or several MCP servers running under one domain.

Why this matters

The DNS-TXT convention is documented by the MCP Registry in preview status. There is no RFC and no adopted MCP SEP yet. Breaking changes are still on the table until the format is finalised.

Our take: if you publish an MCP server and want the Registry to verify you own the domain, publish the TXT now. The format is stable enough to bet on, and the verification path is the only one the Registry currently offers without an OAuth flow. Just don't write tooling that assumes the tag set will never change.

What to do: generate the key with the compressed-point flag explicitly set, publish the TXT at your apex, then re-run this checker. If the fingerprint matches the one your build emitted, you're done.

Where to go next

For the wider DNS picture, the TXT record checker classifies MCP records alongside SPF and the verification tokens from major providers. The structural cousin on the email side is DKIM, which uses the same tag-value layout and the same p= public-key tag.

Frequently Asked Questions

Common questions about MCP signing keys published in DNS.

Two. ed25519 takes the raw 32-byte public key, base64-encoded. ecdsap384 takes a 49-byte compressed point with a leading 0x02 or 0x03 byte. Anything else parses as unknown or malformed.

The common mistake on the ECDSA side is publishing the default 97-byte uncompressed form (0x04 || x || y) or a DER SubjectPublicKeyInfo wrapper. Both look fine to openssl and both get rejected by registry consumers. Always pass -conv_form compressed when exporting.

For ed25519, generate the key and take the trailing 32 bytes of the public-key DER as your base64 payload:

openssl genpkey -algorithm ed25519 -out key.pem
openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64

For ecdsap384, generate on secp384r1 and export with the compressed-point flag. Skip it and you get the 97-byte uncompressed payload that the registry rejects:

openssl ecparam -name secp384r1 -genkey -noout -out key.pem
openssl ec -in key.pem -pubout -conv_form compressed -outform DER \
    | tail -c 49 | base64

Publish the result as a TXT record at your apex in the form v=MCPv1; k=<algorithm>; p=<base64>.

Yes. There is no per-server selector the way DKIM has one. The spec puts every key at the apex, and multiple records at the apex are valid. The usual reasons are an in-flight rotation or several MCP servers running under one domain. Each record is parsed independently. microsoft.com currently publishes twelve.

No. It sits in the MCP Registry documentation in preview status. Breaking changes are still possible. There is no RFC and no adopted MCP SEP behind it.

A separate IETF individual draft (draft-morrison-mcp-dns-discovery) proposes a different scheme using v=alter1 under a _alter. prefix. It is unrelated to v=MCPv1 and has no formal standing yet.

No. DNS-TXT is one path of several, and the one this tool covers. Hosted servers like GitHub's at api.githubcopilot.com/mcp and Notion's at mcp.notion.com/mcp authenticate with OAuth instead, publishing a resource-metadata document at .well-known/oauth-protected-resource.

Reference servers from Slack, HubSpot and others ship as npm packages (@modelcontextprotocol/server-slack, @hubspot/mcp-server) that the user runs locally. Those need no DNS proof at all. A domain without a v=MCPv1 record can still have a working MCP server published one of these other ways.

Different reasons per vendor. Anthropic and OpenAI are MCP clients. Claude Desktop and ChatGPT consume MCP servers, they don't run public ones of their own. Google's agent stack is built on ADK and A2A, so there's nothing to publish in the first place.

GitHub and Notion do run hosted MCP servers, but authenticate via OAuth rather than DNS-TXT. Salesforce has no public server at all, only third-party community implementations. Cloudflare is currently the biggest DNS-TXT adopter outside the Registry's launch partners.

Once the spec moves out of preview and the Registry stabilises, the DNS-TXT convention will probably pick up more publishers. Right now it's a patchwork.