mcpbeat Sign in

TamingDNS MCP Server

by tamingdns Your server? Claim it
answering

TamingDNS is answering right now. Last checked 8 min ago. It exposes 10 tools.

Check SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT, BIMI, DANE and DNSSEC, and analyse email headers.

Uptime history 23 hours of history
23 hours agonow
100.0%
Uptime 24h
85 of 85 checks
10
Tools
read from the server
125 ms
Response time
average over 24h
open, no key
Access
streamable-http

Nothing serious here today

Today is the operative word: we check TamingDNS every 15 minutes and re-read its code on every release. Watch it and you find out the day that stops being true.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 8 min ago.

run in your terminal
claude mcp add mcp --transport http https://tamingdns.com/mcp
Settings → Connectors → Add custom connector, then paste this address
https://tamingdns.com/mcp
~/.codex/config.toml
[mcp_servers.mcp]
url = "https://tamingdns.com/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "mcp": {
      "url": "https://tamingdns.com/mcp"
    }
  }
}
.vscode/mcp.json
{
  "servers": {
    "mcp": {
      "type": "http",
      "url": "https://tamingdns.com/mcp"
    }
  }
}

Available tools 10

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

analyze
analyze_email_headers
Analyse a pasted block of raw email headers for spoofing and phishing tells. Input is the raw headers (everything up to the first blank line — "Show original" / "View source"); the message body is not required. Returns structured findings + a phishing verdict (likely_phishing/verify_sender/minor_concerns/legitimate/auth_incomplete) derived from SPF/DKIM/DMARC alignment (RFC 7489 §3.1), Microsoft composite-auth compauth reason codes (000/010 enforced failure, 601 intra-org implicit failure, 001 weak posture), ARC chain integrity (RFC 8617 §5.2), homoglyph / IDN look-alike From domains (Unicode UTS #39), header smuggling via duplicate singleton headers (RFC 5322 §3.6), display-name-as-address spoofing, hidden bidi/control characters (UAX #9), Received-chain timestamps running backward (RFC 5321 §4.4), link display-text-vs-href mismatches, originating-IP FCrDNS (RFC 8601), and RFC 8058 List-Unsubscribe deliverability posture (category:compliance, never moves the verdict). Findings include DMARC_FAILED, SPF_HARD_FAIL, DKIM_SIGNATURE_FAILED, COMPAUTH_EXPLICIT_FAILURE, COMPAUTH_INTRA_ORG_IMPLICIT_FAILURE, HOMOGLYPH_DOMAIN, DUPLICATE_HEADER, DISPLAY_NAME_SPOOFED_ADDRESS, RECEIVED_TIMESTAMPS_BACKWARD, URL_DISPLAY_MISMATCH, HIDDEN_CONTROL_CHAR, BRAND_IMPERSONATION, and more (registered in docs/finding-codes.md). `status` is the finding-severity aggregate; `verdict` is the authoritative phishing judgment; `analysis` carries the verdict object + per-mechanism authentication. For privacy the echoed `input` is a digest only (from / subject / message_id) — raw headers are never returned. Read-only.
bimi
check_bimi
Check default._bimi.<domain>: parses the BIMI record, validates the SVG Tiny-PS logo, inspects the VMC chain (expiry, EKU, SCT, issuer-accepted, SAN match, logotype hash), and verifies the DMARC prerequisite (p=quarantine/reject at pct=100 with no sp=none — the RFC 7489 reading Gmail and Apple Mail evaluate today). DMARCbis (RFC 9989) aware: t= is parsed into analysis.dmarc.t, t=y emits TESTING_MODE (warn under p=quarantine — bis receivers read it as none; info under p=reject), and a present pct= emits DEPRECATED_TAG (removed by RFC 9989 Appendix A.6, advisory only). Returns grade (A-F), structured findings, and an `analysis` block (logo/vmc/dmarc/provider_matrix). Read-only.
check
check_mx
Inspect a domain's MX / mail-routing posture. Resolves the apex MX RRset (priority-sorted), and for each host the A/AAAA addresses, PTR + forward-confirmed reverse DNS (FCrDNS), DANE TLSA at _25._tcp.<host>, IP-literal (RFC 5321 §5) and CNAME (RFC 2181 §10.3) violations, and the mail provider. Detects the null MX (RFC 7505), a null MX wrongly mixed with real MX, and the implicit MX via the apex A/AAAA when no MX exists (RFC 5321 §5). Probes the MTA-STS and TLS-RPT prerequisites over DNS (case-sensitive per RFC 8461/8460) with outage reported as unknown, never absence. Returns grade (A-F) with grade_reasons, a verdict (healthy/warnings/misconfigured/null_mx/no_mx/implicit_mx), structured findings (NO_MX_RECORD, MX_IMPLICIT_FALLBACK, NULL_MX, NULL_MX_WITH_OTHER, MX_POINTS_TO_IP, MX_POINTS_TO_CNAME, MX_HOSTNAME_UNRESOLVABLE, NO_PTR_RECORD, FCRDNS_MISMATCH, MX_IPV6_ONLY, MX_NO_TRANSPORT_SECURITY, MX_GATEWAY_RDNS_COSMETIC, MX_SINGLE_HOST, MX_DUPLICATE_HOST, MX_SHARED_PRIORITY, MX_MTA_STS_WITHOUT_TLS_RPT), and an `analysis` block (per-host enrichment incl. provider, ips with FCrDNS status, dane_tlsa, and the prerequisite probe results). DNSSEC AD is a UI-only signal, not gradeable through the DoH contract. Read-only.
dane
check_dane
Check SMTP DANE / TLSA records for a domain (RFC 7672). Resolves the MX hosts (falls back to the apex when none), looks up the TLSA record at _25._tcp.<mx-host> over binary DoH, classifies each record (usage 0-3 / selector 0-1 / matching 0-2 per RFC 7671 §2.1), and confirms the answer carried the DNSSEC AD bit — DANE is meaningless without DNSSEC, so an unsigned TLSA answer is the dominant failure mode. Returns grade (A-F) with grade_reasons, a verdict (valid/valid_with_warnings/no_dnssec/not_configured/error), structured findings (DANE_NO_TLSA, DANE_TLSA_HOST_UNSIGNED, DANE_PKIX_TA_USED_WITHOUT_CHAIN, DANE_TLSA_EXACT_MATCH, DANE_PARTIAL_COVERAGE, DANE_TLSA_INVALID_USAGE/SELECTOR/MATCHING), and an `analysis` block (per-host TLSA records + DNSSEC status, the spec-compliance signals, and the MTA-STS cross-signal). DNS-only: it never opens a port-25 STARTTLS handshake, so it proves the TLSA records exist, are well-formed, and are DNSSEC-signed — never that they match the live cert (Hostinger and Cloudflare both block outbound 25). Read-only.
dkim
check_dkim
Look up a DKIM public key at <selector>._domainkey.<domain> and validate it. Detects key revocation (empty p=), RSA key length (KEY_TOO_SHORT below 1024, KEY_WEAK below 2048), SHA-1 hash deprecation, and t=y test mode. For selector1/selector2 it also checks a Microsoft 365 CNAME target carries the token Microsoft builds for the domain (M365_DKIM_CNAME_MISMATCH), even when no key resolves. Returns an `analysis` block with the per-key facts (key_type, key_bits, key_strength, revoked, test_mode, hash_algs, m365_cname). Read-only.
dmarc
check_dmarc
Check the _dmarc record for a domain with DUAL discovery: the RFC 7489 §6.6.3 organisational-domain ladder (what major receivers enforce today — grade/verdict anchor to it) AND the RFC 9989 §4.10 DNS Tree Walk (8-query cap, psd=n/y stop rules, fewest-labels org selection) into analysis.discovery {legacy, tree_walk, diverges}. When the two methods select different policy records or org domains, DISCOVERY_DIVERGENCE (warn) fires with a one-notch grade downgrade. Also DMARCbis tag-aware: t=/np=/psd= parsed into analysis.tags, removed tags (pct/rf/ri) emit DEPRECATED_TAG, t=y emits TESTING_MODE with a one-notch downgrade. Returns the grade (A-F) with grade_reasons, a verdict (enforced/partial/monitoring/monitoring_blind/invalid/not_configured), structured findings (NO_DMARC_RECORD, MULTIPLE_DMARC_RECORDS, INVALID_TAG, POLICY_NONE, POLICY_NONE_NO_RUA, PCT_BELOW_100, RUA_MISSING_UNDER_ENFORCEMENT, SP_NOT_ENFORCED, EXTERNAL_RUA_UNAUTHORIZED, DMARC_INHERITED_FROM_ORG, TESTING_MODE, DEPRECATED_TAG, DISCOVERY_DIVERGENCE), and an `analysis` block with the lookup ladder, discovery, source (self/org), org_domain, normalised tags, per-recipient RUA/RUF external-authorisation detail (RFC 7489 §7.1), and rua_unauthorised. Read-only.
dnssec
check_dnssec
Validate a domain's DNSSEC chain of trust. Pulls DS (at the parent), DNSKEY, and RRSIG over binary DoH, walks the chain zone-by-zone (root → TLD → domain) recomputing each DS digest against the published DNSKEYs (RFC 4034 §5.1.4), and cross-checks the AD bit across Cloudflare, Google, Quad9, and OpenDNS so a single resolver's caching can't mask a break. Returns grade (A-F) with grade_reasons, a verdict (signed/signed_no_ds/partial/unsigned/broken), structured findings (DNSSEC_UNSIGNED, DNSSEC_DS_MISSING_AT_PARENT, DNSSEC_DS_ALGORITHM_DEPRECATED, DNSSEC_DNSKEY_ALGORITHM_DEPRECATED, DNSSEC_RRSIG_EXPIRED, DNSSEC_BOGUS, DNSSEC_AD_BIT_MISSING), and an `analysis` block (the full chain-walk, the per-resolver validator matrix, NSEC3 iteration/opt-out, CDS/CDNSKEY publication, signing mode, root-anchor state). Unsigned is the common case and returns status "info" (DNSSEC is optional), not a failure; signed_no_ds (DNSKEY published, no DS at the parent yet) is treated by validators as unsigned and also returns "info"; a published-but-non-validating zone returns "fail". Read-only.
mta
check_mta_sts
Check MTA-STS (RFC 8461) for a domain: the _mta-sts TXT record (strict §3.1 selection — case-sensitive leading v=STSv1, exactly one record, required 1-32 alphanumeric id), the policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt fetched WITHOUT following redirects (§3.3), strict §3.2 policy validation (version/mode/max_age required, mx required unless mode none, max_age ≤ 31557600, duplicate keys first-wins), the policy-host X.509 certificate (§3.3 — an invalid cert means compliant senders fetch no policy), and live MX coverage against the mx: patterns (§4.1 — wildcards match exactly one leftmost label; coverage is all/partial/none, partial meaning strict senders skip the uncovered hosts per §5.1). Returns grade (A-F) with grade_reasons, a verdict (enforced/testing/reporting_only/invalid/not_configured), structured findings (MTA_STS_NO_TXT_RECORD, MTA_STS_RECORD_INVALID, MULTIPLE_MTA_STS_RECORDS, MTA_STS_POLICY_UNREACHABLE, MTA_STS_POLICY_REDIRECT, MTA_STS_POLICY_INVALID, MTA_STS_CERT_INVALID, MTA_STS_MODE_NONE, MTA_STS_MODE_TESTING, MTA_STS_MX_MISMATCH, MTA_STS_MX_PARTIAL_COVERAGE, MTA_STS_MAX_AGE_TOO_LOW), and an `analysis` block (record, policy incl. fetch_stage, cert, MX coverage detail, TLS-RPT/DANE cross-signals). Read-only.
spf
check_spf
Check the SPF record for a domain. Returns the raw record, grade (A-F), the terminal `all` qualifier (resolved through redirect= chains), structured findings (NEAR_LOOKUP_LIMIT, LOOKUP_LIMIT_EXCEEDED, PLUS_ALL_DANGEROUS, PTR_MECHANISM_DEPRECATED, etc.), and an `analysis` block with the expanded include/redirect tree and the RFC 7208 §4.6.4 lookup count. Read-only.
tls
check_tls_rpt
Check the TLS-RPT (SMTP TLS Reporting, RFC 8460) record at _smtp._tls.<domain>. Strict §3 classification: the record must BEGIN with the case-sensitive v=TLSRPTv1 tag, more than one such record means receivers treat TLS-RPT as not implemented, and rua= is required. Validates every rua= destination syntactically (mailto:/https:// — reachability is never probed), and detects the MTA-STS and DANE prerequisites over DNS (TLSA at _25._tcp of the lowest-preference MX) with outage reported as unknown, never as absence. Returns grade (A-F) with grade_reasons, a verdict (valid/partial/invalid/not_configured), structured findings (TLS_RPT_NO_RECORD, TLS_RPT_INVALID_VERSION, TLS_RPT_MULTIPLE_RECORDS, TLS_RPT_NO_RUA, TLS_RPT_RUA_INVALID_URI, TLS_RPT_NO_VALID_RUA, TLS_RPT_NO_ENFORCEMENT_POLICY), and an `analysis` block with parsed tags, per-URI rua validation detail, and the prerequisite probe results. Read-only.

Endpoints

URLTransportStateLatencyChecked
https://tamingdns.com/mcp streamable-http answering 90 ms 8 min ago

Alternatives to TamingDNS

same job, measured the same way
SecLens.ONE Email Security
by seclens

Assess any domain's email security across SPF, DMARC, DKIM, MTA-STS, DNSSEC, DANE, and TLS-RPT.

3 tools answering
DnsGuard
by workers-mike-tusa-dnsguard

Check a domain's email authentication: SPF, DKIM, DMARC, BIMI, MX, MTA-STS, TLS-RPT. Score + fixes.

1 tools answering
P
Powerline Email Tools
by powerline

Email deliverability checks: SPF, DKIM, DMARC, BIMI, MTA-STS, blacklists, headers, spam words

5 tools answering
DomainRef - domain and email security check
by domainref

Pay-per-call domain and email security check: SPF, DKIM, DMARC, TLS, DNSSEC, BIMI, with exact fixes.

2 tools answering
IntoDNS.ai DNS & Email Security Scanner
by intodns

DNS and email security: check SPF, DKIM, DMARC, DNSSEC, DANE and build the records. 45 tools.

196 installs/wk 45 tools answering
scan.mx Email Diagnostics
by scan

Email deliverability check: MX, SPF, DKIM, DMARC, blacklists, MTA-STS, DNSSEC, BIMI. Graded, no key.

9 tools answering
Domain Security
by ortamarco

Audit a domain's email and web security: SPF, DKIM, DMARC, MTA-STS, DNSSEC, TLS, WHOIS. No API keys.

73 installs/wk local only
Email Deliverability Checker
by kryptoscan

Check SPF, DKIM, DMARC, blocklists, reverse DNS and email headers against Gmail/Yahoo sender rules.

3 tools answering

TamingDNS — questions

Answers built from our own checks of this server.

What can TamingDNS do?
It exposes 10 tools, read directly from the server on our last check. Among them: analyze_email_headers, check_bimi, check_dane, check_dkim, check_dmarc, check_dnssec and 4 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is TamingDNS working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 85 of 85 checks got a reply (100.0%), average response time 125 ms. The bar chart above shows every period we have measured.
How do I connect TamingDNS?
Copy the ready config from this page. We generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each in the form that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does TamingDNS need an API key?
No. TamingDNS completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 10 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is TamingDNS?
It answers our handshake in 125 ms on average, which is faster than 90% of all working MCP servers we measure. That puts it in the quick quarter of the ecosystem. The comparison comes from our own checks across the whole registry, every 15 minutes.