DMARC Checker API: Automate SPF, DKIM and DMARC Checks

A DMARC checker API accepts a domain and returns the state of its email authentication DNS records: MX, SPF, DKIM and DMARC. You call it from code, so you can audit hundreds of sending domains, fail a deployment when a record is missing, or alert when a policy changes. It checks DNS, not inbox placement.

What the four records do

BusinessMCP’s guide to SPF, DKIM and DMARC summarises them clearly:

Record	Where it lives	Purpose
MX	DNS at the domain	Where inbound mail is delivered
SPF	TXT record on the domain	Lists mail servers allowed to send for you
DKIM	TXT at selector._domainkey.domain	Public key to verify message signatures
DMARC	TXT at _dmarc.domain	Policy (none, quarantine, reject) and reporting when checks fail

DMARC also requires alignment: the visible From domain must match the domain that SPF or DKIM validated. The formal definition is in RFC 7489.

Why the sender requirements made this routine

Google’s sender guidelines require authentication for all senders, and stricter setup including DMARC for bulk senders. BusinessMCP’s guide cites roughly 5,000 messages a day to Gmail as the bulk threshold and says Yahoo’s requirements are similar. Confirm the current numbers on Google’s page, since providers revise them. The practical result is that a domain with no DMARC record is now a deliverability risk for anyone sending at volume.

Key takeaway: treat “has SPF, DKIM and a DMARC policy” as a gate before a domain sends its first campaign, and automate the gate.

What the API call returns

BusinessMCP’s website checks API exposes the check as GET /api/hub/v1/sites/{domain}/email-auth, or the MCP tool email_auth_check, at $0.01 per call. Per the vendor, it checks MX, SPF, DMARC and DKIM, grades the result with fixes for failures, resolves records server-side and checks common DKIM selectors.

Two behaviours deserve attention. A DNS lookup that does not complete is reported as unknown, not as a failure of the domain, so your code needs a third state. And because only common DKIM selectors are tried, a domain using an unusual selector can look like it has no DKIM when it does. Where you know the selector, verify it separately with a DNS query.

Reading a result sensibly

Use a simple triage order.

1. DMARC missing. Highest priority for any sending domain. Publish p=none with a reporting address to start.
2. SPF problems. Duplicate records or too many lookups cause a permanent error. We explain the limit in SPF records with too many lookups.
3. DKIM missing for a known sender. Enable signing in each sending platform.
4. MX missing. Only matters if the domain should receive mail.
5. Unknown results. Retry later before raising an alert.

A staged rollout the guide recommends

BusinessMCP’s guide lays out a gradual path:

1. Publish SPF with one record per domain, including every sending service.
2. Enable DKIM signing for each sending platform.
3. Publish DMARC with p=none and a rua= reporting address.
4. Review reports for 2 to 4 weeks and fix every legitimate source that fails.
5. Move to p=quarantine, then after another 2 to 4 weeks to p=reject.

An API check fits each step: re-run it after every change to confirm the record published as intended. DNS changes usually take effect within an hour, depending on TTL, per the guide.

Where an API check stops

• Authentication is not reputation. The guide says authentication is necessary but not sufficient; sender reputation, volume and list quality also decide inbox placement.
• A passing record can still misalign. SPF can pass while DMARC fails because of an alignment problem, which a record-presence check may not reveal.
• It does not read DMARC reports. Aggregate reports sent to your rua address are a separate data stream.
• It cannot see third-party senders you forgot. Only report review exposes those.

Fitting it into a workflow

For a handful of domains, the free email deliverability checker is enough. For a portfolio, script the call and keep results over time. See the bulk audit workflow for the loop, and scheduled monitoring for change alerts. At $0.01 per domain, 200 domains cost $2 per run.

Standards and provider rules change. Verify record syntax against the RFCs and sender requirements on the providers’ own pages before you enforce a policy such as reject.

Worked example: triaging three domains

Imagine three domains returned by an audit. The first has SPF and DKIM but no DMARC record. The second has a DMARC record with p=none and no reporting address. The third shows an SPF permanent error.

Domain	Finding	Action	Urgency
A	No DMARC	Publish p=none with a rua= address	High if it sends at volume
B	p=none, no rua	Add a reporting address so you can learn who sends as you	Medium
C	SPF permerror	Remove duplicate record or reduce lookups	High, mail may fail authentication

Domain B illustrates a point the guide makes: p=none satisfies the providers’ DMARC requirement but does nothing to protect the domain until reports tell you what to fix and you move to quarantine or reject. Domain C shows why an SPF problem outranks a missing policy on a domain that actively sends.

Reports are the other half

A record check tells you the configuration exists. DMARC aggregate reports tell you what is actually happening: which servers sent mail claiming to be your domain, and whether it passed. Without reports you cannot safely tighten policy, because you do not know which legitimate senders would be blocked. Plan for a mailbox or a reporting service to receive them, and budget time to read them during the 2 to 4 week review windows in the staged rollout.

Subdomains and the parent policy

DMARC policies can apply to subdomains through the parent record unless a subdomain publishes its own, and the details are defined in RFC 7489. If you send marketing mail from a subdomain, check both the subdomain and the organisational domain. A pass on the parent says nothing certain about a subdomain with its own records. For many-domain portfolios, loop the check over both, as in a bulk domain audit, and see the SPF lookup limit for the most common cause of failure.

Price and scale

At $0.01 per call, a nightly run on 50 sending domains costs 50 cents a night, roughly $15 a month. Most teams will not need that frequency; weekly checks plus an on-demand check after any DNS change cover the realistic risk. The website checks API lists the endpoint alongside the others, and the trust API covers separate jobs such as verifying individual email addresses, which is a different problem from authenticating your sending domain.