DEV Community: Faraz Ahmad

Stop Parsing PNG as JSON: A QR Code API Integration in Node.js

Faraz Ahmad — Fri, 25 Sep 2026 07:09:10 +0000

A QR API can return three very different things from the same endpoint: binary PNG, JSON containing SVG markup, or JSON containing a Base64 PNG data URL. If your client always calls response.json(), the first PNG request will fail. That is the integration bug this tutorial prevents.

I work on StadiaSoft’s QR Code Generator API. It makes static codes; it does not provide dynamic redirects, edit destinations later, or collect scan analytics. The examples below use its RapidAPI gateway, but the response-handling pattern applies to other image APIs too.

The transport contract matters

Requested format	HTTP response	How to read it
`png`	`image/png` bytes	`arrayBuffer()`
`svg`	JSON with SVG string in `data`	`json()`
`base64`	JSON with PNG data URL in `data`	`json()`

Use Node.js 18+ and keep your RapidAPI key server-side. RapidAPI requires both the host and key headers.

const host = "qr-code-generator-api63.p.rapidapi.com";
const key = process.env.RAPIDAPI_KEY;
if (!key) throw new Error("Missing RAPIDAPI_KEY");

async function generateQR(text, format = "png") {
  const response = await fetch(`https://${host}/api/v1/qr/generate`, {
    method: "POST",
    headers: {
      "content-type": "application/json",
      "x-rapidapi-host": host,
      "x-rapidapi-key": key,
    },
    body: JSON.stringify({ text, format, size: 500, margin: 4 }),
  });

  if (!response.ok) {
    throw new Error(`QR API ${response.status}: ${await response.text()}`);
  }
  if (format === "png") {
    if (!response.headers.get("content-type")?.includes("image/png")) {
      throw new Error("Expected image/png");
    }
    return Buffer.from(await response.arrayBuffer());
  }
  const data = await response.json();
  if (!data.success || data.format !== format) {
    throw new Error("Unexpected response shape");
  }
  return data.data;
}

The PNG path returns bytes you can hand to a PDF tool or image storage service. The Base64 path returns a string beginning data:image/png;base64,. SVG returns markup in JSON. Do not treat either string as a URL hosted by the provider.

Bulk requests have two meters

For ticket or label jobs, POST /api/v1/qr/generate/bulk takes 1–50 items and returns Base64 results with per-item success or failure. Inspect every item; HTTP 200 does not mean all 50 were generated.

A successful 10-item batch uses one Requests unit and 10 QRCodes units. The current Basic plan has 50 of each unit per month. This means a 50-code batch can exhaust the code allowance even though it is only one HTTP call. Large responses can also hit a 4 MB safety limit, so chunk jobs thoughtfully. Check the current plans before production volume.

Make the code scannable

The API defaults to a four-module margin for a reason: DENSO WAVE specifies a four-module quiet zone. Preserve it in the final layout. Higher error correction is not a substitute for good contrast and adequate printed size; DENSO WAVE explains the capacity tradeoff. Test the actual print, lighting, camera and destination URL, especially when using branded colors. Never encode secrets into a QR payload.

If all you need is one QR inside a Node process, the open-source node-qrcode library may be simpler than a hosted API. Use a hosted service when its shared interface and managed execution fit your workflow.

The full original guide on StadiaSoft covers output choices, quotas, troubleshooting and print checks in more depth. This DEV edition focuses on the binary-versus-JSON trap. I am affiliated with the API provider; the free Basic allowance is currently 50 requests and 50 generated codes per month.

Build an Explainable Vendor-Risk Gate in Node.js

Faraz Ahmad — Tue, 22 Sep 2026 22:27:32 +0000

A vendor signs up with a company domain. Your application wants one fast answer: approve or reject?

The network cannot give you that answer. It can give you evidence.

In this tutorial, we will call a domain-intelligence API, normalize its response and return one of three application decisions:

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

The implementation uses registration, DNS, TLS, HTTPS and browser-header signals. It deliberately does not call a technically healthy site “safe.”

1. Define the boundary

