Email Deliverability & Domain Posture Auditor

Bulk email deliverability audit for any domain — MX · SPF · DKIM · DMARC · DNSSEC · MTA-STS · TLS-RPT · BIMI — with a 0–100 posture score and a prioritized fix list per domain.

This email deliverability audit checks the public DNS records that decide whether your mail reaches the inbox or the spam folder. Point it at one domain or a few thousand and every domain comes back as one dataset row: a posture score, a letter grade, the parsed SPF/DMARC/DKIM detail, and the exact DNS change that fixes each problem. It runs on pure DNS-over-HTTPS — no scraping, no proxies, no API keys, no login.

Built for cold-email teams, IT/security teams, email-marketing agencies, and MSPs who need to keep customer domains out of the spam folder — and to prove it.

Remember the Apify platform. Everything here is a standard Apify Actor, so you get the platform for free: scheduling for weekly posture re-checks, the API to drive audits from your own code, run monitoring with alerts on failure, dataset exports (JSON, CSV, Excel), and integrations to push results into Make, n8n, Zapier, Slack or a webhook. This Actor queries public DNS resolvers directly, so no proxy rotation is needed.

What it checks

Area	What we look for	Why it matters
MX	Mail-exchange records present and valid	Without MX, the domain can't receive mail at all
SPF	TXT record at apex, v=spf1, includes, the all= policy, +all hazard, >10 lookups	Receiving servers reject spoofed mail from non-listed IPs
DKIM	Probes 9 common selectors by default (google, default, selector1, selector2, s1, k1, mail, amazon, sendgrid) for public signing keys	Cryptographic email signing — stops tampering and verifies sender
DMARC	_dmarc TXT: policy p= (none/quarantine/reject), sp, pct, rua reporting	The master policy that tells receivers what to do with mail that fails SPF/DKIM
DNSSEC	Authentic-Data flag on queries	Cryptographic chain of trust for DNS — stops cache poisoning
MTA-STS	_mta-sts TXT + policy file at mta-sts.<domain>/.well-known/mta-sts.txt (RFC 8461)	Forces TLS on inbound SMTP — stops STARTTLS downgrade / MITM
TLS-RPT	_smtp._tls TXT (RFC 8460)	Daily reports on STARTTLS failures so you can detect misconfigurations
BIMI	default._bimi TXT	Shows your logo in recipient inboxes (requires DMARC enforcement first)

Each domain gets a 0–100 posture score (A–F grade), a sorted issue list (critical → info) with an exact fix string per issue, and a top_fix summary.

How to run a bulk email deliverability audit

1. Open the Actor and paste your domains into Domains to audit — one per line. Your own domains, your clients' domains, or a prospect list.
2. (Optional) Add any custom DKIM selectors your provider uses (e.g. s1, mandrill, k1). Common selectors are probed automatically.
3. Leave Per-request timeout at the 10-second default unless you're auditing slow or flaky zones.
4. Press Start — or call the Actor from the API/SDK. Every domain is audited sequentially with polite timeouts, so there's no rate-limit risk.
5. Read the results: sort the dataset by posture_score ascending to surface your worst domains first, then work down the issues[].fix strings.
6. Export the dataset as CSV/Excel for a client report, or add a Schedule plus a webhook so a domain that drops below p=reject gets flagged the day it happens.

Why run an email deliverability audit?

Every domain that sends email needs a correct email authentication setup. Without it:

• Cold-email campaigns land in spam. Gmail and Outlook check SPF, DKIM, and DMARC before deciding inbox vs spam folder.
• Your domain can be spoofed. Without DMARC enforcement (p=reject), anyone can send mail that looks like it's from you.
• MTA-STS gaps expose STARTTLS downgrades. A motivated attacker can strip TLS mid-session if MTA-STS isn't published.
• BIMI unlocks branded inbox logos — but only after DMARC p=quarantine or p=reject is enforced.

A single audit pass catches all eight of these surface areas and gives you exact DNS changes to fix each one.

Use cases

• Cold-email / outreach teams — audit your sending domains before a campaign to maximize inbox placement.
• MSPs & agencies — batch-audit your entire customer portfolio; flag every domain missing DMARC or with +all SPF.
• Security / IT teams — detect email spoofing exposure (p=none DMARC, no MTA-STS, no DNSSEC) across your asset list.
• Deliverability consultants — generate a prioritized fix list per domain in one run.
• Compliance — confirm enforcement (p=reject, -all) before audits.

