Build an SPF, DKIM & DMARC Checker API with Node.js
An SPF, DKIM and DMARC checker needs to do more than report whether three DNS records exist. A domain can publish SPF yet have no DMARC policy, sign mail with DKIM but use an unexpected selector, or have strong authentic
An SPF, DKIM and DMARC checker needs to do more than report whether three DNS records exist. A domain can publish SPF yet have no DMARC policy, sign mail with DKIM but use an unexpected selector, or have strong authentication records while missing transport-security controls.
That makes a useful mail-security audit more than a set of three DNS lookups. It needs to collect evidence, distinguish a confirmed failure from an unknown result, and return fixes in a sensible order.
This guide shows how to build an API-based email security workflow that audits MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI from Node.js. It also explains what the result canβand cannotβtell you about deliverability.
What each mail-security check tells you
| Check | What it answers | Audit weight |
|---|---|---|
| MX | Can other mail systems find this domain's mail exchangers? | 20 |
| SPF | Which servers are authorized to send for the domain? | 20 |
| DMARC | What should receivers do when alignment fails, and where should reports go? | 25 |
| DKIM | Can a receiver verify a message's cryptographic signature? | 15 |
| MTA-STS | Does the domain publish an HTTPS policy requiring secure SMTP transport? | 10 |
| TLS-RPT | Where should TLS delivery failures be reported? | 5 |
| BIMI | Does the domain publish a brand-indicator record? | 5 |
The first four controls are the core of an email-authentication review. The remaining controls improve transport visibility, policy enforcement and brand signaling.
One important distinction: SPF validates an envelope sender, DKIM validates a signed message, and DMARC evaluates alignment between an authenticated identity and the address visible to the recipient. A record merely existing does not guarantee that all legitimate mail passes.
Audit a domain from Node.js
The Domain Mail Security & Deliverability Audit API supports a fast GET request and a JSON POST request. In RapidAPI, copy your exact host value from the marketplace code snippet rather than hard-coding the placeholder below.
const domain = "example.com";
const selectors = ["google", "selector1"];
const params = new URLSearchParams({
domain,
dkim_selectors: selectors.join(","),
});
const response = await fetch(
`https://${process.env.RAPIDAPI_HOST}/api/v1/mail-security/audit?${params}`,
{
headers: {
"x-rapidapi-key": process.env.RAPIDAPI_KEY,
"x-rapidapi-host": process.env.RAPIDAPI_HOST,
},
},
);
if (!response.ok) {
const body = await response.text();
throw new Error(`Mail-security audit failed (${response.status}): ${body}`);
}
const audit = await response.json();
console.log({
domain: audit.domain,
score: audit.score,
summary: audit.summary,
findings: audit.findings,
});
Keep the RapidAPI key in an environment variable or secret manager. Do not commit it to your repository or expose it in browser-side JavaScript.
The API returns the domain, audit timing, score and grade, individual checks, a summary, and prioritized findings. That structure makes the result suitable for dashboards, onboarding rules, scheduled monitoring and remediation tickets.
Why DKIM needs special handling
You can look up SPF at the root domain and DMARC at _dmarc.example.com. DKIM is different. Its DNS name includes a selector:
selector._domainkey.example.com
The selector is chosen by the sending provider or mail administrator. DNS does not publish a universal index of every selector a domain uses, so an auditor cannot reliably discover all of them.
If you know the provider, pass likely selectors with the request. For example, Google Workspace often uses google, while other providers or self-managed systems may use values such as selector1, selector2, or a date-based selector.
When no tested selector resolves, the responsible result is unknown, not fail. The score should also be treated as provisional. A definitive DKIM failure requires evidence from an actual signed message or the selector configured by the sender.
Turn findings into a repair plan
A raw DNS dump is not a remediation plan. Triage the findings in this order:
- Restore mail routing first. Missing or broken MX records can prevent normal delivery.
- Fix SPF syntax and authorization. Keep one SPF record, remove obsolete senders, and stay within SPF's DNS-lookup constraints.
- Publish DMARC and improve it gradually. Start with reporting if necessary, study legitimate sources, then move toward quarantine or reject when alignment is stable.
- Verify DKIM with the correct selectors. Confirm every active sending platform, not just the primary provider.
- Add MTA-STS and TLS-RPT together. The policy can require secure transport; reporting provides visibility into failures.
- Treat BIMI as an optional final layer. It depends on strong email authentication and may involve additional brand or certificate requirements.
This ordering reduces the chance of tightening policy before legitimate senders are accounted for.
Use the score as a signal, not a verdict
A mail-security score is useful for comparing domains, tracking configuration work and routing high-risk results for review. It is not proof that messages will reach the inbox.
Inbox placement also depends on factors that a DNS and HTTPS posture audit cannot observe, including sender reputation, complaint rates, bounce history, content, sending cadence, recipient engagement and per-message alignment.
The audit described here checks public DNS records and the standard MTA-STS HTTPS policy endpoint. It does not connect to mail exchangers, send test messages, inspect private provider settings or recursively expand every possible SPF include. For deliverability decisions, combine configuration evidence with message headers, provider telemetry and controlled sending tests.
Practical ways to use the result
- Agency audits: generate a repeatable technical baseline before recommending email changes.
- SaaS onboarding: warn customers about missing authentication before they connect a sending domain.
- Vendor screening: identify domains with weak or incomplete mail-security posture.
- Scheduled monitoring: detect when records disappear or policies regress.
- Support triage: attach structured evidence and prioritized fixes to a ticket.
For monitoring, save both the normalized finding codes and the underlying evidence. Alert on meaningful state changes, not small score movements alone.
SPF, DKIM and DMARC checker FAQ
What does an SPF, DKIM and DMARC checker test?
It looks up the public DNS records used for sender authorization, message signing and authentication policy. A deeper audit can also check MX routing, MTA-STS, TLS-RPT and BIMI, then return the evidence and recommended fixes.
Can a checker find every DKIM record automatically?
No. A DKIM lookup requires the selector used by the sending system, and DNS does not publish a complete list of selectors. Test known provider selectors or inspect the DKIM-Signature header of a real message.
Does passing SPF, DKIM and DMARC guarantee email deliverability?
No. These controls support authentication, but inbox placement also depends on sender reputation, complaints, bounces, content, volume patterns, engagement and per-message alignment.
Can I automate checks with an API?
Yes. A server-side checker API can run during customer onboarding, domain verification, vendor screening or scheduled monitoring. Store both the normalized status and the underlying evidence so changes can be reviewed.
Start with a free audit
The Domain Mail Security & Deliverability Audit API checks seven controls in one request. The Basic plan includes 50 requests per month, so you can test the complete response before choosing a paid plan.
Run a domain in the RapidAPI playground, inspect the evidence behind each check, and use the findingsβnot just the scoreβto decide what to fix first.
Originally published on StadiaSoft.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.