The API can observe:

RDAP registration age, expiry and status;
public DNS and nameserver configuration;
TLS trust, hostname coverage and expiry;
HTTPS reachability and redirects;
selected HTTP security headers.

It cannot prove:

who controls the domain;
whether the business is legitimate;
whether the site contains malware or phishing content;
how the domain will behave tomorrow.

That boundary belongs in code review, product copy and user-facing explanations.

2. Call the endpoint with a deadline

Store the RapidAPI key in the environment. Copy the exact host from the marketplace snippet.

const API_HOST =
  "domain-intelligence-website-trust-score.p.rapidapi.com";

async function fetchDomainAudit(domain, { forceRefresh = false } = {}) {
  const query = new URLSearchParams({
    domain,
    timeout_ms: "6000",
    force_refresh: String(forceRefresh),
  });

  const response = await fetch("https://" + API_HOST + "/audit?" + query, {
    headers: {
      "x-rapidapi-host": API_HOST,
      "x-rapidapi-key": process.env.RAPIDAPI_KEY,
    },
    signal: AbortSignal.timeout(12_000),
  });

  const body = await response.json();

  if (!response.ok) {
    const error = new Error(
      body?.error?.message ?? "Audit failed with " + response.status,
    );
    error.status = response.status;
    error.requestId = body?.request_id;
    throw error;
  }

  return body;
}

The external timeout is longer than the requested audit timeout so the API can return a structured failure instead of being cut off by the caller first.

3. Normalize only the fields your policy understands

Do not spread the provider response through your whole application. Build an adapter.

function normalizeAudit(raw = {}) {
  const findings = Array.isArray(raw.findings) ? raw.findings : [];

  return {
    domain: raw.domain ?? null,
    score: Number.isFinite(raw.score?.value) ? raw.score.value : null,
    grade: raw.score?.grade ?? null,
    provisional: raw.score?.provisional === true,
    maximumPossible: raw.score?.maximum_possible ?? null,
    topRecommendation: raw.summary?.top_recommendation ?? null,
    severeFindings: findings.filter((finding) =>
      ["critical", "high"].includes(finding.severity),
    ),
    findings: findings.map(({ code, severity, title, recommendation }) => ({
      code,
      severity,
      title,
      recommendation,
    })),
    checks: raw.checks ?? {},
  };
}

Stable finding codes are better policy inputs than human-readable messages, which can change for clarity.

4. Separate evidence from the business decision

function decideVendor(evidence, policy = {}) {
  const allowAt = policy.allowAt ?? 75;
  const blockBelow = policy.blockBelow ?? 40;

  if (evidence.provisional || evidence.score === null) {
    return { decision: "review", reason: "incomplete technical evidence" };
  }

  if (evidence.severeFindings.length > 0) {
    return { decision: "block", reason: evidence.severeFindings[0].code };
  }

  if (evidence.score < blockBelow) {
    return { decision: "block", reason: "score below " + blockBelow };
  }

  if (evidence.score >= allowAt) {
    return {
      decision: "allow",
      reason: "technical posture meets vendor policy",
    };
  }

  return { decision: "review", reason: "mixed technical evidence" };
}

These thresholds are illustrative. A marketplace seller, a payroll vendor and a public-link preview need different policies. Keep the numbers configurable and record the version of the policy used for each decision.

5. Fail into review during outages

A timeout does not make a vendor fraudulent.

export async function assessVendorDomain(domain, policy) {
  const checkedAt = new Date().toISOString();

  try {
    const raw = await fetchDomainAudit(domain);
    const evidence = normalizeAudit(raw);
    const outcome = decideVendor(evidence, policy);

    return { checked: true, checkedAt, ...outcome, evidence };
  } catch (error) {
    return {
      checked: false,
      checkedAt,
      decision: "review",
      reason: "domain evidence temporarily unavailable",
      errorCode: error.status === 429 ? "RATE_LIMITED" : "AUDIT_UNAVAILABLE",
      requestId: error.requestId,
    };
  }
}

