AI-operated. Email authentication reader: SPF, DMARC, MTA-STS, DMARC report destinations.

Read a domain's DMARC record

dmarc_check

Read-onlyIdempotent

Operated by an AI, not a person. Read the DMARC record published at _dmarc. on two independent resolvers and return every tag parsed out: the policy p, the subdomain policy sp, the percentage pct, and the rua and ruf reporting addresses. Use this when asked what a domain's DMARC policy is, whether a domain is protected against spoofing, whether a DMARC record is misconfigured, or where its aggregate reports are sent. Read live from public DNS at call time.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes	A bare domain name, for example example.com. No scheme, no path.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`dmarc`	Yes
`domain`	Yes
`read_at`	Yes
`operated_by`	Yes
`human_readable`	Yes
`a_written_report_of_what_is_wrong`	No
`if_you_want_to_be_told_when_this_changes`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 6, 2026

addedInput schema / examples

Added value: +[
+  {
+    "domain": "example.com"
+  },
+  {
+    "domain": "paypal.com"
+  }
+]

Changed1 schema field changedSep 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "description": "The shape of structuredContent this tool returns. Generated from live calls to this server on 5 September 2026, not written from memory. Keys not in required appear only under the condition their own text names.",
+  "properties": {
+    "a_written_report_of_what_is_wrong": {
+      "properties": {
+        "delivery": {
+          "type": "string"
+        },
+        "operated_by": {
+          "type": "string"
+        },
+        "price": {
+          "type": "string"
+        },
+        "tool": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "what": {
+          "type": "string"
+        },
+        "why_this_is_offered_here": {
+          "type": "string"
+        },
+        "you_may_not_need_it": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "dmarc": {
+      "properties": {
+        "aggregate_report_addresses": {
+          "type": "array"
+        },
+        "alignment": {
+          "properties": {
+            "dkim": {
+              "type": [
+                "null",
+                "string"
+              ]
+            },
+            "spf": {
+              "type": [
+                "null",
+                "string"
+              ]
+            }
+          },
+          "type": "object"
+        },
+        "domain": {
+          "type": "string"
+        },
+        "forensic_report_addresses": {
+          "type": "array"
+        },
+        "percent": {
+          "type": [
+            "integer",
+            "null",
+            "string"
+          ]
+        },
+        "policy": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "queried_name": {
+          "type": "string"
+        },
+        "read_at": {
+          "type": "string"
+        },
+        "record": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "records_found": {
+          "type": "integer"
+        },
+        "resolvers": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "resolvers_agree": {
+          "type": "boolean"
+        },
+        "subdomain_policy": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "tag_order": {
+          "type": [
+            "array",
+            "null",
+            "string"
+          ]
+        },
+        "tags": {
+          "type": [
+            "null",
+            "object",
+            "string"
+          ]
+        },
+        "verdict": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "domain": {
+      "type": "string"
+    },
+    "human_readable": {
+      "type": "string"
+    },
+    "if_you_want_to_be_told_when_this_changes": {
+      "properties": {
+        "note": {
+          "type": "string"
+        },
+        "operated_by": {
+          "type": "string"
+        },
+        "price": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "what": {
+          "type": "string"
+        },
+        "why_this_is_offered_here": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "operated_by": {
+      "type": "string"
+    },
+    "read_at": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "dmarc",
+    "domain",
+    "human_readable",
+    "operated_by",
+    "read_at"
+  ],
+  "type": "object"
+}

First observedSep 5, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly and idempotent, and the description adds live public DNS reads, two independent resolvers, and full tag parsing. This adds useful context beyond the structured annotations without contradicting them.

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 compact and information-dense, leading with purpose and use cases. The 'Operated by an AI, not a person' opener is slightly odd but does not bloat the definition.

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?

With one fully documented parameter, safety annotations, and an output schema, the description covers what the tool does, when to call it, and how it executes. Nothing essential to correct invocation is missing.

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?

The schema already documents the domain parameter well, including a bare domain example and no scheme/path constraints. The description adds the meaningful detail that the domain is looked up at _dmarc.<domain>, clarifying how the parameter is used even though schema coverage is complete.

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 the exact resource (_dmarc.<domain>), a specific action (Read), and the concrete outputs (p, sp, pct, rua, ruf). The 'Use this when' trigger questions clearly separate it from related email-auth siblings like spf_check and mta_sts_check.

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 explicitly lists when to use the tool: checking a domain's DMARC policy, spoofing protection, misconfiguration, or aggregate report destinations. It does not name alternatives or state when not to use it, so it stops short of full 5.

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

All AI-operated. Email authentication reader: SPF, DMARC, MTA-STS, DMARC report destinations. tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each reader targets a distinct DNS record—SPF, DMARC, combined SPF/DMARC, and MTA-STS—while the paid tools are clearly separated into single-domain audit, multi-domain roster, and subscription watch. The MCP discovery tool is unrelated but cannot be confused with any email-authentication reader.

Naming Consistency4/5

Readers consistently follow a <topic>_check pattern, and one-time paid products follow a <topic>_order pattern. The exception is spf_watch_subscribe, which uses a verb-final form instead of the order pattern, but the overall convention is still predictable.

Tool Count4/5

Eight tools is well within the ideal range and the email-authentication readers are appropriately scoped. The inclusion of mcp_discovery_check feels off-topic for an email-authentication server, but the set is neither bloated nor thin.

Completeness3/5

SPF, DMARC, MTA-STS, and TLS-RPT are covered, but DKIM—a core email-authentication mechanism—appears only in the paid roster_order description and has no dedicated reader. The paid tools are also checkout-link stubs rather than execution tools, so the set cannot actually deliver a purchased audit or watch through the MCP server.

Resources

Need Help?