email-check

Get Dmarc Record

get_dmarc_record

Read-onlyIdempotent

DMARC record, policy, and whether it actually protects.

Returns the DMARC TXT record at _dmarc., its policy (none / quarantine / reject), the percentage it applies to, and whether that policy protects against spoofing. Also flags the case of MULTIPLE DMARC records, which RFC 7489 requires receivers to treat as no policy at all — a domain in that state is unprotected however strict its records look. A policy of "none" is monitoring only and does not stop forged mail. Use when assessing whether mail claiming to be from a domain can be trusted.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain to check, e.g. "example.com". A full email address is accepted and the domain is taken from it.

Output Schema

TableJSON Schema

Name	Required	Description
`found`	No
`domain`	Yes
`policy`	No	"ignored" means duplicate records cancelled the policy out.
`record`	No
`meaning`	No
`percent`	No	The pct= tag; defaults to 100.
`protects`	No	False for p=none (monitoring only) and for duplicate records.
`all_records`	No	Present only when more than one DMARC record exists.
`multiple_records`	No	RFC 7489 requires receivers to apply NO policy when more than one record exists.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and idempotentHint annotations, the description adds nuanced behavior: the interpretation of multiple DMARC records as no policy, the distinction of 'none' as monitoring-only, and the actual protection assessment. These details materially help an agent reason about results.

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?

The description is front-loaded with the core answer, then adds important caveats. Every sentence earns its place; there is no filler. The length is justified by the valuable edge-case explanations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not detail return formatting. It covers the purpose, the edge cases, and the usage context, making it complete for an agent to invoke correctly. No gaps.

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 covers 100% of the single parameter, including the acceptance of a full email address. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is warranted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific verb (returns), resource (DMARC record) and scope (policy, percentage, protection). It distinguishes from siblings like get_spf_record and get_mx_records by focusing on DMARC-specific details. The purpose is unmistakable.

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?

Explicitly states when to use: 'Use when assessing whether mail claiming to be from a domain can be trusted.' It also clarifies the implications of a 'none' policy and the multiple-record edge case, giving the agent clear context. Does not explicitly contrast with siblings, but the usage guidance is direct.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All email-check tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation4/5

check_email_domain is the comprehensive composite, while get_dmarc_record, get_mx_records, and get_spf_record target distinct record types. However, check_email_domain overlaps somewhat with each of the single-record tools, though the descriptions clearly state when to use each.

Naming Consistency4/5

Three tools follow the get_<record>_records pattern, and one uses check_<noun>_domain. The verbs are consistent (check/get) and the object is always a domain-related resource, making the naming clear. The slight variation in verb (check vs get) is minor and justified by the composite nature.

Tool Count5/5

Four tools cover the domain email checking domain well: a composite plus the three constituent lookups. This is a tight, purposeful set without redundancy or bloat, appropriate for a focused MCP server.

Completeness4/5

The set covers MX, SPF, DMARC, and a combined check, which is comprehensive for email posture. There is no tool for DKIM or other email authentication records, but DKIM is less commonly checked and the existing tools provide a thorough overview. Missing a tool to check for other SPF-like mechanisms (e.g., TXT related) is minor.

Resources

Need Help?