Giving AI Agents an Email Deliverability Check with MCP

Your agent can draft an email in seconds. It still cannot tell whether the sending domain is configured correctly.

That gap matters. An agent can produce a perfect cold email, newsletter, or support reply, then hand it to a domain with no SPF record, a broken DKIM selector, or a DMARC policy that tells receivers to do nothing. The writing is fine; the infrastructure is not.

I built a small remote MCP server to give agents a read-only email-domain health check. This post shows how it works, how to connect it, and where I deliberately kept the scope narrow.

One tool: scan_domain

The MCP server is available at:

https://mcp.mailers.email/mcp

It exposes a single tool:

{
  "name": "scan_domain",
  "description": "Run a domain email health scan (cheap checks; no blacklist).",
  "inputSchema": {
    "type": "object",
    "properties": {
      "domain": { "type": "string" }
    },
    "required": ["domain"]
  }
}

A call returns checks for:

• MX records
• SPF
• DKIM
• DMARC
• reverse DNS / PTR
• domain age

The response includes a score, maxScore, grade, confidence, individual check details and a fixes array ordered by what to fix first.

The public MCP tool intentionally does not run DNSBL blacklist checks. Those are 32+ extra DNS queries per domain and belong in the full web scan at mailers.email/scan, not in a quick agent tool.

Connect an MCP client

Add the server to your MCP configuration:

{
  "mcpServers": {
    "mailers": {
      "url": "https://mcp.mailers.email/mcp"
    }
  }
}

No API key, account, or OAuth flow is required. The server is anonymous and rate-limited by IP.

After connecting, ask your agent something like:

Check example.com's email setup. Tell me the three most important fixes and why they matter.

A useful agent response should separate:

1. What is broken — for example, no MX record or no SPF record.
2. What it means — can the domain receive mail? Can another server spoof it?
3. What to do first — prioritize authentication and routing before cosmetic improvements.

Why only one tool?

MCP servers can become a pile of endpoints. I kept this one focused because the main agent use case is simple: check a domain before you send from it or recommend it.

One tool also makes the permission model easy to reason about:

• It is read-only.
• It does not touch a mailbox.
• It does not send email.
• It does not require credentials.
• It returns DNS-based evidence, not a guarantee of inbox placement.

DNSBL checks, mailbox access, and sending would each deserve a separate tool with a separate threat model.

Limits and caching

The MCP server shares the same scan budget as the REST API:

• 60 requests per hour per IP
• No API key or account
• MCP calls run a fresh scan
• The REST endpoint caches same-domain results for 24 hours

That difference is intentional. The REST API is optimized for repeated checks and dashboards; the MCP path is optimized for an agent asking once during a task.

If your agent needs the full blacklist report, send it to the web scanner or use the REST API's documented surface. The MCP tool says no blacklist in its description so the agent does not silently assume otherwise.

What the score means

The public API returns maxScore: 80. That is not a bug.

The score is normalized against the checks that actually ran. Because DNSBL checks are excluded from the public API, the maximum available score is 80 rather than 100. A "perfect" cheap scan should not be presented as a perfect full deliverability audit.

This is the kind of detail that matters when an agent is summarizing results for a human. The agent should say what was checked, not just repeat a number.

A small example response

{
  "domain": "example.com",
  "score": 69,
  "maxScore": 80,
  "grade": "C",
  "confidence": 83,
  "checks": ["mx", "spf", "dkim", "dmarc", "age", "rdns"],
  "fixes": ["rdns", "mx"]
}

The real payload includes the record values and reasons behind each status. That is what makes the result useful to an agent: it can explain the finding instead of only returning a grade.

When this is useful

• An agent onboards a new client domain and checks it before sending.
• A developer asks an IDE agent to sanity-check a domain from a README.
• A support assistant flags a customer domain with no SPF or DMARC.
• A sales agent checks a prospect's domain before recommending an email setup.

When it is not enough

This is not a replacement for a full deliverability audit. It does not inspect mailbox placement, content, sending reputation, or live blacklist listings. It is a fast, cheap first pass.

If you need the complete view, use the web scanner:

• Full scan: mailers.email/scan
• API and MCP docs: mailers.email/api/scan
• GitHub README and examples: github.com/xusteve/mailers-scan-api

If you connect it to an agent, I would like to hear what the agent does with the results — especially where it overstates the score or misses a fix-first priority.