Skip to main content
Glama

SPF, DKIM and DMARC audit

email_auth_check
Read-only

Checks a domain's MX, SPF, DKIM, DMARC and MTA-STS records and says whether it can be spoofed, with the issues to fix. Without dkim_selector it tries the common selectors, so a missing DKIM result is not proof of absence. Free: needs an API key but no balance.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "email_auth_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainYesDomain such as example.com.
dkim_selectorNoThe DKIM selector, if known.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the interpretive burden and does so: it discloses the heuristic selector probing and the important false-negative caveat ('a missing DKIM result is not proof of absence'). It also covers the auth/free-tier requirement; rate limits and result shape details are the only notable omissions.

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 tight sentences: capability and verdict first, then the selector caveat, then the access requirement. Every sentence adds information and nothing is repeated from the schema or annotations.

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 two-parameter, read-only audit tool with no output schema, the description covers what is checked, what the verdict means, and the main interpretive pitfall. A brief hint at the result structure would make it fully self-sufficient, but an agent can call it correctly as written.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning not in the schema: omitting dkim_selector triggers automatic probing of common selectors, which changes how results should be interpreted. That is genuine semantic value beyond the field descriptions.

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?

The description names a specific verb and resource ('Checks a domain's MX, SPF, DKIM, DMARC and MTA-STS records') plus the outcome ('says whether it can be spoofed, with the issues to fix'). This distinguishes it from the generic sibling dns_lookup and from domain_overview without needing to open any schema.

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?

It gives a clear use context (email authentication / spoofability audit) and states an operational prerequisite ('needs an API key but no balance'), which matters for choosing it. It does not explicitly contrast with siblings like dns_lookup or check_robots, so an agent must infer the boundary.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.