Email authentication failures rarely come from one missing DNS record. A domain may publish SPF but authorize an obsolete sender, use DKIM with a selector your checker never tested, or have DMARC set to monitoring mode without a safe path to enforcement. Transport controls such as MTA-STS and TLS-RPT add another layer that basic lookup tools often ignore.
This guide builds a practical SPF, DKIM and DMARC checker API workflow in Node.js. It audits seven public controls—MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI—then turns the evidence into a score and a prioritized repair plan.
You will also learn where a DNS-based audit stops. The result is useful for onboarding, monitoring and technical triage, but it is not a promise that a message will reach the inbox.
The fast path: If you need the result rather than the implementation theory, run a domain through the Domain Mail Security & Deliverability Audit API. The Basic plan includes 50 requests per month.
Why an API-based email security check matters
SPF, DKIM and DMARC answer different questions. Treating them as interchangeable produces misleading reports:
| Control | Question it answers | Public evidence inspected | Audit weight |
|---|---|---|---|
| MX | Can other mail systems find this domain’s receiving servers? | MX records | 20 |
| SPF | Which hosts may use the domain in an SMTP MAIL FROM or HELO identity? |
Root-domain TXT record | 20 |
| DKIM | Is a public key available for a known signing selector? | selector._domainkey TXT or CNAME |
15 |
| DMARC | What happens when aligned SPF and DKIM authentication fail? | _dmarc TXT record |
25 |
| MTA-STS | Does the domain publish an HTTPS policy for secure SMTP transport? | _mta-sts TXT plus the policy file |
10 |
| TLS-RPT | Where should TLS delivery failures be reported? | _smtp._tls TXT record |
5 |
| BIMI | Does the domain advertise a brand-indicator logo? | default._bimi TXT record |
5 |
The distinctions are grounded in the underlying standards. SPF authorizes hosts for SMTP identities. DKIM associates a cryptographic signature with a signing domain. DMARC adds identifier alignment, policy and reporting around authenticated mail.
That distinction is operationally important. A message may pass SPF for a bounce domain while failing DMARC alignment with the address visible in From:. A domain may also sign mail with DKIM while a generic DNS scanner reports “not found” because it guessed the wrong selector.
Major mailbox providers have made these controls commercially relevant. Google’s current email sender guidelines require authentication and additional practices for senders to personal Gmail accounts, with stricter requirements for bulk senders. Yahoo publishes corresponding sender best practices. Even for lower-volume senders, a repeatable audit reduces preventable configuration failures.
Checker API versus inbox-placement test
Choose the right tool for the question you are trying to answer.
| Question | DNS and HTTPS audit | Test email / inbox-placement tool |
|---|---|---|
| Is an SPF policy published? | Yes | Sometimes |
Is DMARC set to none, quarantine or reject? |
Yes | Sometimes |
| Is a specified DKIM selector resolvable? | Yes | Yes, from the received message |
| Is MTA-STS published and reachable? | Yes | Rarely |
| Did this exact message align? | No | Yes |
| What reputation does the sender currently have? | No | Partly |
| Did the message reach Gmail or Outlook’s inbox? | No | Yes |
Use the audit for configuration evidence, change monitoring and workflow automation. Use real message headers, provider telemetry and controlled delivery tests when you need per-message authentication or inbox-placement evidence.
Make your first audit request from Node.js
The API supports both a query-string GET and a JSON POST. A POST is easier when you already know one or more DKIM selectors.
const response = await fetch(
`https://${process.env.RAPIDAPI_HOST}/api/v1/mail-security/audit`,
{
method: "POST",
headers: {
"content-type": "application/json",
"x-rapidapi-key": process.env.RAPIDAPI_KEY,
"x-rapidapi-host": process.env.RAPIDAPI_HOST,
},
body: JSON.stringify({
domain: "example.com",
dkim_selectors: ["google", "selector1"],
}),
},
);
if (!response.ok) {
const errorBody = await response.text();
throw new Error(`Mail-security audit failed (${response.status}): ${errorBody}`);
}
const audit = await response.json();
console.log({
domain: audit.domain,
score: audit.score,
summary: audit.summary,
findings: audit.findings,
});Copy the exact host from the RapidAPI marketplace code snippet. Keep the key in an environment variable or secret manager—never commit it to a repository or expose it in browser-side JavaScript.
RAPIDAPI_HOST=copy-the-host-from-your-rapidapi-code-snippet
RAPIDAPI_KEY=your-key-from-rapidapiFor a simple query-string request, encode the values instead of concatenating unchecked input:
const params = new URLSearchParams({
domain: "example.com",
dkim_selectors: "google,selector1",
});
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,
},
},
);Understand the response before automating it
A useful checker should return both a normalized decision and the evidence behind it. The following shortened example shows the response shape; record values are illustrative.
{
"success": true,
"request_id": "7eea3f51-7d70-4f2f-a88e-8dd58a4d4bde",
"domain": "example.com",
"audited_at": "2026-09-18T08:35:21.000Z",
"duration_ms": 412,
"score": {
"value": 72,
"grade": "C",
"maximum": 100,
"provisional": true,
"possible_with_unverified_dkim": 87
},
"summary": {
"passed": 3,
"warnings": 2,
"failed": 2,
"errors": 0,
"top_recommendation": "Review DMARC reports, then progress to quarantine or reject."
},
"checks": {
"spf": {
"status": "pass",
"points": 20,
"details": {
"record": "v=spf1 include:_spf.example.net -all"
}
},
"dmarc": {
"status": "warn",
"points": 10,
"details": {
"policy": "none",
"percentage": 100
}
},
"dkim": {
"status": "unknown",
"points": 0,
"details": {
"checked_selectors": ["google", "selector1"]
}
}
},
"findings": [
{
"code": "DMARC_MONITOR_ONLY",
"severity": "high",
"title": "DMARC is monitoring only",
"recommendation": "Review reports, then progress to quarantine or reject."
}
]
}Three fields deserve special treatment in your application:
request_idhelps trace a specific failure when you contact support or inspect logs.score.provisionaltells you that unknown DKIM selectors limit the conclusion.findings[].codeis safer for automation than matching human-readable text.
Use the score for sorting and trends, not as a binary security verdict. A domain with an incomplete but safe configuration can score below a domain whose records exist but are operationally wrong in ways a public audit cannot observe.
Why DKIM must return “unknown” sometimes
SPF lives at the domain root and DMARC at _dmarc.example.com. DKIM has no universal lookup name. It uses a selector chosen by the sender:
selector._domainkey.example.comThe selector appears in a real message’s DKIM-Signature header as the s= value. The signing domain appears as d=. DNS does not offer an index of every selector, so trying a list of common names can never prove that DKIM is absent.
For example, if a message contains:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; ...test google._domainkey.example.com. If no tested selector resolves, label the result unknown and ask for a selector from a recent message. Reporting a hard failure would overstate the evidence.
This is also why DKIM makes the score provisional. Once a known active selector is supplied, the same audit can confirm whether a public key or CNAME target is available.
Turn the findings into a safe repair plan
Do not apply every recommendation at once. Authentication changes can block legitimate senders if they are tightened in the wrong order.
1. Confirm mail routing and inventory every sender
Verify MX first if the domain should receive mail. Then list every platform that sends as the domain: Google Workspace or Microsoft 365, CRM, support desk, billing system, marketing platform, transactional provider and any legacy sender.
2. Consolidate and validate SPF
Publish one SPF policy. Multiple SPF records cause a permanent evaluation error. Remove obsolete sources and inspect recursive include, a, mx, exists and redirect terms: RFC 7208 limits terms that cause DNS queries during evaluation.
A checker can count direct lookup-producing terms, but recursive includes may add more. Treat “near the limit” as a review trigger, not proof that the complete policy is safe.
3. Verify DKIM for every sending system
Collect a recent received message from each provider and record its d= and s= values. Test the matching selector, confirm that the public key is active, and recheck after provider migrations or key rotation.
4. Roll out DMARC with evidence
Start with aggregate reporting if the domain has never used DMARC. Identify legitimate sources, fix alignment and advance carefully from p=none toward quarantine or reject. Google’s recommended DMARC rollout likewise emphasizes monitoring reports and gradual enforcement.
Do not assume that record existence equals protection. p=none asks receivers to report but not quarantine or reject mail solely because of DMARC failure. A partial pct value also limits how widely the requested policy applies.
5. Add transport policy and reporting
MTA-STS combines a DNS marker with a policy served from a standard HTTPS URL. The audit must verify both pieces. A TXT record alone is not enough if the policy is unavailable, has the wrong content type or contains invalid fields.
TLS-RPT gives domains aggregate reports about failures to establish secure SMTP transport. Deploy it with MTA-STS so enforcement work has operational visibility.
6. Consider BIMI after authentication is stable
BIMI is a brand-display layer, not a substitute for SPF, DKIM or DMARC. The BIMI implementation guide describes the logo and verification process. Provider support and certificate requirements vary, so treat BIMI as an optional final step.
Test cases worth automating
Before connecting the API to onboarding or alerts, test predictable cases:
| Test | Input | Expected application behavior |
|---|---|---|
| Valid public domain | example.com |
Store the score, evidence and request ID |
| URL passed as input | https://example.com/path |
Normalize to the public hostname |
| Known DKIM selector | Domain plus selector from a message | Treat a found active key as confirmed evidence |
| Unknown selectors | Common guesses only | Preserve unknown; do not convert it to fail |
| Monitoring DMARC | p=none |
Warn and recommend staged enforcement |
| Multiple SPF records | Two v=spf1 TXT values |
Raise a critical configuration finding |
| DNS timeout | Resolver error | Mark the check as an error, not “record missing” |
| Private or invalid host | localhost or malformed input |
Reject the request with a client error |
The error distinction matters for monitoring. A transient resolver failure should normally be retried; a confirmed missing record should create a configuration task.
function shouldOpenIncident(audit) {
if (!audit.success) return false;
return audit.findings.some(({ severity }) =>
severity === "critical" || severity === "high"
);
}
function shouldRetry(audit) {
return audit.summary.errors > 0;
}For scheduled checks, store the previous statuses and alert only on meaningful changes. Repeating the same warning every hour trains teams to ignore it.
Accuracy, privacy, latency and cost
These are the questions to answer before adopting any email security API.
How accurate is the result?
The response is a point-in-time view of public DNS and the standard MTA-STS HTTPS policy endpoint. DNS caching, propagation and temporary resolver failures can change what is visible. DKIM is conclusive only when you provide selectors actually used by the domain. The API keeps missing records separate from lookup errors and exposes evidence so a human can verify important decisions.
What data leaves my system?
The request contains the public domain and any DKIM selector names you choose to submit. The audit does not need an email body, recipient list, mailbox password or private provider configuration. It queries public DNS and the domain’s public MTA-STS policy URL. As with any third-party API, do not send secrets in the domain or selector fields.
How should I handle latency?
An audit fans out across several DNS lookups and may fetch one HTTPS policy. That is more work than a single-record checker. Use it in server-side workflows, display a loading state in interactive tools, and record duration_ms. Add your own request timeout and retry only transient failures; do not blindly retry invalid input.
What coverage is included?
The response covers MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI. It does not send email, connect to recipient inboxes, calculate sender reputation, inspect complaint rates or guarantee delivery. It also does not claim to discover every DKIM selector or fully expand every possible recursive SPF path.
What does it cost to evaluate?
The RapidAPI Basic plan includes 50 requests per month, enough to validate the response format, test a small onboarding flow or monitor a limited set of domains. Review the current marketplace pricing before moving production volume, since plan details can change.
How do I get support for a failed request?
Keep the request_id, HTTP status, endpoint and a redacted request example. Use the provider support channel on RapidAPI; never post your RapidAPI key in a public message.
Where this API fits in a product
The same structured response can power several workflows:
- SaaS onboarding: block or warn when a customer connects an incomplete sending domain.
- Agency audits: create a repeatable technical baseline before recommending changes.
- Managed-service monitoring: detect disappearing records or weaker policies.
- Vendor screening: add public mail-security evidence to a domain review.
- Support triage: attach finding codes, evidence and recommended fixes to tickets.
- Portfolio reporting: compare posture across brands without manually copying DNS records.
For a broader domain review, combine this audit with the Domain Intelligence & Website Trust Score API for RDAP, TLS, HTTPS and security-header evidence. The Website Technology Stack Detector API adds public CMS, framework, commerce, analytics, hosting and CDN signals.
SPF, DKIM and DMARC checker FAQ
What does an SPF, DKIM and DMARC checker test?
It inspects the public records used for sender authorization, message signing and authentication policy. A deeper audit can also check MX, MTA-STS, TLS-RPT and BIMI, return the underlying evidence and prioritize fixes.
Can a checker find every DKIM key automatically?
No. DKIM requires a selector, and DNS does not publish a complete list of selectors. Use the s= value from a recent message’s DKIM-Signature header for a conclusive lookup.
Does passing SPF, DKIM and DMARC guarantee deliverability?
No. Authentication supports trustworthy handling, but inbox placement also depends on reputation, complaints, bounces, sending patterns, content, engagement and per-message alignment.
Is a DMARC policy of p=none enough?
It is useful during discovery because it enables reporting, but it does not ask receivers to quarantine or reject mail solely for failing DMARC. Use the reports to identify legitimate senders, fix alignment and plan gradual enforcement.
Can I run the audit during customer onboarding?
Yes. Run it server-side after a customer submits a domain, preserve the evidence and show precise actions rather than only a score. Treat lookup errors as retryable and unknown DKIM as a request for the correct selector.
Run your first complete audit
The Domain Mail Security & Deliverability Audit API checks all seven controls in one request and returns evidence, normalized findings and prioritized recommendations.
Start with the 50 monthly requests in the Basic plan. Test one healthy domain, one intentionally incomplete domain and one domain with a selector taken from a real message. That three-case evaluation will tell you far more than checking whether a score looks impressive.