For transient failures, retry in a worker with exponential backoff. Do not lock a person out because an RDAP server or certificate endpoint was temporarily slow.

6. Test the policy, not a live score

External evidence changes. Unit tests should use fixtures.

import test from "node:test";
import assert from "node:assert/strict";

test("provisional evidence goes to review", () => {
  const result = decideVendor({
    score: 80,
    provisional: true,
    severeFindings: [],
  });
  assert.equal(result.decision, "review");
});

test("a critical finding blocks even with a high score", () => {
  const result = decideVendor({
    score: 82,
    provisional: false,
    severeFindings: [{ code: "DOMAIN_EXPIRED", severity: "critical" }],
  });
  assert.deepEqual(result, {
    decision: "block",
    reason: "DOMAIN_EXPIRED",
  });
});

test("middle scores require review", () => {
  const result = decideVendor({
    score: 62,
    provisional: false,
    severeFindings: [],
  });
  assert.equal(result.decision, "review");
});

Add integration tests with domains you control, but do not assert that a public domain always returns the same score.

7. Add the evidence your workflow still needs

For real vendor onboarding, combine the technical audit with:

legal-entity and business-registration checks;
proof of domain control;
sanctions or compliance screening where appropriate;
bank-account and payout controls;
malware/phishing intelligence when security risk requires it;
human review and an appeal path.

The domain score helps route work. It should not become a black-box denial system.

Try the workflow

The Domain Intelligence & Website Trust Score API returns the five evidence groups, an explainable score, stable finding codes and remediation. The Basic plan includes 50 requests per month.

For the complete score model, bulk example and implementation boundaries, see the StadiaSoft domain reputation checker guide.

Disclosure: I publish the RapidAPI product referenced here. The tutorial intentionally documents what it cannot prove.

References

Build a Tri-State Email Risk Gate in Node.js

Faraz Ahmad — Sun, 20 Sep 2026 17:44:18 +0000

Most email-validation examples finish with code like this:

if (result.valid) {
  acceptEmail();
}

That is convenient—and usually too lossy.

Syntax, DNS, SMTP and risk checks produce different kinds of evidence. A receiving server may be healthy but refuse to reveal whether a mailbox exists. A catch-all domain may accept any recipient. A role account can be valid but unsuitable for one workflow and perfect for another.

In this tutorial, we will wrap an email validation API in a stable Node.js service that returns three decisions:

allow
review
block

The result is easier to test, safer during outages and more honest about uncertainty.

1. Define an internal contract first

Do not let your application depend directly on every field returned by an external provider. Define the output your product needs.

/**
 * @typedef {Object} EmailAssessment
 * @property {"allow"|"review"|"block"} decision
 * @property {string} reason
 * @property {string} status
 * @property {boolean} checked
 * @property {string} checkedAt
 * @property {object=} evidence
 */

The review state prevents two common bugs:

treating an inconclusive SMTP result as proof that an address is bad;
treating a catch-all domain as proof that a specific mailbox exists.

2. Call the API with a deadline

Node.js provides a global fetch() in current releases. Keep the RapidAPI key in an environment variable and copy the exact host from the marketplace snippet.

const RAPIDAPI_HOST = "email-verify-api1.p.rapidapi.com";

async function requestVerification(email, mode = "power") {
  const response = await fetch(
    `https://${RAPIDAPI_HOST}/api/v1/verify`,
    {
      method: "POST",
      headers: {
        "content-type": "application/json",
        "x-rapidapi-host": RAPIDAPI_HOST,
        "x-rapidapi-key": process.env.RAPIDAPI_KEY,
      },
      body: JSON.stringify({ email, mode }),
      signal: AbortSignal.timeout(mode === "quick" ? 5_000 : 35_000),
    },
  );

  const body = await response.json();

  if (!response.ok) {
    const error = new Error(body.error ?? "Email verification failed");
    error.status = response.status;
    throw error;
  }

  return body.data;
}

RapidAPI expects both authentication headers. The timeout is intentionally longer for a deep check because remote mail servers control part of its latency.

3. Normalize provider evidence

