valid   -> accept
invalid -> reject

The real network is less cooperative.

A verifier can prove that an address is malformed. It can observe that a domain has no usable mail infrastructure. It may receive a strong negative recipient response. But it cannot force every SMTP server to disclose whether a mailbox exists.

That is why unknown is not a weak implementation detail. It is a necessary part of an honest API contract.

SMTP is a delivery protocol, not a mailbox directory

During deep email verification, a service can connect to the destination mail system and observe parts of an SMTP conversation without sending a message. The response may provide evidence about connectivity, recipient acceptance or temporary failure.

However, providers have good reasons to limit what they reveal:

• address enumeration enables spam and phishing;
• rate limits protect infrastructure;
• greylisting intentionally defers unfamiliar clients;
• overloaded servers can time out;
• security gateways may accept recipients before later validation;
• policy can vary by network, sender reputation or time.

RFC 5321 explicitly allows operators to restrict address-verification behavior. A server’s refusal to answer a verification-style query is not evidence that the mailbox is nonexistent.

Three results are the minimum

At the application boundary, model at least three outcomes:

type VerificationDecision = "allow" | "review" | "block";

allow means the currently available evidence satisfies your policy. block means the evidence supports rejection. review preserves uncertainty or contextual risk.

This maps several SMTP and risk states without pretending they are equivalent:

The table is a starting point. It is not universal business logic.

Catch-all is a different kind of uncertainty

A catch-all mail system accepts messages for recipients that may not exist. This configuration is useful for organizations that do not want to lose mail sent to mistyped aliases, but it frustrates mailbox-level verification.

Suppose a server accepts all of these:

sales@example.com
alice@example.com
definitely-not-a-real-person-92831@example.com

The SMTP acceptance signal proves something about the domain’s behavior. It does not prove that alice has a real inbox.

Marking every catch-all result “valid” inflates confidence. Marking every one “invalid” throws away legitimate corporate contacts. Preserve the state and let the use case decide.

unknown should survive normalization

Provider integrations often lose uncertainty in their adapter layer:

// Do not do this.
return Boolean(providerResult.is_deliverable);

If the provider omitted the field, returned null, or reported unknown, the Boolean conversion collapses all of that into false.

Use an explicit normalizer:

function normalizeStatus(result = {}) {
  const status = String(result.status ?? "unknown").toLowerCase();

  if (["safe"].includes(status) && result.is_safe_to_send === true) {
    return "allow";
  }

  if (
    ["invalid", "disabled", "spamtrap"].includes(status) ||
    result.is_valid_syntax === false
  ) {
    return "block";
  }

  return "review";
}

This default is intentionally conservative: unrecognized future statuses also go to review instead of silently becoming allow or block.

Quick validation and deep verification are not interchangeable

Fast verification is valuable in interactive paths. It can evaluate syntax, disposable status, role accounts, MX records and whether a domain appears able to receive mail.

What it cannot do is infer an individual mailbox from domain health alone.

Deep or Power-mode verification adds SMTP and mailbox signals where possible. The receiving server controls part of the latency and observability, so a deep check can take longer and can still be inconclusive.

A practical architecture is:

signup request
  -> local syntax hygiene
  -> quick API check
  -> create account in pending state
  -> send confirmation link
  -> optional deep check asynchronously

For a CRM import, the sequence changes:

import rows
  -> deduplicate
  -> create bulk verification task
  -> poll in background
  -> segment safe / review / block
  -> preserve original evidence

The product decision stays separate from the transport check.

Build retry semantics around uncertainty

An unknown result can be temporary. That does not justify an immediate tight retry loop.

Use bounded exponential backoff:

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

async function retryUnknown(check, maxAttempts = 3) {
  let lastResult;

  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    lastResult = await check();
    if (lastResult.status !== "unknown") return lastResult;

    const delay = Math.min(15_000 * 2 ** attempt, 120_000);
    await sleep(delay);
  }

  return lastResult;
}

In a real service, move this work to a queue. Persist the attempt count and next-run timestamp so a process restart does not reset the loop. Honor API rate limits and do not use retries to probe a server aggressively.

Verification errors are not address errors

The same principle applies to your own integration. If the verification API returns a transient 5xx, your application learned nothing about the mailbox.

Do not write this:

try {
  return await verify(email);
} catch {
  return { valid: false };
}

Return a separate operational state:

try {
  const evidence = await verify(email);
  return { checked: true, evidence, decision: normalizeStatus(evidence) };
} catch {
  return {
    checked: false,
    decision: "review",
    reason: "verification unavailable",
  };
}

Now your monitoring can distinguish “we observed a bad address” from “our dependency failed.”

Measure decisions against later outcomes

The most useful calibration data comes after verification.

Track whether each category later:

• confirms ownership;
• hard-bounces or soft-bounces;
• complains or unsubscribes;
• becomes an active user;
• remains unknown after a bounded retry.

Do this with privacy controls and retention limits. You are not trying to build a permanent address dossier. You are testing whether your policy produces the intended product outcome.

If many legitimate users in review successfully confirm their inboxes, an automatic block would have been costly. If a segment marked safe still hard-bounces at an unusual rate, investigate data age, provider behavior and your sending system before increasing the threshold blindly.

Verification cannot answer questions it was not designed to answer

SMTP evidence does not establish consent. It does not override unsubscribe or suppression data. It does not guarantee inbox placement. It does not replace bounce processing, SPF, DKIM or DMARC.

Those boundaries are not reasons to avoid verification. They are the conditions for using it well.

Try the model with real responses

The Email Verification API on RapidAPI returns syntax, MX, SMTP and risk evidence through quick and power modes, with an asynchronous bulk workflow. The Basic plan includes 50 requests per month.

For the complete request code and bulk-polling example, see the Node.js email validation guide on StadiaSoft.

Test with addresses you control. Preserve the raw evidence. Make unknown visible in logs and metrics. Then let your product—not an accidental Boolean conversion—decide what happens next.

Disclosure: I publish the RapidAPI product referenced above. This article focuses on a protocol limitation that applies across providers and deliberately avoids delivery guarantees.

References

• RFC 5321: Simple Mail Transfer Protocol
• Node.js global API documentation

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

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:

1. Restore mail routing first. Missing or broken MX records can prevent normal delivery.
2. Fix SPF syntax and authorization. Keep one SPF record, remove obsolete senders, and stay within SPF's DNS-lookup constraints.
3. Publish DMARC and improve it gradually. Start with reporting if necessary, study legitimate sources, then move toward quarantine or reject when alignment is stable.
4. Verify DKIM with the correct selectors. Confirm every active sending platform, not just the primary provider.
5. Add MTA-STS and TLS-RPT together. The policy can require secure transport; reporting provides visibility into failures.
6. 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.