Example input

{
  "domains": ["example.com", "github.com"],
  "dkimSelectors": ["google", "default", "selector1"]
}

Example output (per domain)

One dataset row per domain (issue array trimmed here — the real run emits one object per flagged issue):

{
  "domain": "example.com",
  "status": "ok",
  "queried_at": "2026-09-16T13:03:53.057Z",
  "mx": [{ "priority": 10, "host": "aspmx.l.google.com" }],
  "mx_count": 1,
  "has_mx": true,
  "txt_count": 8,
  "spf": { "found": true, "qualifier": "fail", "all_mech": "-all", "includes": ["_spf.google.com"], "unsafe": false },
  "dmarc": { "found": true, "policy": "none", "pct": 100, "enforced": false, "strong": false },
  "dkim": { "selectors_probed": 9, "keys_found": 0, "keys": [] },
  "dkim_found": false,
  "dnssec": false,
  "mta_sts": "absent",
  "tls_rpt": "absent",
  "bimi": "absent",
  "posture_score": 72,
  "posture_grade": "C",
  "spf_status": "fail",
  "dmarc_policy": "none",
  "issue_count": 3,
  "top_fix": "Move the DMARC policy to p=quarantine then p=reject once SPF and DKIM pass for all legitimate senders.",
  "issues": [
    { "severity": "medium", "area": "DMARC", "message": "DMARC policy is p=none — reports only, no protection against spoofing.", "fix": "Replace p=none with p=quarantine, then p=reject." },
    { "severity": "high", "area": "DKIM", "message": "No DKIM public keys found at common selectors — emails cannot be cryptographically signed/verified.", "fix": "Enable DKIM signing in your email provider and publish the public key at <selector>._domainkey.<domain>." },
    { "severity": "medium", "area": "MTA-STS", "message": "No MTA-STS policy — inbound SMTP connections are vulnerable to downgrade/MITM attacks.", "fix": "Publish a _mta-sts TXT record and a policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt (RFC 8461)." }
  ]
}

Pricing (pay-per-event)

You pay per result, so a cheap audit stays cheap.

Event	Unit	Price (list)
actor-start	per run	$0.01
domain-audited	per domain fully audited (all record sets pulled)	$0.03
issue-flagged	per issue flagged (capped at 8 per domain)	$0.01

Apify applies automatic volume discounts by subscription tier — the domain-audited event drops to $0.027 (BRONZE), $0.024 (SILVER), $0.021 (GOLD), $0.018 (PLATINUM) and $0.015 (DIAMOND). Prices shown are the FREE-tier list prices; live values are always on the Pricing tab.

Worked cost example — auditing a portfolio of 100 domains, average 3 issues each: actor-start ($0.01) + 100 × domain-audited (100 × $0.03 = $3.00) + 300 × issue-flagged (300 × $0.01 = $3.00) = $6.01 for 100 domains (≈ 6¢ per domain).

Compare: a one-off DMARC/SPF scan from a deliverability vendor runs $15–$50 per domain.

Failed lookups are not charged — a domain that can't be resolved returns a structured error row instead of a billable audit.

Integration

• API / SDK — standard Apify actor; call via HTTP API, JavaScript/Python SDK, or Schedule.
• Webhooks — set an actor webhook to POST results to Make/n8n/Zapier on run completion.
• Bulk — pass up to thousands of domains in the domains array; queries run sequentially with polite timeouts.
• Clay / lead-enrichment — outputs are flat JSON, ready for Clay/GSC enrichment tables.

Frequently asked questions

What is an email deliverability audit?

An email deliverability audit checks a domain's DNS records to determine whether its outgoing mail is authenticated and secure. This Actor inspects MX, SPF, DKIM, DMARC, DNSSEC, MTA-STS, TLS-RPT, and BIMI, then scores the domain 0–100 with a prioritized fix list.

How do I check my DMARC record? (DMARC checker)

Run any domain through this Actor. The DMARC check queries _dmarc.<domain> and returns the policy — none, quarantine, or reject — plus the parsed sp, pct, rua, and ruf tags. If no record is found, the fix field tells you exactly which TXT record to publish. There's no separate DMARC checker to pay for; the DMARC check is one of the eight checks in every domain audit.

Can a domain have multiple DMARC records?

No — RFC 7489 allows exactly one DMARC record at _dmarc.<domain>. When receivers find two TXT records that both start with v=DMARC1 they may discard the set entirely, and your policy silently stops applying. This Actor parses the first DMARC record it finds and returns its raw value in the output, so you can inspect it directly — but it does not currently detect duplicates for you, so check the record set manually if you suspect a migration leftover.

