A DMARC MCP server for your AI agent

Checking email authentication is exactly the kind of look-it-up-and-explain job you hand to an agent. plaindmarc-mcp gives it seven read-only tools — DMARC, SPF, DKIM, BIMI and MTA-STS checks, DMARC record generation, and aggregate-report analysis — with no API key and no account. This is the quickstart, for you or for the agent reading it.

What it is

The Model Context Protocol (MCP) is how assistants like Claude pick up tools. plaindmarc-mcp is a small MCP server that wraps PlainDMARC's public tool endpoints. Every tool is read-only: it does a live DNS lookup (or, for the generator, builds a string) and returns structured fields plus a one-sentence plain-English summary. It never writes DNS, never signs in, and collects nothing about you.

Install

Claude Code:

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

Claude Desktop, or any MCP client — add to your MCP config:

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

Then ask, for example, "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, and whether reports are actually being received. A domain can be protected yet 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, how 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

The tools are built to tell an agent the truth, because an agent will quote them to a person:

• A DNS failure or a missing record returns an explicit unknown state with the reason — never a guessed verdict, and a FAIL is never softened.
• check_bimi reports eligibility, not a promise — mailbox providers apply their own rules.
• check_mta_sts states plainly that it can't fetch the HTTPS policy file remotely, so it doesn't pretend to.
• generate_dmarc_record warns if you ask for p=reject or p=quarantine directly: start at p=none, watch the reports, then tighten — or enforcement blocks legitimate mail. It also notes that pct= is deprecated in DMARCbis.

The same checks power the free DMARC checker and the other browser tools; the MCP server is the agent-facing door to them, and requests are concurrency-capped with backoff so an agent auditing a whole portfolio finishes cleanly.

From a check to continuous monitoring

The tools read DNS the moment you ask. The verdict that actually catches a problem, though, is the one that arrives after a spoofing run starts — which is what monitoring is for. PlainDMARC turns the incoming aggregate reports into a weekly plain-English verdict per domain, with daily alerts. If your agent has email access it can even set that up over the API.