Use this server to audit one or many domains for email deliverability and DNS health via a single MCP tool.
Check SPF, DKIM, and DMARC records, validity, and DMARC policy.
Retrieve MX records and identify the mail provider.
Check DNS blacklist status and spam trap risk.
Detect catch-all status with an optional SMTP probe (returns unknown on Apify due to blocked port 25).
Get domain age, website presence, risk level, and a 0–100 deliverability score.
Batch audit domains concurrently (up to 10) and skip the 24-hour cache when needed.
Return flat, Clay-ready JSON per domain with audit errors and run date; read-only, sends no email, and does not verify mailboxes.
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: mcp-gtm-tech-stack-signal-scraper
This server gives an AI client one tool:
check_domain_deliverability: audit one domain or a list of domains for SPF, DKIM, DMARC, MX, mail provider, DNS blacklist status, catch-all, domain age, and a 0 to 100 deliverability score. Results are cached for 24 hours per domain. It reads public DNS only, sends no email, and does not verify individual mailboxes.
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 (integer): how many domains from the list are audited at the same time. 1 to 10. Default 5.
skipCache (boolean): ignore the 24 hour result cache and audit again now, for example right after a DNS change. Default false.
attempt_catch_all (boolean): run the SMTP catch-all probe. Off by default; the Apify platform blocks port 25, so it returns unknown there.
One flat row per domain: domain, spf_record, spf_valid, spf_policy, dkim_selectors_found, dkim_present, dmarc_record, dmarc_policy, dmarc_valid, mx_records, has_mx, mail_provider, catch_all, catch_all_status, blacklisted, blacklists_listed, blacklists_checked, blacklist_status, spam_trap_risk, spam_trap_flags, domain_age_days, domain_age_source, has_website, deliverability_score, risk_level, audit_error, and run_date.
Domain Deliverability Checker is pay per event on Apify.
Event | Price | Fires when |
| $0.00005 | Once per run, on start, one event per GB of memory (minimum one). Apify's start event. |
| $0.005 (FREE tier), down to $0.00425 on GOLD and above | Once per row written to the dataset. |
The tool starts the actor run and polls it to a finished status, so a long run is not cut off at 300 seconds. A run that does not succeed comes back as an error with its run ID and status.
For the complete input and output reference, pricing, and run history, see the Domain Deliverability Checker actor on the Apify Store:
https://apify.com/mambalabs/domain-deliverability-checker
The wrapper calls the actor by its immutable ID 0tVgxI7A6o9jMlxmc, so a Store rename never breaks it.
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.
Use when email lands in spam: audits SPF, DKIM, DMARC, MX and returns the DNS records to fix it.
One-call domain audit: MX receiving, SPF/DMARC/DKIM spoofing protection, disposable-address risk.
Complete domain email-auth audit in one call: SPF with RFC 7208 lookup counting, DKIM selector pr...
Check email deliverability for a domain: MX, SPF, DKIM, DMARC, blacklists. Graded, no key.