What is a good email deliverability score?

Scores 80–100 (A–B grade) indicate strong email authentication with DMARC enforcement, DKIM signing, and MTA-STS enabled. Scores below 60 mean critical gaps exist — typically missing DMARC or an overly permissive SPF +all policy. The output lists the highest-impact fix first.

How do I bulk-check SPF, DKIM and DMARC for hundreds of domains?

Pass an array of up to several thousand domain names in the domains input field. Each domain is audited sequentially with polite timeouts and returns one result object, so a bulk SPF/DKIM/DMARC check over a whole client portfolio is a single run — not one run per domain. Sort by posture_score to rank the worst offenders first.

What does SPF +all mean and how do I fix it?

An SPF record ending in +all (or with no explicit all qualifier) tells receiving servers to accept mail from any IP address — the domain is trivially spoofable. Fix by replacing +all with -all (hard fail) or ~all (soft fail), and ensure every legitimate sending source is listed in the include: statements.

What is MTA-STS and do I need it?

MTA Strict Transport Security (RFC 8461) forces inbound mail servers to use TLS, preventing STARTTLS downgrade attacks. You need it if your domain accepts email and you want to guarantee encrypted delivery. Configure a _mta-sts TXT record and serve a policy file at mta-sts.<domain>/.well-known/mta-sts.txt.

Does this Actor check blacklists, or test live mailbox delivery?

No. This Actor audits published DNS posture, not live SMTP responses and not RBL/blocklist standing. It never opens an SMTP connection and never sends mail. For blocklist checks or mailbox-level probing (bounce detection, SMTP handshake), pair it with a dedicated SMTP-check Actor.

Where do I report a bug or ask for a feature?

Use the Issues tab on this Actor's page — it's public, so your question helps the next user too. Feedback on the fix strings is especially welcome: the score is a heuristic, and the fix list is what actually has to be actionable. Custom solutions for agency-scale workflows are available on request.

Limitations & honest notes

• DKIM is selector-based. DKIM public keys live at <selector>._domainkey.<domain> — there is no "list all DKIM keys" DNS query. We probe 9 selectors by default (google, default, selector1, selector2, s1, k1, mail, amazon, sendgrid), reported as dkim.selectors_probed, plus any custom selectors you pass in dkimSelectors. A domain using a non-standard selector without you supplying it will report dkim_found: false even though it signs mail.
• DNSSEC detection uses the DoH resolver's AD (Authentic Data) flag. Rare split-horizon or private-DNS setups may report differently than a validating resolver on your network.
• MTA-STS requires fetching a policy file over HTTPS from mta-sts.<domain> — a handful of domains do not have this subdomain configured even when they publish a _mta-sts TXT.
• No SMTP handshake / mailbox-probe, no blocklist lookup. This Actor inspects published DNS posture, not live mailbox state.
• The posture score is a heuristic, not a vendor deliverability metric. It weights protocol-level gaps (missing MX/SPF/DMARC enforcement, +all, absent MTA-STS/DNSSEC) — it does not know your sending volume, reputation history or engagement metrics.
• No personal data. All inputs are domain names; outputs are DNS records and posture scores. Incidental emails in SPF/DMARC rua reporting addresses are operator-published infrastructure config, not collected personal data.

Data sources

All DNS records resolved via DNS-over-HTTPS public resolvers (Cloudflare 1.1.1.1, Google Public DNS) using the standard DoH JSON API. MTA-STS policy fetched over HTTPS from the domain's own well-known endpoint. No third-party APIs, no scraping, no API keys.

Related Apify Actors

• SSL/TLS Certificate Expiry Monitor — Check TLS certificate expiry, issuer changes, and SAN drift across your domain portfolio. Complements email posture auditing by verifying the TLS layer your mail servers depend on.
• HTTP Security Headers & OWASP Posture Auditor — Audit your web application's security headers, CSP, and OWASP-recommended protections. Use alongside email posture checks for a full-domain security picture.
• GEO & llms.txt Readiness Auditor — Check your domain's AI crawler access policies and llms.txt, sitemap, and robots.txt configuration for generative-engine optimisation.
• Technical On-Page SEO & Meta Auditor — Audit titles, meta descriptions, headings, canonical tags, and structured data for on-page SEO issues across a list of URLs.