mcp-publisher authentication failed — how to fix it

DNS authentication failed:
no valid MCP public keys found in DNS TXT records

This is the most common mcp-publisher failure, and the error message actively misleads you. It reads like a key problem. It is almost always a placement problem.

MCP DNS authentication follows SPF-style placement — the record goes on the apex of your domain. It is not DKIM-style selector placement. A record at _mcp-registry.example.com or _mcp-auth.example.com is never read, and the registry reports a generic signature failure rather than “no record found”.

# ✗ Never read — selector placement
_mcp-registry.example.com.  IN TXT  "v=MCPv1; k=ed25519; p=…"
_mcp-auth.example.com.      IN TXT  "v=MCPv1; k=ed25519; p=…"

# ✓ Apex placement
example.com.                IN TXT  "v=MCPv1; k=ed25519; p=…"

dig +short TXT example.com | grep MCPv1
# expect: "v=MCPv1; k=ed25519; p=…"

# If this returns nothing, the record is not on the apex,
# whatever your control panel shows.

A previous TXT record left on the apex is tried first, and its failure ends the attempt — the registry does not fall through to your new key.

dig +short TXT example.com | grep MCPv1
# More than one MCPv1 line = the stale one is shadowing the new one.

DNS changes are not instant. The record must propagate before the registry can read it, and community reports describe waits of up to a couple of hours depending on the provider and the previous record's TTL.

# Ask a public resolver
dig +short TXT example.com @1.1.1.1 | grep MCPv1

# Ask your domain's own authoritative nameserver — the ground truth
dig +short NS example.com
dig +short TXT example.com @<one-of-those-nameservers>

openssl genpkey -algorithm Ed25519 -out key.pem
Algorithm Ed25519 not found

You are running LibreSSL, not OpenSSL 3. macOS ships LibreSSL as the system openssl binary and it does not implement Ed25519 in genpkey. The Ed25519 codepath requires OpenSSL 3.0 or later.

brew install openssl@3

# Apple Silicon
/opt/homebrew/opt/openssl@3/bin/openssl genpkey -algorithm Ed25519 -out key.pem

# Intel
/usr/local/opt/openssl@3/bin/openssl genpkey -algorithm Ed25519 -out key.pem

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:secp384r1 -out key.pem

PUBLIC_KEY="$(openssl ec -in key.pem -text -noout -conv_form compressed \
  | grep -A4 "pub:" | tail -n +2 | tr -d ' :\n' | xxd -r -p | base64)"
echo "${MY_DOMAIN}. IN TXT \"v=MCPv1; k=ecdsap384; p=${PUBLIC_KEY}\""

PRIVATE_KEY="$(openssl ec -in key.pem -noout -text \
  | grep -A4 "priv:" | tail -n +2 | tr -d ' :\n')"
mcp-publisher login dns --algorithm ecdsap384 \
  --domain "${MY_DOMAIN}" --private-key "${PRIVATE_KEY}"

You authenticated fine, and you are still only granted io.github.yourusername/* rather than io.github.yourorg/*.

Publishing under an organization namespace requires Owner role in that organization. Ordinary membership is not enough: the registry checks your membership role and grants the org namespace only to admins, so that anyone who merely belongs to an org cannot publish — or overwrite — servers under the org's name.

The device flow you ran locally carried your full identity. A Personal Access Token in CI does not, unless it was granted the right scope.

mcp-publisher login github-oidc

# Uses the workflow's OIDC token — nothing to store,
# nothing to rotate, and no PAT scope to get wrong.

HTTP verification proves the same thing and grants the same com.example.*/* namespace. It is the better choice when DNS is managed by someone else, or when you want the proof to live in the same repo as the code.

# /.well-known/mcp-registry-auth
v=MCPv1; k=ed25519; p=${PUBLIC_KEY}

PRIVATE_KEY="$(openssl pkey -in key.pem -noout -text \
  | grep -A3 "priv:" | tail -n +2 | tr -d ' :\n')"
mcp-publisher login http --domain "${MY_DOMAIN}" --private-key "${PRIVATE_KEY}"