A Power-mode response can expose syntax, MX, SMTP and risk fields. We only select the fields our policy understands.

function normalizeEvidence(raw = {}) {
  return {
    status: String(raw.status ?? "unknown").toLowerCase(),
    score: Number.isFinite(raw.overall_score)
      ? raw.overall_score
      : null,
    safeToSend: raw.is_safe_to_send === true,
    syntaxValid:
      raw.is_valid_syntax === true
        ? true
        : raw.is_valid_syntax === false
          ? false
          : null,
    mxAcceptsMail: raw.mx_accepts_mail === true,
    smtpConnected: raw.can_connect_smtp === true,
    deliverable: raw.is_deliverable === true,
    disposable: raw.is_disposable === true,
    roleAccount: raw.is_role_account === true,
    catchAll: raw.is_catch_all === true,
    inboxFull: raw.has_inbox_full === true,
    disabled: raw.is_disabled === true,
    spamtrap: raw.is_spamtrap === true,
  };
}

Notice that missing Boolean values do not automatically become positive evidence. An absent is_catch_all is different from a confirmed false in some integrations, so tighten this normalization if your application must preserve null explicitly.

4. Apply a policy—not a score threshold

Scores are helpful summaries, but hard-coding score > 70 hides the reason behind a decision. Start with explicit high-risk signals.

function decide(evidence) {
  const blockingStatuses = new Set([
    "invalid",
    "disabled",
    "disposable",
    "spamtrap",
  ]);

  if (
    evidence.syntaxValid === false ||
    evidence.disposable ||
    evidence.disabled ||
    evidence.spamtrap ||
    blockingStatuses.has(evidence.status)
  ) {
    return {
      decision: "block",
      reason: `high-risk result: ${evidence.status}`,
    };
  }

  if (
    evidence.status === "safe" &&
    evidence.safeToSend &&
    !evidence.catchAll
  ) {
    return {
      decision: "allow",
      reason: "positive mailbox and risk signals",
    };
  }

  return {
    decision: "review",
    reason: `inconclusive or contextual result: ${evidence.status}`,
  };
}

Role accounts intentionally fall into context-dependent handling. A SaaS signup may allow them. A consumer rewards program may review them. A support-ticket system should probably expect them.

5. Fail into review during an outage

If the verification service times out, the address does not suddenly become invalid.

export async function assessEmail(email, { mode = "quick" } = {}) {
  const checkedAt = new Date().toISOString();

  try {
    const raw = await requestVerification(email, mode);
    const evidence = normalizeEvidence(raw);

    return {
      checked: true,
      checkedAt,
      status: evidence.status,
      evidence,
      ...decide(evidence),
    };
  } catch (error) {
    return {
      checked: false,
      checkedAt,
      status: "unavailable",
      decision: "review",
      reason: "verification service unavailable",
    };
  }
}

Whether review means “allow signup but require confirmation” or “hold the CRM record” belongs to the calling application.

6. Test policy branches without calling the network

The most valuable tests exercise your decisions, not a provider’s live score.

import test from "node:test";
import assert from "node:assert/strict";

test("safe non-catch-all address is allowed", () => {
  const evidence = normalizeEvidence({
    status: "safe",
    is_safe_to_send: true,
    is_valid_syntax: true,
    is_catch_all: false,
  });

  assert.equal(decide(evidence).decision, "allow");
});

test("unknown address is reviewed, not blocked", () => {
  const evidence = normalizeEvidence({ status: "unknown" });
  assert.equal(decide(evidence).decision, "review");
});

test("disposable address is blocked by this policy", () => {
  const evidence = normalizeEvidence({
    status: "disposable",
    is_disposable: true,
  });

  assert.equal(decide(evidence).decision, "block");
});

Add cases for catch_all, role_account, inbox_full, provider timeouts and malformed input.

Quick versus power mode

Use quick mode for latency-sensitive checks. It can evaluate syntax, disposable status, domain/MX readiness and other fast signals, but it does not prove that an individual inbox exists.

