The Model Context Protocol is the standard that lets assistants like Claude call external tools, and it collapses that whole loop into a single sentence: Is acme.com protected against spoofing, and is anyone actually reading its DMARC reports?

Install it in one line

plaindmarc-mcp is a small, read-only MCP server that wraps a set of public email-authentication endpoints. Every tool does a live DNS lookup and returns structured fields plus a one-sentence plain-English summary.

Claude Code:

claude mcp add plaindmarc -- npx -y plaindmarc-mcp

Claude Desktop, or any other MCP client:

{
  "mcpServers": {
    "plaindmarc": {
      "command": "npx",
      "args": ["-y", "plaindmarc-mcp"]
    }
  }
}

There is no signup step and no API key to paste, which matters more than it sounds: the friction in most tooling is not the tool, it is the account you have to make before you can try it. Then ask something like "Is example.com protected against email spoofing, and is anyone watching its DMARC reports?"

The seven tools

• check_dmarc - the verdict and a letter grade (A-F), the policy in force, and whether aggregate reports are actually being received. A domain can be protected yet completely unmonitored; this says so.
• check_spf - the SPF record, the DNS-lookup count against the limit of 10, and whether it ends in a protective -all/~all or a permissive one.
• check_dkim - a selector's key, following CNAME chains the way most providers publish: found, missing, revoked or weak.
• check_bimi - BIMI eligibility: the logo, the VMC, and whether DMARC is at enforcement (a BIMI record at p=none never shows a logo).
• check_mta_sts - MTA-STS and TLS-RPT DNS setup for enforced, reported TLS delivery.
• generate_dmarc_record - a valid DMARC record to publish.
• analyze_dmarc_report - a raw aggregate (rua) XML report, explained in plain English.

Honest by design

An agent repeats whatever a tool tells it, more or less verbatim, to a human being who is going to act on it. That changes what a good answer looks like.

A DNS failure or a missing record returns an explicit unknown state with the reason attached, never a guessed verdict, and a FAIL is never softened into a maybe. BIMI is reported as eligibility rather than a promise, because mailbox providers apply their own rules on top. The MTA-STS check says plainly that it cannot fetch the HTTPS policy file remotely, instead of pretending otherwise.

The record generator is the clearest example. Ask it for p=reject or p=quarantine straight out of the gate and it pushes back: start at p=none, watch the reports for a few weeks, then tighten. Skip that and enforcement starts blocking your own legitimate mail. It also flags that pct= is deprecated in DMARCbis, which is exactly the kind of detail an assistant gets confidently wrong from stale training data.

Requests are concurrency-capped with backoff, so an agent auditing a whole portfolio of domains finishes cleanly.

Where a one-off check stops being enough

These tools read DNS at the moment you ask. That answers "is this configured correctly today", which is the right question when you are onboarding a domain or debugging a bounce. It is not the question that catches a live problem. The verdict that matters there arrives three days into a spoofing run, from the aggregate reports receivers send back, and nobody reads those XML files voluntarily.

So treat the MCP server as the fast half of the job: instant answers, no account, inside the tool you are already working in. Then put something in place that keeps watching after the check comes back green.

The server is on npm as plaindmarc-mcp.

Originally published on the PlainDMARC blog: A DMARC MCP server for your AI agent