How this MCP record checker works
MCP (Model Context Protocol) servers can publish a signing key in DNS so the MCP Registry, or any client that wants to verify the server's domain ownership, has a public key to check signatures against. The record looks like v=MCPv1; k=<algorithm>; p=<base64-public-key> and uses the same tag-value layout as SPF, DKIM and DMARC. The Registry expects it at the apex, but some operators publish on a dedicated subdomain instead (Cloudflare does this at mcp.cloudflare.com). Enter either form below and we read every TXT record at that name, pull out the MCP entries, and validate each one against the spec.
Two algorithms are defined: ed25519 (32-byte raw key) and ecdsap384 (49-byte compressed point with leading byte 0x02 or 0x03, not the more common uncompressed 0x04 || x || y). We decode the base64 payload, check it matches the expected length for the declared algorithm, and compute a SHA-256 fingerprint over the raw published bytes so you can compare it to what your registry or build pipeline produced. Multiple keys at the apex are allowed and usually mean either key rotation or several MCP servers running under one domain.
The convention is published by the MCP Registry documentation in preview status, so breaking changes are possible until the format is finalised. For the broader DNS picture, our 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.
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
Validation results
Frequently Asked Questions
Common questions about MCP signing keys published in DNS.
What is an MCP DNS record?
An MCP (Model Context Protocol) DNS record is a TXT record at a domain's apex that publishes a public signing key for an MCP server. It uses the format v=MCPv1; k=<algorithm>; p=<base64-public-key>. The MCP Registry uses these records to verify that whoever is publishing a server entry actually controls the domain.
Which algorithms are supported?
Two: ed25519 and ecdsap384. Anything else is unknown or malformed. For ed25519, the p= value is the raw 32-byte public key, base64-encoded. For ecdsap384, it is a 49-byte compressed point (leading 0x02 or 0x03), not the more common uncompressed 0x04 || x || y form and not a DER SubjectPublicKeyInfo wrapper. This is easy to get wrong with the default openssl settings.
How do I generate an MCP record?
Follow the recipes in the MCP Registry authentication docs. For ed25519, generate a key with openssl genpkey -algorithm ed25519, export the public key DER, and take the trailing 32 bytes as the base64 payload. For ecdsap384, generate with openssl ecparam -name secp384r1 -genkey, then export with -conv_form compressed. Skip that flag and you get the default 97-byte uncompressed payload, which registry consumers reject.
Can I publish more than one MCP key?
Yes. The spec mandates apex placement (no per-server selector like DKIM uses), and multiple records at the apex are valid. The usual reasons are key rotation overlap or several MCP servers running under one domain. Each record is parsed independently. microsoft.com currently publishes twelve.
Is v=MCPv1 a finalised standard?
No. It is published in the MCP Registry documentation in preview status, with breaking changes still possible until the format is finalised. There is no RFC and no adopted MCP SEP. A separate IETF individual draft (draft-morrison-mcp-dns-discovery) proposes a different scheme using v=alter1 under a _alter. prefix; it is unrelated and has no formal standing.
Is DNS the only way to publish an MCP server?
No. DNS-TXT is one of several MCP authentication paths and is the one this tool checks. Several hosted MCP servers, including GitHub's at api.githubcopilot.com/mcp and Notion's at mcp.notion.com/mcp, authenticate with OAuth instead and publish 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 and never need a DNS proof. A domain without a v=MCPv1 record can still have a working MCP server published in one of these other ways.
Why don't Anthropic, OpenAI, Google, and other big names publish MCP records?
Different reasons, depending on the company. 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 rather than MCP, so there is nothing to publish. 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. For now it is a patchwork.