domain-security-mcp-server

DKIM Record Check

dkim_check

Read-onlyIdempotent

Check a domain's DKIM public keys by probing specified or common selectors. Returns found records, key types, and findings to verify email authentication.

Instructions

Look up DKIM public keys at ._domainkey.. Because DKIM selectors are arbitrary and undiscoverable, you should pass the selector(s) your mail provider uses for a definitive answer; otherwise a curated list of common selectors is probed and a miss is inconclusive.

Args:

domain (string): the domain to check.
selectors (string[], optional): DKIM selectors to probe.
response_format ('markdown' | 'json'): output format (default 'markdown').

Returns: { any_found, probed_selectors, selectors[{selector, found, record, key_type}], findings[] }.

Examples:

"Does acme.com publish a DKIM key for selector 'google'?" -> dkim_check(domain="acme.com", selectors=["google"])
"Find any DKIM keys for acme.com" -> dkim_check(domain="acme.com")

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain to check, e.g. 'example.com'.
`selectors`	No	DKIM selectors to check (e.g. ['google']). If omitted, common provider selectors are probed — absence is then inconclusive.
`response_format`	No	Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes
`findings`	Yes
`any_found`	Yes
`selectors`	Yes
`probed_selectors`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.2.1Sep 14, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```
addedInput schema / properties / domain / maxLength
```
Added value: +253
```
addedInput schema / properties / selectors / items / maxLength
```
Added value: +63
```
addedInput schema / properties / selectors / maxItems
```
Added value: +50
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv1.0.0Jun 8, 2026

TDQS

A4.7/5.0

Behavior4/5

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

No contradictions with annotations (readOnly, openWorld, idempotent, non-destructive). The description adds essential behavioral context: the probing of a curated selector list, the inconclusive nature when selectors are omitted, and the return structure. However, since annotations already indicate it's read-only and non-destructive, the extra transparency credit is capped; still, the details on selector behavior are valuable.

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 well-structured: a lead sentence stating the action, a clear conditional on selectors, a concise Args section mirroring the schema, a Returns section, and two practical examples. Every sentence adds value, no redundancy, and key caveats are front-loaded.

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?

Given the tool's moderate complexity, full schema coverage, annotations, and an output schema that documents the return structure, the description covers all essential aspects: what it does, how to use it, edge cases (inconclusive results), and example invocations. The agent has enough to call it correctly without missing information.

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 schema already describes each parameter. The description reinforces the meaning of domain and selectors, and clarifies the response_format choices. Since schema does the heavy lifting, baseline is 3, but the description adds the critical insight that selectors are undiscoverable and omission is inconclusive, which is a meaningful semantic enhancement.

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 explicitly states it looks up DKIM public keys at a specific DNS naming pattern, distinguishes it from siblings by focusing on DKIM selectors, and includes concrete example queries. This is a clear, specific purpose that an agent can act on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises when to pass selectors (for a definitive answer) and warns that omitting them yields inconclusive results. It also provides two examples that illustrate the two usage modes. This gives clear, operational guidance beyond the schema.

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