Audit a domain's email deliverability and DNS health in a single call. Capabilities include:
SPF, DKIM, DMARC – Verify authentication records and inspect DMARC enforcement policy (none, quarantine, reject)
MX records – Identify mail exchange servers and detect the email provider (e.g., Google, Microsoft)
DNS blacklist status – Determine if a domain appears on any DNS-based blacklists
Catch-all detection – Optionally probe via SMTP whether a domain accepts all email addresses (disabled by default)
Domain age – Retrieve how old a domain is
Deliverability score – A 0–100 composite score summarizing overall email deliverability health
Batch processing – Audit multiple domains concurrently (up to 10 at a time per wave)
Cache bypass – Skip the 24-hour result cache to force a fresh audit
Flat, Clay-ready JSON output – Results returned as flat JSON rows for easy integration
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Domain Deliverability Checker MCP Server Check the email deliverability of stripe.com."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that exposes the Mamba Labs Domain Deliverability Checker as a single tool. Install one package and give your MCP client a way to audit any domain's email deliverability and DNS health, wrapping the Mamba Labs actor on Apify and returning Clay-ready flat JSON.
Related MCP server: mailX tools
This server gives an AI client one tool:
check_domain_deliverability: audit a domain's SPF, DKIM, DMARC, MX, mail provider, DNS blacklist status, catch-all, domain age, and a 0 to 100 deliverability score.
All of the work runs on Apify. This package is a thin client that routes the tool call to the actor and hands back the result.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config:
{
"mcpServers": {
"mamba-domain-deliverability-checker": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-domain-deliverability-checker"],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Get your token at https://console.apify.com/account/integrations, paste it in, and restart Claude Desktop. The tool will be available.
Node.js 18 or newer
An Apify account with an API token
"Check the email deliverability of stripe.com."
"Does github.com have SPF, DKIM, and DMARC set up, and what is its DMARC policy?"
"Audit these domains for deliverability: stripe.com, notion.so, figma.com."
"Is acme.com on any DNS blacklist, and what is its mail provider?"
check_domain_deliverability:
domain (string): bare domain to audit, e.g. stripe.com. Provide this or domains.
domains (array): list of bare domains for batch processing. Takes precedence over domain.
batchSize (number): domains audited concurrently per wave in batch mode. Default 5, maximum 10.
skipCache (boolean): force a fresh audit and ignore the 24 hour result cache.
attempt_catch_all (boolean): run the SMTP catch-all probe. Off by default; the Apify platform blocks port 25, so it returns unknown there.
For the complete input and output reference, pricing, and run history, see the Domain Deliverability Checker actor on the Apify Store (canonical immutable Actor ID URL):
https://apify.com/mambalabs/0tVgxI7A6o9jMlxmc
This server is part of the Mamba Labs GTM Suite, a fleet of twelve specialized MCP servers for go-to-market signal intelligence, each backed by a dedicated Apify actor.
Actor | Immutable Actor ID |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
Built by Mamba Labs | npm | Apify Store
MIT
Built by Mamba Labs. https://apify.com/mambalabs
Audit a domain's email deliverability and DNS health. Returns SPF, DKIM, and DMARC authentication with policy, MX records and mail provider, DNS blacklist status, catch-all detection, domain age, and a 0 to 100 health score as a flat, Clay-ready JSON row. Read-only; requires an APIFY_TOKEN and consumes Apify credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Bare domain to audit, e.g. stripe.com. Provide this or domains. | |
| domains | No | List of bare domains for batch processing. Takes precedence over domain. | |
| batchSize | No | Domains audited concurrently per wave in batch mode. Default 5, maximum 10. | |
| skipCache | No | Force a fresh audit and ignore the 24 hour result cache. | |
| attempt_catch_all | No | Run the SMTP catch-all probe. Off by default; the Apify platform blocks port 25 so it returns unknown there. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by specifying the need for an APIFY_TOKEN, credit consumption, and that it returns a flat JSON row. This provides practical behavioral information beyond annotations. However, it doesn't mention cache behavior or platform limitations for catch-all, which are in parameter descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the purpose, and the second enumerates outputs and requirements. It is front-loaded with the key action, and every sentence provides value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple DNS checks, score, batch processing) and the absence of an output schema, the description comprehensively lists output components and mentions important usage details (token, credits, read-only). It could be improved by noting the cache behavior (skipCache) or the catch-all limitation in the main description, but overall it is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning for parameters beyond what the schema provides. It focuses on output and usage, not on parameter details. No extra guidance is given for the 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Audit a domain's email deliverability and DNS health.' It specifies the verb 'audit' and the resource 'domain's email deliverability and DNS health,' and lists the specific checks it performs. Since there are no sibling tools, differentiation is not required. The description is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for usage by noting it is 'Read-only' and requires an 'APIFY_TOKEN' and consumes 'Apify credits,' implying it is a paid, safe operation. However, it does not explicitly state when to use this tool versus alternatives, or when not to use it. Given no siblings, this is adequate but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0check_domain_deliverabilityScored across 1 tool
With only one tool, there is no possibility of confusion between tools. The single tool has a clear and distinct purpose.
There is only one tool, so naming consistency is inherently perfect. The name 'check_domain_deliverability' is descriptive and follows a clear verb_noun pattern.
The single tool covers a specific domain (email deliverability) comprehensively. While one tool is minimal, the scope is narrow and the tool is well-designed, making the count reasonable.
The tool covers all major aspects of email deliverability: SPF, DKIM, DMARC, MX, blacklists, catch-all, domain age, and health score. No obvious gaps exist for a basic audit.
Check email deliverability for a domain: MX, SPF, DKIM, DMARC, blacklists. Graded, no key.
Scan and fix a domain's email deliverability (SPF, DKIM, DMARC, MTA-STS, BIMI, DNS blocklists).
Check if a domain can be email-spoofed: SPF, DMARC, DKIM, MX graded from public DNS. Authless.
Email-domain intelligence: MX capability, provider, disposable status, SPF, DMARC, and MTA-STS.
