DMARKOFF — DMARC, SPF & DKIM Analytics

DMARKOFF MCP

DMARC analytics inside your AI assistant.

DMARKOFF MCP connects your DMARC monitoring data to AI assistants — Claude, ChatGPT, Cursor, Windsurf — through the Model Context Protocol. Instead of opening a dashboard and building filters, you ask a question and get an answer with real numbers behind it.

Endpoint: https://mcp.dmarkoff.com/mcp Requires: an active DMARKOFF account and an API key from app.dmarkoff.com/account/mcp

What it looks like in practice

*"Which domains dropped in compliance over the last 14 days?"*

The AI checks health across all your projects and surfaces the ones that changed — ranked by how much.

*"Why is SPF failing on example.com? Who's the problem sender?"*

The AI checks return paths, finds the sending source (say, SendGrid using its own bounce domain instead of yours), and tells you what to fix.

*"Anything unusual in email traffic compared to last week?"*

The AI compares the last fully reported day against the 14 days before it — compliance rate, unknown sender volume, message counts. The kind of check most teams skip because setting it up manually takes too long.

*"Can example.com go to p=reject yet?"*

The AI reads DMARKOFF's readiness plan for the domain and gives you its verdict. It names the senders that still need DKIM and where to set it up, the unknown sources you have to confirm are not yours, and the exact record to publish once nothing holds the step. Tell it which senders are yours, and it records that for the plan. Before it takes out a sender the plan counts as your own, it asks you.

Quick connect

Claude.ai

1. Settings → Connectors → Add custom connector
2. URL: https://mcp.dmarkoff.com/mcp
3. Advanced settings:

• OAuth Client ID: claude (any value)
• OAuth Client Secret: your DMARKOFF API key

1. Click Add, then Connect

Works on Free (1 custom connector limit), Pro, Max, Team, and Enterprise.

Claude Desktop

Click + in the chat window → Connectors → Manage Connectors → Add custom connector, paste the URL, complete the OAuth flow.

Or edit the config file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{

"mcpServers": { "dmarkoff": { "command": "npx", "args": [ "mcp-remote", "https://mcp.dmarkoff.com/mcp", "--header", "Authorization: Bearer YOUR_API_KEY" ] } } }

Claude Code

claude mcp add --transport http dmarkoff https://mcp.dmarkoff.com/mcp \

--header "Authorization: Bearer YOUR_API_KEY"

Cursor

Settings → Tools & MCP → Add new MCP server, select Streamable HTTP, enter the URL.

Or edit ~/.cursor/mcp.json:

{

"mcpServers": { "dmarkoff": { "url": "https://mcp.dmarkoff.com/mcp", "headers": { "Authorization": "Bearer YOUR_API_KEY" } } } }

ChatGPT (Business / Enterprise / Edu)

Enable Developer Mode, then go to Settings → Apps → Create App:

• MCP Server URL: https://mcp.dmarkoff.com/mcp
• Authentication: OAuth, without a client ID or secret

ChatGPT registers its own OAuth client with the server, then opens a DMARKOFF page where you paste your API key.

Windsurf

Edit ~/.codeium/windsurf/mcp_config.json:

{

"mcpServers": { "dmarkoff": { "serverUrl": "https://mcp.dmarkoff.com/mcp", "headers": { "Authorization": "Bearer YOUR_API_KEY" } } } }

Note: Windsurf uses serverUrl, not url.

→ [Full connection guide for all clients](docs/connect.md)

Things to ask

Show me an overview of all my DMARC projects

Which domains have Critical severity right now?

Why is SPF failing on example.com? Which senders are the problem?

Are there anomalies in email traffic over the last 24 hours?

Show me source details for example.com grouped by ISP — only rows where SPF is failing

We publish p=reject on example.com — why did some mail still get delivered?

Gmail is throttling us on example.com. What are they actually complaining about?

Our SPF record is at 10 lookups — which includes still carry mail and which can go?

Compliance on example.com dropped last week. Did the DMARC or SPF record change?

Yesterday's Google report for example.com is missing. Is it late, or is something wrong?

Can example.com move to p=reject? What's holding it?

Klaviyo is ours, and the unknown host sending as example.com is not. Record that for the plan.

Live DNS checks — these work for any domain, monitored or not:

Check the SPF record for example.com — are there too many DNS lookups?

What DMARC policy does example.com have right now?

Look up the DKIM key for selector "google" on example.com

Onboarding a new domain — the assistant registers it and hands you the exact TXT record to publish:

Add example.com to my project and tell me what to put in DNS

We already have DMARC on example.com — add our reporting address without touching the rest of the record

I published the record for example.com. Will its reports reach my project?

Tools

Analytics (require API key)

Live DNS (API key, but no monitored project)

Onboarding (requires API key and owner access to the project)

Source decisions (requires API key and owner access to the project, or a shared project whose owner lets you manage sources)

Every tool is read-only (readOnlyHint: true per MCP spec) except two. add_domain creates domains. It never updates or deletes anything, and each non-parked domain it adds consumes a paid domain slot on your plan. set_source_decision saves, changes or clears your decision on one sending source of a domain, or confirms that a source you took out stays out. It cannot add or remove domains, change your DNS or touch report data. Taking out one of the plan's own senders is not saved until you confirm, and each change is logged with the API key as its author. The tool reference lists which sources that check covers.

→ [Full tool reference with parameters](docs/tools.md)

Security

• API key auth — access is scoped to your DMARKOFF account
• OAuth 2.1 (RFC 8414, RFC 9728) — compatible with standard MCP flows used by Claude.ai and ChatGPT
• Project-level isolation — the AI only sees what your API key has access to
• Per-API-key rate limiting — protection against accidental overuse
• Two tools write — add_domain creates domains in a project you own. set_source_decision records your decision on a sending source in a project you own, or one shared with you to manage sources. Its description tells the assistant to use it only at your request, and the server does not take out a source the plan counts among your own senders until you confirm. Every other tool is read-only. No tool deletes domains or report data, and none changes your DNS

How this differs from other DMARC MCP tools

DNS checks tell you SPF is failing. DMARKOFF MCP tells you which specific sender is causing the failure, how many messages it affected over the last two weeks, and what the fix is. That data comes from your aggregate reports — the actual traffic — not just what's published in DNS.

It also answers the questions that come after: whether the problem is new (every domain report carries the previous period beside the current one), what a record looked like before someone edited it, why a receiver ignored the policy you published, and which parts of an oversized SPF record are still earning their DNS lookups.

When you want to tighten the policy, it reads DMARKOFF's own verdict on whether a domain can go to quarantine or reject. That verdict comes from the plan behind the policy recommendation in the DMARKOFF app and the policy-upgrade email, so the assistant and DMARKOFF give you the same answer.

Troubleshooting

Tools don't appear in the client → Confirm your client supports Streamable HTTP (not just SSE). → Some clients need a full restart after config changes.

401 Unauthorized → Check your API key at app.dmarkoff.com/account/mcp.

**"No proj