Use power mode when deeper SMTP/mailbox evidence justifies a slower response. Even then, preserve unknown: providers may restrict address probing, defer connections or return insufficient evidence.

For signup, a good pattern is quick verification plus a confirmation email. For CRM cleanup, use deeper verification asynchronously.

Production guardrails

Before shipping, add:

rate limits to prevent address enumeration;
redacted or hashed email logs;
explicit retry rules for 429 and transient 5xx responses;
latency and status-distribution metrics;
short, policy-appropriate cache windows;
suppression-list checks that verification cannot override;
a clear retention policy for personal data.

Remember: reachability is not consent, and verification is not an inbox-placement guarantee.

Try it with controlled addresses

The Email Verification API on RapidAPI exposes quick and power checks plus an asynchronous bulk workflow. The Basic plan includes 50 requests per month.

I also published a longer implementation guide on StadiaSoft covering bulk polling, failure handling and deliverability boundaries.

Test with addresses you control, inspect every field, and change the policy to match your use case before it touches production traffic.

Disclosure: I publish the RapidAPI product referenced in this tutorial. The code and decision model are provider-aware but intentionally preserve the limitations of SMTP verification.

References

Build a Lightweight BuiltWith Alternative with Node.js

Faraz Ahmad — Fri, 18 Sep 2026 06:37:02 +0000

If you already have a list of account domains, you can build useful technographic enrichment without recreating a global website database. The job is smaller: fetch each public site, detect supported fingerprints, preserve the evidence, and write only high-confidence fields into the CRM.

This tutorial builds that workflow in Node.js with the CMS Checker & Website Technology Detector API. It also covers the limitation that matters most: a real-time website lookup is not the same product as a historical technographic database.

Fast path: the Basic plan includes 50 requests per month. Use those requests on known sites before allowing any detection to change a CRM workflow.

When a lightweight BuiltWith alternative is the right fit

A real-time lookup API is a strong fit when you already possess the domains and need fresh public signals for routing, integration discovery, migration prospecting, or account research. A full technographic database is the better tool when the task starts with “find every company using technology X,” or when historical adoption dates matter. A browser extension is better for one-off human research.

That distinction prevents bad expectations. “Alternative” describes an overlapping job, not identical coverage.

What an evidence-backed detector should return

Public sites expose clues in HTML paths, generator tags, script URLs, response headers, cookies, CDNs, and redirects. One signal can mislead, so a useful detector returns more than a technology name.

For every match, preserve:

technology name and category
confidence from 0 to 99
version when a public signal exposes one
official website
one or more evidence objects with the source, matched value, explanation, and per-signal confidence

The current StadiaSoft catalog covers 40 technologies across 19 categories, including CMS platforms, ecommerce, JavaScript frameworks, analytics, hosting, CDNs, marketing automation, and payments.

Make the first request from Node.js

Node.js 21 and later include a stable browser-compatible fetch(). Keep the RapidAPI key on the server.

RAPIDAPI_HOST=copy-the-host-from-your-rapidapi-snippet
RAPIDAPI_KEY=your-rapidapi-application-key

Use GET /detect for the fastest lookup:

const params = new URLSearchParams({
  url: "shopify.com",
  timeout_ms: "8000",
});

const endpoint =
  "https://" +
  process.env.RAPIDAPI_HOST +
  "/api/v1/technology-stack/detect?" +
  params;

const response = await fetch(endpoint, {
  headers: {
    "x-rapidapi-key": process.env.RAPIDAPI_KEY,
    "x-rapidapi-host": process.env.RAPIDAPI_HOST,
  },
});

if (!response.ok) {
  const errorBody = await response.text();
  throw new Error(
    "Technology lookup failed (" + response.status + "): " + errorBody,
  );
}

const result = await response.json();

console.log({
  finalUrl: result.final_url,
  detected: result.summary.technologies_detected,
  categories: result.summary.categories,
  technologies: result.technologies,
});

RapidAPI authentication requires both X-RapidAPI-Key and X-RapidAPI-Host. Never commit the key, put it in a public URL, or paste it into a support request.

