A
licenseNot graded
qualityC
maintenanceEnables users to audit a domain's email-authentication DNS configuration—covering SPF, DKIM, DMARC, MX, BIMI, MTA-STS, and TLS-RPT—and receive issues, recommendations, a 0–100 score, and A–F grade.
MIT
DMARC Shark — Email DNS Checker
Server Details
Check a domain's public SPF, DMARC, MX and DKIM DNS records on demand. No account required.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
- Status
- Unhealthy
- Uptime
- 92.7% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
A3.9/5.0
Scored across 2 tools
Disambiguation5/5
The two tools split cleanly along the read/write boundary: check_domain performs live DNS queries and mutates the saved snapshot, while get_saved_result only reads the stored snapshot with no network activity. There is no realistic scenario where an agent would confuse them.
Naming Consistency5/5
Both names follow a consistent snake_case verb_noun pattern (check_domain, get_saved_result), with verbs that accurately signal the mutation vs. read distinction. No mixed conventions or vague naming.
Tool Count3/5
Two tools is on the thin side, though it mirrors the minimal check-then-retrieve workflow. It earns its place functionally, but the surface is small enough that the rubric treats it as borderline.
Completeness3/5
The checking surface itself is broad (SPF, DMARC, MX, DANE/TLSA, TLS-RPT, BIMI, MTA-STS, DKIM, DNSSEC), but there is no way to list or compare historical snapshots, query a single record type in isolation, or manage expiry, which are notable gaps for a monitoring-oriented checker.
Available Tools
2 toolscheck_domainCheck a domain's public email DNSAInspect
Runs fresh, bounded public SPF, DMARC, MX, DANE/TLSA, TLS-RPT, BIMI, MTA-STS, optional DKIM-selector and resolver DNSSEC validation checks. Changes the public saved snapshot. Rate limited. Clients should obtain user approval before calling. Findings do not prove message authentication, TLS use or enforcement, DANE certificate matching, brand verification, logo display, or report delivery.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| selectors | No | ||
| bimi_selector | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| saved | Yes | |
| dnssec | No | |
| domain | Yes | |
| source | Yes | |
| findings | Yes | |
| checked_at | Yes | |
| recommendations | Yes |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations by disclosing that the call mutates state ('Changes the public saved snapshot'), is rate limited, and requires user approval before invocation. The closing sentence is unusually valuable: it enumerates the inferences the findings do NOT support (message authentication, TLS enforcement, DANE matching, brand verification, logo display, report delivery), which directly guards against the most likely misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with zero filler, front-loaded with the action and scope before the operational constraints and the caveats. Every clause carries information an agent needs; nothing restates the tool name or the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, state-mutating, network-dependent tool the description covers the important ground, and an output schema exists so return values need not be explained. The remaining gap is parameter-level: the purpose and constraints of 'bimi_selector' and the two-item cap on 'selectors' are absent given 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden: it explains that DKIM selectors are optional ('optional DKIM-selector'), which gives meaning to the 'selectors' array. It says nothing about the required 'domain' parameter, the maxItems=2 cap on selectors, or the 'bimi_selector' parameter at all, so a third of the parameters remain undocumented anywhere and the two-item limit will surprise an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb ('Runs fresh, bounded') and enumerates the exact record types checked (SPF, DMARC, MX, DANE/TLSA, TLS-RPT, BIMI, MTA-STS, DKIM-selector, DNSSEC), which is far beyond a tautology. It never names the sibling get_saved_result, so the distinction between a fresh check and retrieving an existing result is only implied by 'Changes the public saved snapshot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Runs fresh' signals the use case and the approval prerequisite plus rate limiting give operational context an agent needs before calling. However, there is no explicit statement of when an agent should call get_saved_result instead of paying for a fresh check, so the alternative is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_saved_resultRead a saved domain checkARead-onlyIdempotentInspect
Reads the last saved, timestamped public snapshot without making any DNS queries. Results expire after 90 days.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| saved | Yes | |
| dnssec | No | |
| domain | Yes | |
| source | Yes | |
| findings | Yes | |
| checked_at | Yes | |
| recommendations | Yes |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real value beyond them: no DNS queries are issued and results expire after 90 days. It does not say what happens when no saved snapshot exists or the snapshot has expired.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the cached-read constraint front-loaded before the expiry caveat. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. However, for a lookup that can plausibly fail on missing or expired snapshots, the description omits the failure behavior and does not clarify the domain argument, leaving gaps for a simple one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has zero schema description coverage, and the description never explains the domain argument (expected format, whether subdomains are allowed, whether it must match a previously checked domain). The parameter name is self-evident, but the description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Reads the last saved, timestamped public snapshot.' The phrase 'without making any DNS queries' implicitly distinguishes it from the live-check sibling, though it never names check_domain directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is hinted at through the negative constraint (no DNS queries), which suggests using this instead of a live lookup, but there is no explicit when-to-use statement or named alternative. An agent must infer that check_domain is the live counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
check_domain2 fields changed- added
Input schema / properties / bimi_selectorAdded value: +{ + "maxLength": 253, + "type": "string" +} - added
Output schema / properties / dnssecAdded value: +{ + "type": "object" +}
- Changed
get_saved_result1 field changed- added
Output schema / properties / dnssecAdded value: +{ + "type": "object" +}
2 tool updates
- First observed
check_domain - First observed
get_saved_result
Related MCP Connectors
SPF, DKIM, DMARC, MTA-STS and domain-expiry checks for any domain, with SPF lookup counts.
Check a domain's DMARC, SPF, DKIM, MX, BIMI and MTA-STS records. Generate SPF and DMARC records.
Free live DNS, SPF/DMARC/MX, DKIM and WHOIS lookups for any domain. No key needed to start.
Free, read-only email and DNS checks: SPF, DKIM, DMARC, MX, DNS records, blocklists, domain health.
Related MCP Servers
- AlicenseAqualityDmaintenancePerforms domain security posture checks including SPF, DKIM, DMARC, TLS, and HTTP security headers.37 npmMIT
- AlicenseAqualityCmaintenanceChecks email deliverability: audits a domain's SPF (including the 10-lookup limit), DKIM, DMARC and MX records with ranked fixes, checks a sending IP's reverse DNS and blocklist listings, and tests email headers against Gmail and Yahoo bulk sender requirements.3MIT
- AlicenseNot gradedqualityDmaintenanceEnables DNS and email security analysis through passive and active scanning capabilities. Provides comprehensive domain security checks including SPF, DMARC, DNSSEC validation, MX record analysis, and SMTP connectivity testing.MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.