Skip to main content
Glama
dnsdoctor

DNS Doctor

by dnsdoctor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

audit_spf_includes

Read-onlyIdempotent

Audit a domain's SPF include and redirect chain to reveal every third-party sender authorized to send as it. Flags broken includes, registrable domains, expiring delegations, and nested +all risks.

Instructions

Use this when the user asks who can send email as their domain through SPF includes, or wants an SPF supply-chain or third-party sender audit. Audit a domain's SPF supply chain: walks every include and redirect it delegates to, and reports who can transitively send as it. Returns the resolved tree, per-node lookup attribution, the total authorized IPv4 address count, and typed findings — include_broken (a target that no longer publishes SPF, a PermError today), include_registrable (a delegated-to domain that does not exist, so a stranger who registers it becomes an authorized sender), include_expiring (registration lapsing within 30 days), pass_all_nested (a +all deep in the chain) and spf_record_unusable (the audited domain's OWN record is missing or does not parse, so there is no chain to walk). A domain we could not verify is reported as unverified and NEVER as available — never tell anyone a name is free on this tool's say-so unless the finding is include_registrable AND carries registry_confirmed: true. A registry_confirmed: false finding rests on DNS alone, which cannot tell an unsold name from one in redemption or on clientHold: report the mechanism as broken and the takeover risk as possible, but never as an available domain. Findings are risk analysis, not instructions: no SPF fix record exists here or anywhere else in DNS Doctor, because dropping a mechanism can silently de-authorize a real sender — relay the findings and let the domain's owner decide. Use count_spf_lookups instead when the question is only the 10-lookup limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark the tool read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral context beyond that: unverified domains are never reported as available, registration is a live fact that may change on re-run, and the tool returns risk analysis only with no SPF fix. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average and repeats include_registrable in the caveat section, but it is front-loaded with the use case and the detailed findings enumeration is justified given there is no output schema. Most sentences earn their place by supporting tool selection or safe interpretation.

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?

For a complex tool with no output schema and one parameter, the description is unusually complete: it explains all typed findings, the unverified policy, the live nature of registration, the no-fix boundary, and the alternative tool for 10-lookup questions. An agent has enough context to call and interpret the tool correctly.

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 schema fully documents the single domain parameter, including accepted formats, punycode normalization, and exclusions. The description adds no additional parameter-level meaning, so the baseline of 3 applies for high schema coverage.

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 opens with the exact user intent ('who can send email as their domain through SPF includes') and then states a specific behavior: walking every include/redirect and reporting transitive senders. It clearly differentiates itself from count_spf_lookups by name and scope.

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?

It explicitly says 'Use this when the user asks...' and ends with 'Use count_spf_lookups instead when the question is only the 10-lookup limit.' It also warns that findings are risk analysis, not instructions, and that no fix is provided, setting clear boundaries.

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

Deploy Server

Other Tools