Check SPF, DKIM, and DMARC Across Domains in One Call

One API call returns every DNS authentication signal for a sending domain: SPF, DKIM, DMARC, MX, blacklist status, and a 0 to 100 deliverability score, so you stop stitching together separate dig lookups. This recipe wires that call into a standing audit: list the domains you send from, check each one, gate on the score and the DMARC policy, and re-run on a schedule so a broken record or a downgraded policy gets caught before it tanks your inbox placement.

TL;DR

• One /x402/email-deliverability-check call from Strale takes a domain and returns SPF, DKIM, DMARC, MX, blacklist status, and a 0 to 100 score in a single response.
• Build a gate, not a report: fail if SPF or DMARC is missing, warn if the DMARC policy is p=none, and alert if the domain is blacklisted or the score falls below your threshold.
• Loop over your domain list on a schedule. A scheduled agent can drive the loop because Monid ships as an MCP server.
• Cost is a few cents per domain, so a fleet of a dozen sending domains checked daily is a single-digit-dollar habit. Live magnitudes sit at monid.ai/tools.
• A clean DNS setup is necessary but not sufficient for inbox placement. Treat the score as a floor you must clear, not a guarantee.

Why check all three records at once

Each record answers a different question a receiving mail server asks, and a gap in any one of them quietly hurts you.

• SPF lists which servers are allowed to send mail for your domain. Without it, a receiver has no authorized-sender list to check against.
• DKIM cryptographically signs each message, so a receiver can confirm the body was not altered in transit and really came from you.
• DMARC tells receivers what to do when SPF or DKIM fails, and where to send the aggregate failure reports. It is the policy layer that turns the other two into enforcement.

Checking them one at a time with raw DNS queries means writing a parser that counts SPF's lookup limit, guesses DKIM selectors, and reads the DMARC policy string instead of just confirming a record exists. The endpoint below encodes all of that and hands back a verdict. If you only want the raw DNS records for a domain without the scoring, Strale's sibling mx-lookup endpoint returns those directly, but for an audit you want the interpreted result.

Set up the check

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More details in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add --label main --key <your-api-key>

More details in the CLI quickstart.

Monid is a pay-per-call data API marketplace that lets you reach hundreds of external data endpoints from one key and one wallet, paying only when a run succeeds. Discovering and inspecting endpoints are free. Only monid run bills.

Step 1: Inspect the endpoint for free

Before you spend anything, read the schema and the exact price. monid inspect costs nothing.

monid inspect -p api.strale.io -e /x402/email-deliverability-check

This prints the query parameters (domain is the only required one), the shape of the response, and the per-call price so you know the number before a cent moves.

Step 2: Check one domain

Run the check against a single domain to see the full payload. The -w flag waits inline and hands the verdict straight back, which is what an audit loop wants.

# one domain: SPF, DKIM, DMARC, MX, blacklist, and a 0-100 score
monid run -p api.strale.io -e /x402/email-deliverability-check \
  --query '{"domain":"example.com"}' -w

Because the endpoint takes query parameters, you pass --query rather than -i. The response carries each record's presence and validity, the DMARC policy value, the MX records, whether the domain shows on any blacklist, and the netted 0 to 100 score.

Step 3: Turn the response into a gate

A raw score is not an audit. An audit is a decision. Read four signals off the response and branch on them:

1. Missing SPF or DMARC: fail the check. A sending domain without both is unauthenticated and will get filtered.
2. DMARC policy is p=none: warn, do not fail. The record exists and monitors, but it never quarantines or rejects a spoof, so it is a starting line, not enforcement. Push toward p=quarantine or p=reject. The policy levels are documented at DMARC.org.
3. Blacklisted: alert immediately. A listed domain is actively hurting placement right now.
4. Score below your threshold: alert. Pick a floor (say 80) and treat anything under it as a regression to investigate.

Step 4: Loop over your sending domains

Put every domain you send from into a list and run the check across all of them. Here the loop is a shell fragment, but the same shape works inside an agent step.

for domain in monid.ai mail.example.com news.example.com; do
  monid run -p api.strale.io -e /x402/email-deliverability-check \
    --query "{\"domain\":\"$domain\"}" -w
done

Each iteration is one metered call. Feed the results into whatever your team already reads: a Slack message, a row in a sheet, or an alert channel. The point is that one pass covers your whole fleet and flags only the domains that broke a rule.

Step 5: Put it on a schedule

DNS drifts. Someone edits an SPF include, a provider rotates a DKIM selector, or a well-meaning cleanup downgrades a DMARC policy back to p=none. A one-time audit misses all of that. Because Monid ships as an MCP server, a scheduled agent can drive the loop on a cadence and only ping you when a domain crosses a gate. Run the fleet every morning, and a record that broke overnight surfaces before your first campaign of the day goes out.

What it costs

Pricing is per call at a few cents per domain, and it drops to zero when the schedule is idle. Reason about it as magnitude, not sticker:

Every one of those calls prints its price during monid inspect before it runs, and it draws from the same wallet as the rest of your data stack, so a deliverability audit is a line item, not a new vendor. Current per-endpoint magnitudes live at monid.ai/tools.

The honest caveat

A passing DNS setup is necessary for good deliverability, not sufficient. SPF, DKIM, and DMARC being correct means your domain is configured to land, but content, list hygiene, subscriber engagement, and IP reputation also decide the inbox. Read a high score as "the domain cleared the floor," then still warm your sending and keep your list clean. This check also reads public DNS only, so it audits configuration, not the contents of your outbound mail.

FAQ

What does the email deliverability check API return? For one domain, a single call returns SPF, DKIM, DMARC, MX records, blacklist status, and a 0 to 100 deliverability score. That covers presence, validity, the DMARC policy, and the common misconfigurations in one response, so you do not run separate lookups per record.

How do I catch a DMARC policy that got downgraded to p=none? Read the DMARC policy value off the response and warn whenever it equals none. A p=none record passes a presence check but never enforces, so a gate that only confirms "DMARC exists" will miss the downgrade. Branch on the policy string, not just the record's existence. The levels are explained at DMARC.org.

How much does auditing a fleet of domains cost? A few cents per domain per call, shown before it runs by a free monid inspect. A dozen domains checked daily lands in single-digit dollars a month, and nothing accrues when the schedule is idle. Live magnitudes are at monid.ai/tools.

Does a good score guarantee my email reaches the inbox? No. Correct SPF, DKIM, and DMARC are necessary, not sufficient. Content, engagement, list hygiene, and IP reputation also decide placement. Treat the score as a floor you must clear, then handle sending reputation separately.

Grab a key at app.monid.ai, inspect the endpoint for free, and start with a single domain you already trust. Once the verdict matches what you expect, wrap the loop in a schedule and let it watch your whole sending fleet. Start at monid.ai.