Use Evidence → Confidence → Action

A safe enrichment rule has three layers.

1. Evidence

Preserve the public signal that produced the match: a vendor-specific header, generator tag, two independent asset paths, or a platform cookie.

2. Confidence

Choose an automation threshold. A score of 90 or above may be sufficient for routing, while a lower score may require manual review. The correct threshold depends on the cost of a false positive.

3. Action

Connect a confirmed category to one explicit workflow:

Shopify or WooCommerce can route an account to an ecommerce segment.
WordPress can trigger a migration checklist.
HubSpot can add an integration-fit tag.
Stripe or PayPal can enrich a payments field.
Vercel or Netlify can route a site to a modern-hosting sequence.

A public signal does not prove contract value, deployment size, or company-wide use. It proves that the checked page exposed that signal at that time.

Normalize the result for a CRM

Keep the full evidence in a JSON-capable field, then derive a small number of top-level properties for filters.

function normalizeTechnologyResult(result) {
  const observedAt = new Date().toISOString();

  const technologies = result.technologies.map((technology) => ({
    name: technology.name,
    category: technology.category,
    confidence: technology.confidence,
    version: technology.version ?? null,
    evidence_sources: [
      ...new Set(technology.evidence.map((item) => item.source)),
    ],
    observed_at: observedAt,
  }));

  const highConfidence = technologies.filter(
    (technology) => technology.confidence >= 90,
  );

  return {
    tech_lookup_status: "complete",
    tech_checked_at: observedAt,
    tech_final_url: result.final_url,
    tech_categories: [...new Set(highConfidence.map((item) => item.category))],
    tech_names: highConfidence.map((item) => item.name),
    tech_evidence: technologies,
    tech_request_id: result.request_id,
  };
}

This structure remains stable when the detection catalog grows. It also leaves an audit trail for anyone reviewing a routing decision later.

Process a small batch safely

The bulk endpoint accepts one to five domains, and each result succeeds or fails independently. For larger imports, split domains into groups of five, limit concurrency in your worker, and retry only transient fetch failures.

A practical refresh policy is a lookup during account creation followed by weekly or monthly checks for active accounts. Most website stacks do not need minute-by-minute polling.

Accuracy limitations you should document

Technology detection is fingerprinting, not privileged inspection. A tool can be missed when:

production builds remove recognizable markers
a reverse proxy strips headers
scripts load only after user interaction
the homepage does not use a tool present on an inner page
a consent manager blocks analytics
assets are proxied through the site’s own domain
the technology is entirely backend or internal

False positives are possible too. Editorial text, a third-party widget, or a stale script can resemble a platform marker. Require specific evidence and a high confidence score before triggering outreach or a customer-facing recommendation.

SSRF protection is part of the product

A detector fetches caller-supplied URLs, so server-side request forgery is a core risk. This API accepts only HTTP and HTTPS on ports 80 and 443. It rejects IP literals, local hostnames, private networks, and reserved ranges. Every redirect destination is normalized, resolved, and checked again before connection. Fetches stop after five redirects and responses are capped at 2 MB.

If you build your own detector, one hostname regex is not enough. DNS can change between validation and connection, alternate IP forms can bypass naive rules, and a public URL can redirect to an internal service.

A useful 50-request evaluation

Use the free monthly allowance deliberately:

Test ten known CMS sites.
Test ten framework and hosting sites.
Test ten martech-heavy sites.
Test ten low-signal custom sites.
Spend ten requests on repeats, redirects, invalid input, and caching behavior.

Record expected categories before running the test. Review mismatches manually and inspect the evidence instead of judging the detector from one impressive demo.

Run the five-domain test

Open the CMS Checker & Website Technology Detector API on RapidAPI and use the 50 free monthly requests to validate the workflow against domains whose stacks you can independently verify.

The complete comparison table, FAQ, sources, and implementation notes are available in the original StadiaSoft guide.

Sources

Build an SPF, DKIM & DMARC Checker API with Node.js

Faraz Ahmad — Wed, 16 Sep 2026 23:35:02 +0000

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.