Email & Domain Auth Checker — MX, SPF, DKIM & DMARC from DNS alone

Check an email or domain's deliverability signals and email-authentication posture — MX, SPF, DKIM, DMARC, disposable/role flags — using only public DNS records. No SMTP connection, no mailbox ping. This tells you whether a domain is set up correctly to receive and authenticate mail; it does not confirm a specific mailbox exists.

$5 per 1,000 checks flat — with a low per-run start fee and nothing else.

Use with AI agents (MCP)

This Actor is also an MCP tool — AI agents like Claude and Cursor can run it for you. Your agent can call this tool directly; usage bills through your Apify account.

MCP server URL:

https://mcp.apify.com?tools=apifmcpfactory/email-domain-checker

Claude Desktop (claude_desktop_config.json):

{
    "mcpServers": {
        "email-domain-checker": {
            "command": "npx",
            "args": [
                "mcp-remote",
                "https://mcp.apify.com?tools=apifmcpfactory/email-domain-checker",
                "--header",
                "Authorization: Bearer YOUR_APIFY_TOKEN"
            ]
        }
    }
}

Cursor (.cursor/mcp.json):

{
    "mcpServers": {
        "email-domain-checker": {
            "url": "https://mcp.apify.com?tools=apifmcpfactory/email-domain-checker",
            "headers": {
                "Authorization": "Bearer YOUR_APIFY_TOKEN"
            }
        }
    }
}

Replace YOUR_APIFY_TOKEN with your API token from Apify Console. This same checker is also published standalone on MCPize as a free community MCP server.

Why this Actor?

• DNS-only, honestly — MX, SPF, DKIM and DMARC are all public DNS records. Reading them needs no SMTP handshake, no "ping the mailbox" trick that gets you greylisted or rate-limited by mail providers, and no false confidence from a technique (SMTP verification) mail servers increasingly detect and block.
• Distinguishes "doesn't exist" from "can't receive mail" from "couldn't tell" — a domain that doesn't resolve at all (UNRESOLVABLE), a domain that resolves but publishes no MX (NO_MX — including an explicit RFC 7505 "null MX" record), and a genuine DNS failure (LOOKUP_ERROR) are three different things. Most checkers collapse them into one generic failure.
• Disposable and role-address flags — checked against bundled open lists, useful for cleaning a signup or lead list before it hits your CRM.
• Honest about DKIM — DKIM keys live at a selector-specific DNS name with no directory to look one up. Without a selector, this probes a handful of common ones and reports exactly which it checked — never claiming "no DKIM" when it simply didn't guess the right selector.
• Bulk-safe by design — up to 1,000 inputs per run, one dataset row per input, in order. A single bad entry never fails the batch.

Input

{
    "inputs": ["user@google.com", "mailinator.com", "not-a-real-domain-xyz.example"],
    "dkimSelector": "google"
}

dkimSelector is optional — omit it to probe the common default set (google, default, selector1, selector2, k1, dkim, mail).

Output

One dataset item per input, in the same order as given:

{
    "input": "user@google.com",
    "domain": "google.com",
    "status": "OK",
    "syntaxValid": true,
    "hasMX": true,
    "mxHosts": ["smtp.google.com"],
    "disposable": false,
    "roleAddress": false,
    "spf": { "present": true, "record": "v=spf1 include:_spf.google.com ~all", "policy": "~all" },
    "dmarc": { "present": true, "record": "v=DMARC1; p=reject; ...", "policy": "reject" },
    "dkim": { "selectorsChecked": ["google"], "found": ["google"] },
    "summary": "google.com accepts mail (1 MX host(s)). SPF present (~all). DMARC present (p=reject). DKIM found for 1/1 checked selector(s)."
}

You can download the dataset in various formats such as JSON, HTML, CSV, or Excel.

Is this email valid or deliverable?

This checks whether the domain is correctly configured to receive and authenticate mail: it resolves, has MX records, and (ideally) publishes SPF/DKIM/DMARC. It does not connect to the mail server or check whether a specific mailbox exists — that requires an SMTP handshake, which real-world mail providers throttle, block, or answer dishonestly (accept-all servers, greylisting) often enough that the result is less trustworthy than DNS-based signals, not more.

Does it check SPF, DKIM, and DMARC?

Yes, all three, for every input that resolves and has (or explicitly refuses) mail:

• SPF — the domain's own TXT record starting v=spf1; reports the "all" mechanism's qualifier (-all/~all/?all/+all) as a simple policy summary.
• DMARC — the TXT record at _dmarc.<domain> starting v=DMARC1; reports the p= policy (none/quarantine/reject).
• DKIM — selector-specific; provide dkimSelector if you know it, or a common-selector probe runs automatically.

Does it detect disposable email addresses?

Yes — every domain is checked against a bundled snapshot of well-known public disposable/temporary-email domains (Mailinator, Guerrilla Mail, Yopmail, and similar). New disposable services appear constantly, so disposable: false means "not on this known list," not a guarantee.

GDPR & lawful use

Every check reads only public DNS records — nothing is stored beyond your own run's dataset, no third-party enrichment, no mailbox contact of any kind.

More tools from MCP Factory

• IBAN Validator — offline ISO 13616 IBAN checksum and structure validation.
• EU VAT Validator — validate EU VAT numbers against the official VIES registry.
• Sanctions Screening — screen names against official OFAC, EU, UK and UN sanctions lists in bulk.