Skip to main content
Glama
Sign In

dns-doctor

by dev.dnsdoctor
OverviewDiscussionsAdmin

Generate DMARC Record

generate_dmarc_record
Read-onlyIdempotent

Use this when the user asks to create, generate or write a DMARC record for a domain that has none. Build a DMARC record from scratch for a domain that has none, using a validating engine — never compose one yourself. policy is none|quarantine|reject; optional rua_email (aggregate-report destination), subdomain_policy, and strict_alignment. Every generated record carries np=reject — the DMARCbis tag for non-existent subdomains, which can have no legitimate aligned mail — independently of the p= you choose. The generated record is re-validated before it is returned. Present it verbatim; a human must approve before publishing.

Input Schema

NameRequiredDescriptionDefault
policyYesThe requested p= policy: 'none' monitors only, 'quarantine' sends failing mail to spam, 'reject' refuses it outright. Start at 'none' unless the domain's aggregate reports already justify enforcement.
rua_emailNoMailbox to receive DMARC aggregate (RUA) reports, as a plain address like dmarc@example.com. Strongly recommended: without it nobody can see who sends as the domain.
strict_alignmentNoSet true to emit strict alignment (aspf=s adkim=s), requiring an exact domain match instead of the organizational-domain match. Leave false unless you know every sender aligns strictly.
subdomain_policyNoOptional sp= policy for subdomains when it should differ from the main p= policy. Omit to let subdomains inherit p=.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / policy / description
      Added value: +"The requested p= policy: 'none' monitors only, 'quarantine' sends failing mail to spam, 'reject' refuses it outright. Start at 'none' unless the domain's aggregate reports already justify enforcement."
    • addedInput schema / properties / rua_email / description
      Added value: +"Mailbox to receive DMARC aggregate (RUA) reports, as a plain address like dmarc@example.com. Strongly recommended: without it nobody can see who sends as the domain."
    • addedInput schema / properties / strict_alignment / description
      Added value: +"Set true to emit strict alignment (aspf=s adkim=s), requiring an exact domain match instead of the organizational-domain match. Leave false unless you know every sender aligns strictly."
    • addedInput schema / properties / subdomain_policy / description
      Added value: +"Optional sp= policy for subdomains when it should differ from the main p= policy. Omit to let subdomains inherit p=."
  2. Changed2 schema fields changed
    • addedInput schema / properties / policy / enum
      Added value: +[
+  "none",
+  "quarantine",
+  "reject"
+]
    • changedInput schema / properties / subdomain_policy / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "none",
+      "quarantine",
+      "reject"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, and the description adds substantial non-obvious behavior: generation runs through a validating engine rather than free-form composition, np=reject is appended unconditionally regardless of the chosen p=, the output is re-validated before return, and it must be presented verbatim with human approval before publishing. Nothing here contradicts the annotations — generating a text record is consistent with readOnlyHint=true.

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?

Front-loaded with the trigger sentence, followed by dense, useful detail about validation, the forced np=reject tag, and the approval workflow. Slight redundancy in re-listing the policy enum values already spelled out in the schema keeps it from a 5.

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?

An output schema exists so return values need no explanation, and annotations carry the safety profile. The description covers the remaining agent-critical facts — the automatic np=reject tag, re-validation, verbatim presentation, and required human approval — leaving no meaningful gap for a 4-parameter generator.

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 coverage is 100% and the enum for policy is fully documented in the schema, so the baseline is 3. The description restates the policy enum values and names the optional parameters, which is largely redundant with the schema; its genuinely additive note (the automatic np=reject tag) is a record-construction behavior rather than a parameter semantic.

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?

States a specific verb (generate/create) and resource (DMARC record) plus a scope constraint — 'for a domain that has none' — which cleanly separates it from sibling build_dmarc_upgrade (which upgrades existing records) and validate_dmarc_record. An agent can route correctly without opening 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?

Explicit trigger is given ('when the user asks to create, generate or write a DMARC record for a domain that has none'), and the 'has none' clause acts as an implicit exclusion from the upgrade tool. However, no sibling is named as the alternative for domains that already have a record, so the routing is left partly to inference.

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

All dns-doctor toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources