Most email MCP servers do not test email. Of the 107 email related servers in the official Model Context Protocol registry on September 21, 2026, three put a message in front of a real spam filter and report where it landed. Thirty seven give an AI agent a mailbox so it can collect a signup code. Twenty six send mail, twenty five verify addresses, and sixteen read DNS records.
That gap matters because the two jobs get filed under one label. "Email MCP server" is used for a connector that sends transactional mail and for a connector that tells you whether your last campaign reached the inbox, and a team that installs the first while shopping for the second gets an assistant that can send confidently and cannot check anything.
This guide sorts the field by what each server actually does, names the deliverability vendors that publish one, and gives you a three part test for telling a vendor's own server from a lookalike that borrowed its name.
An email testing MCP server checks a message, a sending server dispatches one
An email testing MCP server exposes checks to an AI assistant; a sending MCP server exposes delivery. The difference is the direction the message travels. A sending server takes content from the assistant and hands it to an SMTP pipeline. A testing server takes content from you and reports what happened to it: the spam score it earned, the authentication it passed, the clients it rendered in, the folder each mailbox provider filed it under.
Both are useful and neither substitutes for the other. Our companion guide to picking the best email MCP server covers the platform and sending side, from Klaviyo and Brevo to Resend. This one covers the checking side.
The five jobs below are what the registry actually contains, counted on September 21, 2026. The counts come from seventeen single word searches against the registry API, deduplicated by server name, with twenty three non email results removed.
| What the server does | Servers | Typical example |
|---|---|---|
| Gives an agent its own mailbox | 37 | Disposable inboxes that catch a verification code |
| Sends mail, or other | 26 | SMTP relays, campaign and template tools |
| Verifies addresses | 25 | Syntax, MX and disposable domain checks on a list |
| Reads authentication and DNS | 16 | SPF, DKIM, DMARC, MTA-STS and BIMI readers |
| Tests a message against a real filter | 3 | Placement tests and client renders |
The ratio is the finding: 3 of 107. Every other row is a server that does something useful with email without ever telling you where a message ended up.
One detail about the registry is worth knowing before you count anything yourself. It returns one row per published version, not one per server, so a result count overstates the field badly. A search for spam returns eleven rows that are three servers. A search for dkim returns nine rows that are two. A search for mail returns a hundred rows that are thirty one. Every number above is a distinct server name.
Three servers in the registry put a message in front of a real filter
Three servers out of 107 send or render a message somewhere a filter can judge it, and all three are small and recent. Their registry descriptions are submitted by their own publishers, so treat the capability lists as claims rather than findings.
ai.powerline/inbox-preview renders HTML or .eml files in real Gmail, Outlook and Yahoo web clients and screenshots the result. It is a remote server published in July 2026 at version 0.1.0.
io.github.live-direct-marketing/inbox-check advertises inbox placement tests across Gmail, Outlook, Yahoo, Mail.ru and Yandex alongside an authentication reading. It ships as an npm package, ldm-inbox-check-mcp, at version 0.1.2.
io.github.serg-tanichev/email-spam-tester offers a disposable address and 41 checks with RFC citations, published in September 2026 at version 1.0.0.
Three things are absent from the registry entirely. A search for blacklist returns nothing, a search for blocklist returns nothing, and a search for spamassassin returns nothing. Those are single word searches, which is the only kind the registry answers: every multiword query we tried, including inbox placement and seed list, returned zero results regardless of what is published. Read the three single word zeros as real and ignore any zero from a phrase.
Five of fifteen deliverability vendors publish an MCP server
Five deliverability vendors publish their own MCP server, one runs a pilot, and nine publish none. We checked all fifteen vendors in our comparison set on their own domains in September 2026, and the table below is the result.
| Vendor | Own MCP server | What it covers |
|---|---|---|
| Mailtrap | Yes | Sending, sandbox inspection, logs, contacts, account admin |
| Mailgun | Yes | Sending and analytics retrieval |
| ZeroBounce | Yes | Email validation |
| Litmus | Yes | Validity Engage connector, one client only |
| Everest | Yes | The same Validity Engage connector |
| Folderly | Pilot | Campaign briefs, drafts and review, access by arrangement |
| EasyDMARC | No | A third party publishes one against their API |
| Email on Acid | No | A community server exists, not theirs |
| GlockApps | No | Nothing published |
| Kickbox | No | Nothing published |
| mail-tester | No | Nothing published |
| MailReach | No | Nothing published |
| MXToolbox | No | Nothing published |
| Warmy | No | One comparison article, no product |
| MailGenius | Unverified | Site sits behind a bot verification wall |
Two of those rows deserve their qualifier. The Litmus and Everest entries are one connector, not two: Validity publishes a single Engage MCP connector, its privacy addendum took effect on September 1, 2026, and the addendum names Litmus as the OAuth authorization server while mapping the account to Everest and Certification records. The EasyDMARC and Email on Acid rows say no because the servers that exist for them were built by other people. A third party wrapping a vendor's public API is a fact about the third party.
PowerDMARC sits outside our comparison set and publishes one, com.powerdmarc/mcp, registered in June 2026 with an endpoint that answers an unauthenticated request with a 401. Its own integration page is gated behind a bot check, so the registry entry is the first party evidence.
The Unspam first party test tells a vendor's server from a lookalike
The Unspam first party test: a server counts as a vendor's own only when the vendor's own domain publishes it, the endpoint or package resolves to that vendor, and the registry namespace belongs to the same company. Two out of three is a lookalike.
The test exists because we nearly published two false entries in the vendor table, both under a live trademark.
A GitHub organization called litmusautomation publishes litmus-mcp-server, described as the official MCP server for configuring Litmus instances. It is industrial edge computing software for factory equipment, and it mentions email nowhere. The name is a coincidence between two companies. Nothing in the package or its documentation says so, because there is no reason for it to.
The official registry lists com.warmysender/mcp, which reads at a glance like the email warmup vendor Warmy. It is warmysender.com, a cold outreach company with its own lead database, and it is not warmy.io. The namespace is the giveaway, and only if you look it up.
Both would have passed a check that searched for a vendor name and accepted the first plausible result. Neither passes a check that requires the vendor's own domain to publish the thing.
Mailtrap ships 117 tools and exactly one returns a spam score
The Mailtrap MCP server exposes 117 tools, and one of them reads a spam score. get-sandbox-message-spam-score returns the SpamAssassin report for a message captured in a Mailtrap sandbox: the score, the rules that fired, and the full report. Counted from Mailtrap's own README, the rest divide into 56 account and infrastructure tools, 30 contact and campaign tools, 22 sandbox tools, 6 send tools and 3 for logs and statistics.
This is a genuinely capable server and the count is not a criticism. It is a description of the question it answers. A sandbox score tells you what your content looks like to a rules engine, which is the same thing our own SpamAssassin score guide walks through by hand. It does not tell you which folder Gmail chose, because the message never reached Gmail.
That distinction is the whole reason the category of servers that test against a real filter is so thin. Scoring a captured message is cheap and can run anywhere. Delivering to seed mailboxes at real providers and reading back the folder needs mailboxes at those providers, which is infrastructure rather than code.
Content that scores clean still misses the inbox for a third of recipients
A clean spam score does not predict placement, which is why an assistant that can only score is answering a smaller question than the one you asked. Inbox placement is at 63% across the messages in the Unspam 2026 Email Deliverability Benchmark, so better than a third of mail lands somewhere other than the inbox.
Authentication is the part an MCP server can read from DNS, and it is also the part most senders have already half fixed. Among the domains we test, 93% pass SPF and 90% pass DKIM, while 48% publish a DMARC policy. A domain can pass all three and still see its mail filtered on reputation, content or engagement, none of which a DNS lookup can see.
This is what the sixteen authentication servers in the registry are good at and what they cannot cover. Reading a domain's records is a real check and we publish an explainer on what each record does. It is a check of your configuration, not of your mail.
The Unspam MCP server exposes the placement tools the category is missing
The Unspam MCP server covers the third category: spam checks, real inbox placement, client previews, heatmaps, scheduled tests and DMARC reporting, exposed to an assistant as plain language tools. It is documented in full on the Unspam MCP server page.
The spam check set runs start_spam_check, then get_spam_check_result, with get_spam_check_screenshots, get_spam_check_client_previews and get_spam_check_heatmap for the render and attention output. The inbox placement set starts a seed test and reads the per provider folder split back. The autopilot set creates a sender, a schedule and a notification, so the assistant can set up recurring placement tests rather than one off runs. The DMARC set runs from create_dmarc_domain and get_dmarc_dns_instructions through verify_dmarc_domain, list_dmarc_reports, get_dmarc_report and get_dmarc_report_records. get_account_status reads your plan and remaining limits.
Access needs a paid plan, because MCP is gated to API access and free accounts cannot connect. The current rates are on the pricing page.
Prefer OAuth over a static key, and grant the narrowest scope that works
An MCP server connected with OAuth can be revoked from your account; one connected with an API key holds that key's full permissions until you rotate it. The two authentication styles split roughly along the remote and local line, and the split is worth knowing before you paste anything.
Remote servers run on the vendor's infrastructure and generally use OAuth. The Unspam server registers your client with Dynamic Client Registration, runs the Authorization Code grant with PKCE, and scopes consent to mcp. There is nothing to paste and nothing to rotate, and the connection appears under Connected apps in your account where you can revoke it. Its failure modes are explicit: 401 for a missing or invalid token, 403 for the wrong scope, 429 when you are over quota.
Local servers run on your machine and usually take an API key in an environment variable. Mailtrap's needs MAILTRAP_API_TOKEN, and organization level tools need a second, separately scoped token. A key in an environment variable is a key on disk, so scope it to the minimum the assistant needs and treat it as a credential you will have to rotate.
One more check before you connect anything: run the Unspam first party test. An MCP server you install gets whatever access the credential carries, and a lookalike is not a hypothetical.
What to ask an assistant once the server is connected
Ask for the outcome, not the tool call, and let the assistant chain the steps. These four prompts each cover a job the sending and sandbox servers cannot reach.
- "Run a spam check on this HTML and tell me the score and what is dragging it down."
- "Start an inbox placement test across all mailboxes and report the folder split per provider when it settles."
- "Schedule a weekly placement test for our newsletter sender and notify me if anything lands in spam."
- "Pull last week's DMARC report records and tell me which sending sources are failing alignment."
Each of those is a sequence of calls behind one sentence: start a run, poll for completion, read the result, summarize it. That chaining is the actual value of MCP over a raw API, and it only works if the tools behind it can answer the question.
Pick the server that answers your question
The right email MCP server depends on which of the five jobs you are automating. If an agent needs its own mailbox to catch a verification code, one of the 37 mailbox servers is the answer. If you are sending from an assistant, a sending server is. If you want a list cleaned, a verification server is.
If the question is whether your mail reaches people, the field narrows to almost nothing, and that is the gap Unspam fills. Connect the server, then run a spam test and ask your assistant where your email actually landed.
