Skip to main content
Glama

audit_spf_includes

Read-onlyIdempotent

Walks a domain's SPF include and redirect chain to reveal every authorized sender, count IPv4s, and flag broken, expiring, or registrable includes that could let strangers spoof email.

Instructions

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.
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, openWorld), the description discloses critical behavioral constraints: unverified domains are always reported as unverified, never as available, and registry_confirmed: false means DNS-only inference with limitations. It also states that no SPF fix record exists, preventing misuse, which is substantial disclosure beyond 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 front-loaded with the purpose sentence and then provides essential details in a structured list. It is longer than the calibration's ideal but every sentence carries information; minor repetition of 'never as available' could be tightened, but overall the density is justified by the tool's complexity.

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 there is no output schema, the description compensates by fully enumerating the return elements (resolved tree, lookup attribution, IPv4 count, all five finding types) and explaining edge cases like registry_confirmed and unverified domains. It also covers the alternative tool, making it contextually complete.

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 already documents the domain parameter with 100% coverage, including normalization and allowed forms. The description adds only contextual references to 'the audited domain's OWN record' but no new format or syntax rules, so the baseline of 3 is appropriate.

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 a specific action and resource: 'Audit a domain's SPF supply chain' and explicitly differentiates from sibling count_spf_lookups by mentioning it as the alternative for 10-lookup questions. It also enumerates the main outputs (resolved tree, findings, IPv4 count), which further clarifies 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 names count_spf_lookups as the alternative when only the 10-lookup limit matters, which provides a clear when-to-use/not-use boundary. The cautions about not treating findings as instructions and relaying to the domain owner are additional usage guardrails.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dnsdoctor/claude-plugin'

If you have feedback or need assistance with the MCP directory API, please join our Discord server