Domain Security, Deliverability & Governance Intelligence

DNS, SPF, DMARC, DKIM & email-auth intelligence for a whole domain portfolio — formerly DNS Record Lookup.

Find in one run:

✓ Spoofable domains   ✓ Forgotten SaaS senders   ✓ Silent SPF failures   ✓ Vendor dependencies   ✓ Single points of failure   ✓ What to fix first

---

Find out in 5 seconds

// input
{ "domains": ["example.com"] }

// what you learn
{
  "domain": "example.com",
  "postureGrade": "F",
  "spoofable": true,
  "recommendedAction": "fix-now",
  "topFix": "Enable DMARC enforcement"
}

Most DNS tools tell you what records exist. This actor tells you what is broken, what is risky, what changed, and what to fix first — across one domain or a portfolio of thousands. Deterministic, no LLM, no third-party keys.

---

What nobody realises about their domains

Marketing connected Mailchimp. Sales connected HubSpot. Support connected Zendesk.

Years later, nobody remembers any of it — but the authorisation to send email as your company is still there, sitting in your SPF and DKIM records. This actor finds it.

More broadly, most organisations cannot answer these questions about their own domains:

• Which vendors can send email on our behalf?
• Which SaaS platforms are still authorised that nobody remembers connecting?
• Which of our domains are spoofable right now?
• Which providers are single points of failure?
• What changed in the last 30 days?

This actor answers all five — from records that are already public, that you've simply never correlated.

---

Questions this actor answers

✓ Is this domain spoofable? ✓ What should we fix first? ✓ Which vendors can send email for us? ✓ What SaaS platforms are still connected? ✓ Which domains are operationally risky? ✓ Which 12 of our 500 domains need attention today? ✓ What changed and why does it matter? ✓ Which providers are we dependent on? ✓ Who owns each domain's setup? ✓ Is this acquisition target a mess?

---

Outcomes by team

Team	What they get
Security	Find spoofable domains, detect control regressions, surface shadow SaaS senders.
MSPs	Prioritise remediation across clients, generate executive reports, monitor portfolios on a schedule.
Deliverability	Fix SPF PermErrors, raise DMARC enforcement, discover risky third-party senders.
M&A / due diligence	Assess a target's email-security maturity, vendor sprawl and infrastructure risk before the deal closes.

---

Used for

Domain portfolio audits · MSP client reporting · security assessments · email-deliverability reviews · M&A due diligence · scheduled DNS / email-auth monitoring · vendor discovery · SaaS rationalisation.

---

Why this is different

• Most DNS tools show you records.
• Most DMARC tools show you email authentication.
• Most monitoring tools show you changes.

This actor shows you risk, ownership, dependencies, governance, and what to fix first — the decision layer the others leave to you. In detail, where a DNS tool tells you what records exist, this tells you:

• What is risky — spoofability, takeover exposure, operational fragility.
• What is broken — silent SPF PermErrors, dead MX targets, unenforced DMARC.
• What changed — and whether it's a regression worth paging someone over.
• What to fix first — findings ranked by security recovered per hour of work.
• Who you depend on — every vendor authorised to send, and which are single points of failure.
• Whether it's still needed — the forgotten SaaS senders you can probably remove.
• What would break if it failed — per-domain blast radius for email, web and identity.

---

One example that lands

Point it at a single corporate domain:

{ "domains": ["corp.example"] }

// vendors — who can send email as corp.example
{
  "vendors": [
    { "name": "Microsoft 365", "kind": "mailbox", "sources": ["mx", "spf"] },
    { "name": "Proofpoint",    "kind": "gateway", "sources": ["mx"] },
    { "name": "SendGrid",      "kind": "esp",     "sources": ["spf"] },
    { "name": "Mailchimp",     "kind": "sender",  "sources": ["dkim"] }
  ],
  "thirdPartySenders": ["SendGrid", "Mailchimp"],
  "cleanupCandidates": [
    { "vendor": "Mailchimp", "reason": "A DKIM selector exists but the vendor is not in SPF — may be a stale selector.", "recommendation": "review" }
  ]
}

Nobody remembered Mailchimp was still authorised to send email as the company. The actor found it in the DKIM records — and flagged it for review — in one call.

Now point it at all 143 of an MSP client's domains in one run — the closing summary record is the prioritised work queue:

{
  "executiveSummary": { "domains": 143, "critical": 7, "spoofable": 12, "averagePostureScore": 64 },
  "portfolioRanking": [
    { "priority": 1, "domain": "client-a.com", "spoofable": true, "topRisk": "NO_DMARC" },
    { "priority": 2, "domain": "client-b.net", "spoofable": true, "topRisk": "SPF_LOOKUP_LIMIT_EXCEEDED" }
  ]
}

143 client domains in, a ranked remediation queue out — drop it straight into the monthly client report.

---

What you get from one call

Every domain comes back with the decision fields first — postureScore + grade, spoofable, recommendedAction, topFix — then the supporting intelligence:

• Email authentication — SPF policy + the RFC 7208 10-lookup-limit check (catches the silent PermError that breaks SPF) + include-tree map; DMARC maturity (0–100, monitoring → enforced); DKIM; MTA-STS / TLS-RPT / BIMI.
• DNSSEC — signed / validated / unsigned (via DNS-over-HTTPS).
• DNS resilience & attack surface — redundancy, single-point-of-failure, dangling-CNAME / subdomain-takeover risk, dead-MX targets.
• Vendor & governance — vendor inventory + shadow SaaS, inferred ownership, cleanup candidates, complexity / operational risk / maintainability / blast radius.
• Prioritisation & reporting — security gradecard (5 category grades), remediation roadmap (reduction-per-effort), security debt, account benchmark, and a run-level executive summary, portfolio ranking and vendor dependency graph.
• Compliance — Google / Microsoft bulk-sender mapping (DNS-checkable portion) + a stable findings catalogue (DNS-NNN).
• Monitoring — opt-in cross-run drift with regression alerts, change narratives, baselines and churn.

The full raw record set (A/AAAA/MX/NS/TXT/CNAME/SOA) is still on every record. You get the decision and the data.

(Formerly DNS Record Lookup — it still does every lookup dig does; the lookups are now the data layer underneath the intelligence.)

---

Problems this finds

• Your domain is spoofable. No enforced DMARC means attackers can impersonate your domain in email today.
• Forgotten SaaS still has the keys. Marketing connected Mailchimp in 2021; it can still send as you, and nobody remembers it. The actor surfaces it as a third-party sender and a cleanup candidate.
• SPF is silently broken. Mail that should authenticate fails because SPF exceeds the RFC 7208 10-lookup limit and returns PermError — invisible until deliverability drops.
• Vendor concentration risk. Dozens of domains depend on one mail gateway; a single outage takes them all down. The dependency graph and singlePointsOfFailure make it visible.
• A control was quietly removed. DMARC went from reject to none after two years of stability — the regression alert and change narrative catch it.

---

Records vs decisions

Most DNS tools return things. This returns work to do.

A raw DNS lookup gives you	This actor also gives you
dmarcRecord: "v=DMARC1; p=none"	"DMARC is monitoring-only — your domain is still spoofable. Move to p=reject."
spfRecord: "v=spf1 include:a include:b … ~all"	"SPF is at 11 DNS lookups — over the limit. Receivers return PermError and SPF fails."
mxRecords: [...], nsRecords: [...]	"Single self-hosted MX, one nameserver — no redundancy."
cnameRecords: ["x.s3.amazonaws.com"]	"CNAME points to an unclaimed target — possible subdomain-takeover exposure."
13 fields you still have to interpret	postureScore: 41, riskLevel: "critical", recommendedAction: "fix-now"

How this compares

DNS and email tools cluster into a few categories. Each is good at its slice; this actor spans the decision + governance layer on top of all of them.

Capability	DNS diagnostic tools (dig, nslookup, MXToolbox)	DMARC platforms (EasyDMARC, Dmarcian)	Exposure-mapping platforms (Hardenize)	This actor
Raw record lookup	✓	partial	✓	✓
SPF lookup-limit detection	partial	✓	✓	✓
DMARC maturity scoring	✗	✓	✓	✓
MTA-STS / TLS-RPT / BIMI	partial	partial	✓	✓
DNSSEC	partial	✗	✓	✓
Vendor inventory + shadow-SaaS	✗	✗	partial	✓
Operational risk + blast radius	✗	✗	partial	✓
Remediation roadmap (fix-first)	✗	partial	✗	✓
Portfolio ranking + dependency graph	✗	partial	partial	✓
Runs in your own pipeline (Apify API, no SaaS seat)	✗	✗	✗	✓

Comparison reflects the typical focus of each category; specific products evolve their feature sets over time.

---

Why this exists

Running dig against one domain is easy. Auditing the email security and DNS resilience of 50, 500 or 5,000 domains — and knowing which of them to fix first — is not. Reading a raw SPF string and deciding whether it is safe takes expertise; reading recommendedAction: "fix-now" and whyFlagged takes a second.

This actor does the interpretation for you, deterministically. The same domain always produces the same score — no LLM, no randomness, no external API. It runs on Node's native DNS resolver, so there are no third-party keys, no rate limits, and nothing to manage.

---

How it works

1. Clean + de-duplicate the input domains (protocol, path, port and www. are stripped; duplicates removed).
2. Resolve A, AAAA, MX, NS, TXT, CNAME and SOA in parallel, plus SPF / DMARC / DKIM when email-security checks are on.
3. Analyse the email-authentication posture (SPF policy + lookup limit, DMARC strength, DKIM), the DNS resilience (redundancy, takeover risk), and the providers.
4. Score each domain into a posture (0–100) + grade, derive a riskLevel, stable riskFlags, and a recommendedAction, with a plain-English whyFlagged and summary.
5. Stream each domain's record as it finishes, then emit a run-level summary (grade distribution, spoofable count, worst domains, prioritised recommendations).

Every domain's record is pushed the moment it is ready, so the first results appear within a second or two even on large runs.

---

What you learn

Executive view — one domain at a glance

The fields most people act on sit at the top of every record:

{
  "domain": "corp.example",
  "postureGrade": "D",
  "spoofable": true,
  "riskLevel": "high",
  "recommendedAction": "fix-now",
  "topFix": "Advance DMARC from p=none to p=quarantine, then p=reject.",
  "ownership": { "likelyOwner": "marketing", "confidence": "medium" },
  "maintainability": { "score": 58, "level": "moderate" }
}

Portfolio view — the whole estate in one summary record

Run it against your full list and the closing summary record is the MSP / exec report:

{
  "recordType": "summary",
  "domainsAnalyzed": 527,
  "averagePostureScore": 71,
  "executiveSummary": { "domains": 527, "critical": 9, "high": 22, "spoofable": 31, "averagePostureScore": 71 },
  "portfolioRanking": [
    { "priority": 1, "domain": "legacy.example.net", "postureScore": 18, "spoofable": true, "topRisk": "NO_DMARC" }
  ],
  "criticalVendors": [{ "vendor": "Proofpoint", "domains": 214, "sharePct": 41 }],
  "singlePointsOfFailure": [{ "vendor": "Proofpoint", "affectedDomains": 214, "sharePct": 41 }],
  "recommendations": [
    "21 domain(s) have no DMARC record — they are spoofable. Publish DMARC, then enforce p=reject.",
    "Portfolio concentrated on Proofpoint (41% of domains) — a single vendor outage has wide blast radius."
  ]
}

527 domains in, "fix these 9 first and you depend on Proofpoint" out.

Detailed view — the full record

A representative domain record, abridged to the high-signal blocks (a real record carries more):

{
    "recordType": "domain",
    "domain": "example.com",
    "postureScore": 41, "postureGrade": "E", "spoofable": true,
    "riskLevel": "critical", "recommendedAction": "fix-now",
    "topFix": "Advance DMARC from p=none to p=quarantine, then p=reject.",
    "riskFlags": ["DMARC_MONITOR_ONLY", "SPF_LOOKUP_LIMIT_EXCEEDED", "SPOOFABLE"],
    "whyFlagged": "DMARC is monitoring-only (p=none) — spoofed mail is still delivered.",
    "emailAuth": {
        "spf": { "policy": "softfail", "resolvedLookupCount": 11, "lookupRisk": "exceeds-limit", "distinctVendors": 6 },
        "dmarc": { "policy": "none", "enforced": false, "maturityScore": 36, "maturityLevel": "monitoring" },
        "dkim": { "present": true },
        "spoofable": true, "spoofableReason": "DMARC p=none does not reject spoofed mail.",
        "recommendedActions": ["Reduce SPF DNS lookups below 10.", "Advance DMARC to p=quarantine, then p=reject."]
    },
    "dnssec": { "status": "unsigned" },
    "gradecard": { "emailAuthentication": "E", "transportSecurity": "C", "dnsResilience": "B", "attackSurface": "A+", "monitoringReadiness": "B", "overall": "C" },
    "remediationPlan": [
        { "priority": 1, "findingId": "DNS-003", "title": "Enable DMARC enforcement", "effort": "low", "scoreGain": 16 }
    ],
    "securityDebt": { "score": 41, "level": "medium" },
    "benchmark": { "percentile": 34, "band": "below-average", "population": "domains analysed on this account" },
    "vendors": { "count": 3, "thirdPartySenders": ["SendGrid", "Mailchimp"], "risk": "medium" },
    "ownership": { "likelyOwner": "marketing", "confidence": "medium" },
    "cleanupCandidates": [{ "vendor": "Mailchimp", "reason": "DKIM selector with no SPF — may be stale.", "recommendation": "review" }],
    "complexity": { "score": 45, "level": "high" },
    "operationalRisk": { "score": 22, "level": "medium" },
    "maintainability": { "score": 58, "level": "moderate" },
    "blastRadius": { "email": "high", "web": "medium", "identity": "low" }

    // … plus modernEmailSecurity (MTA-STS/TLS-RPT/BIMI), mailArchitecture, dnsHealth, providers,
    //    compliance, findings[], domainRole, the raw A/AAAA/MX/NS/TXT/CNAME/SOA records, and nextActions[].
}

The closing summary record (shown as the "Portfolio view" above) carries the run-level rollup: executiveSummary, portfolioRanking, grade distribution, the vendor dependency graph, criticalVendors, singlePointsOfFailure and prioritised recommendations. It is also mirrored to the key-value store under SUMMARY.

Headline output fields

Field	Description
recordType	domain | summary | error.
resolved	false when the domain returned no DNS records (likely does not exist / misspelled). Unresolved domains are reported but not billed and excluded from the posture statistics.
postureScore / postureGrade	0–100 composite + letter grade (A+ → F). Higher is better.
riskLevel	critical | high | medium | low | none.
riskFlags	Stable tokens: NO_DMARC, DMARC_MONITOR_ONLY, DMARC_NOT_ENFORCED, NO_SPF, SPF_PASS_ALL, SPF_NEUTRAL, SPF_LOOKUP_LIMIT_EXCEEDED, SPF_LOOKUP_LIMIT_NEAR, SPOOFABLE, NO_DKIM, DANGLING_CNAME_RISK, SINGLE_POINT_OF_FAILURE.
recommendedAction	fix-now | review | monitor | ok.
whyFlagged / summary	Plain-English reason + ≤280-char summary line.
emailAuth	Full SPF (policy + lookup-limit + include tree + vendor count) / DMARC (+ maturity) / DKIM + spoofable + recommendedActions.
modernEmailSecurity	MTA-STS (+ mode), TLS-RPT, BIMI (+ VMC), adoptionScore.
mailArchitecture	Inferred inbound provider, security gateway, outbound senders.
dnsHealth	Redundancy, single-point-of-failure, IPv6, dangling-CNAME risk, dead-MX.
dnssec	status: signed-validated / signed / unsigned / unknown.
providers	DNS provider, mail provider, mail-provider category.
subdomainProtected	Whether the DMARC policy governs subdomains.
domainRole	Inferred role: primary / mail-only / web-only / parked-or-inactive.
findings	Stable misconfiguration catalogue (DNS-NNN id + severity + title).
compliance	Google / Microsoft bulk-sender mapping (DNS-checkable portion) + CIS controls.
gradecard	Five executive category letter-grades + overall.
remediationPlan	Findings ordered by reduction-per-effort (priority, effort, scoreGain).
securityDebt	Accumulated unfixed-risk score + level.
benchmark	Posture percentile vs domains scanned on this account.
topFix	The single highest-priority remediation for this domain.
vendors	Vendor inventory (vendors[] + thirdPartySenders[] shadow SaaS + count + risk).
ownership	Inferred owning team (likelyOwner + confidence + evidence) from the vendor mix.
cleanupCandidates	Vendors authorised in SPF/DKIM only — "can I remove this?" review candidates.
complexity	Structural complexity score + level + drivers.
operationalRisk	Operational fragility score + level + drivers.
maintainability	"Is this manageable to operate?" score + level.
blastRadius	email / web / identity impact-if-it-breaks.
monitoring	Cross-run drift (only when watchlistName is set) — changeType, driftSeverity, changeImpactScore, regression, changes, postureScoreDelta, trend.

---

Input

Name	Type	Default	Description
domains	string[]	—	Domains to analyse. Protocol / path / port / www. stripped; duplicates removed.
recordTypes	string[]	all 7	Which DNS record types to resolve.
checkEmailSecurity	boolean	true	Resolve SPF, DMARC and DKIM (required for the posture engine).
timeout	integer	5000	Per-query timeout in ms (1,000–30,000).
analysisMode	select	balanced	Re-weights the posture score: deliverability (SPF/DMARC/DKIM heaviest), security (DNS resilience + takeover risk), monitoring (scheduled re-runs), or balanced.
outputProfile	select	standard	minimal (decision fields only — for Zapier/Make rules), standard, or full (every diagnostic block).
expandSpfIncludes	boolean	false	Resolve the full SPF include chain to count real DNS lookups (catches PermErrors) and map sending vendors. Adds extra DNS queries; when off, a static lower-bound count is used.
checkDnssec	boolean	true	Query DNSSEC state via Cloudflare DNS-over-HTTPS (no key). Adds one lightweight HTTPS request per domain.
watchlistName	string	—	Name a watchlist to persist this run's fingerprint and diff it next run — flags DMARC/SPF downgrades, DKIM removal, MX / mail-provider changes, and tracks a posture-score trend.
maxPostureScore	integer	100	Surface (and bill for) only domains scoring at or below this — i.e. only the domains that need attention.

Example — audit a portfolio, deliverability lens, surface only the problems:

{
    "domains": ["example.com", "legacy.example.net", "shop.example.org"],
    "analysisMode": "deliverability",
    "expandSpfIncludes": true,
    "maxPostureScore": 70
}

---

Monitoring (scheduled runs)

Set a watchlistName and schedule the actor. On the first run every domain reads changeType: "new". From the second run on, each record carries a monitoring block flagging what drifted since last time:

• dmarc-weakened (e.g. reject → none) and spf-weakened (e.g. -all → ~all) — regressions: a security control was weakened. monitoring.regression: true.
• mx-changed / mail-provider-changed — your mail routing moved.
• dkim-removed, nameservers-changed, a-records-changed.

Each carries a driftSeverity plus a numeric changeImpactScore (so alert routing can branch on WHERE monitoring.regression = true or threshold on the score), and a trend block tracking the posture score across runs (improving / declining / stable). Every record also gets:

• baseline — firstSeen and daysStable (how long the config held before this change). A change after 3 days reads very differently from one after 3 years.
• driftRisk — { level, reason }, the business-impact framing of the change (a regression elevates to at least high).
• changeFrequency — last30Days / last90Days change counts + a risk band. Frequently-changing domains are usually unmanaged or mid-migration.
• changeNarrative — a paste-ready one-liner with an importance tier: "DMARC enforcement removed after 742 days of stability." Drops straight into a SOC ticket, a change-review (CAB) note, or a Slack alert.

This turns a one-off lookup into continuous DNS / email-auth monitoring with regression alerting.

---

Prioritisation & reporting

The actor does not just flag problems — it tells you what to fix first and packages the run for a report.

• Remediation roadmap — every record carries a remediationPlan[] ordered by reduction-per-effort: the fix that recovers the most posture for the least work is priority: 1. Each step has effort (low/medium/high), scoreGain, and the stable findingId. Security teams fix queues, not findings.
• Security gradecard — five category letter-grades (emailAuthentication, transportSecurity, dnsResilience, attackSurface, monitoringReadiness) plus overall. An executive reads A / C / A / C / B in one glance.
• Security debt — securityDebt.score (0–100) is the accumulated weight of unfixed findings, aged up the longer they stay open (with a watchlist).
• Benchmark — benchmark.percentile answers "is 72 good?" by comparing against the domains you have scanned on this account (it is honestly account-scoped, never a fabricated global figure, and stays null until the pool has ≥ 10 samples).
• Portfolio ranking — the run summary carries a portfolioRanking[] (worst domains first, with priority) and an executiveSummary block (critical / high / spoofable counts + average score) that drops straight into an MSP client report.

---

Vendor & governance intelligence

Most DNS tools answer "what does this domain look like?". This one also answers "what are we dependent on, and is it manageable?" — entirely from the records already resolved.

• Vendor inventory — vendors lists every vendor authorised to send or route mail (Microsoft 365, Salesforce, SendGrid, Mailchimp, Zendesk, …), classified by kind (mailbox / gateway / esp / sender) and sources (mx / spf / dkim). thirdPartySenders[] surfaces the shadow SaaS — the senders marketing wired up years ago that nobody remembers.
• Ownership — ownership infers which team likely owns the setup (IT / marketing / developers) from the vendor mix, so you know who to talk to before changing anything. Heuristic and labelled "likely" — ownership isn't literally in DNS.
• Cleanup candidates — cleanupCandidates[] flags vendors authorised in SPF (or a lone DKIM selector) with no other evidence they're in use — the "can I safely remove this?" review list. It recommends review, never blind removal.
• Vendor dependency graph — the run summary carries vendorDependencies (each vendor → which of your domains depend on it), criticalVendors[] (vendors ≥ 40% of the portfolio leans on), and singlePointsOfFailure[] (vendors ≥ 50% depend on, with the affected domain list). "If our mail gateway has an outage, how many domains go dark?" — answered.
• Complexity, operational risk & maintainability — complexity scores how complicated the setup is; operationalRisk scores how fragile it is to run; maintainability collapses both (plus monitoring hooks) into one "is this manageable?" number. Complex, fragile environments fail more.
• Blast radius — blastRadius tells you, per domain, whether a config break takes out email, web, or identity.

M&A due-diligence mode

Set analysisMode: "mna" to point this at a target company's domain portfolio. The run summary adds an acquisitionReadiness block — a graded composite of email/DNS posture, operational fragility, infrastructure complexity, and vendor sprawl — that a consultant drops straight into a due-diligence report.

{ "domains": ["targetco.com", "targetco.net", "mail.targetco.com"], "analysisMode": "mna", "expandSpfIncludes": true }

---

Use in Dify

Drop this actor into Dify workflows via the Apify plugin's Run Actor node. Every domain returns scored, classified and recommended as structured JSON — fix-now / review / monitor / ok plus the riskLevel and spoofable flags your downstream if/else node branches on. A raw DNS tool pointed at the same domain returns record strings you still have to interpret; this returns the decision.

• Actor ID: ryanclinton/dns-record-lookup
• Sample input (deliverability audit, surface only the domains that need work):

{
    "domains": ["example.com", "shop.example.org", "mail.example.net"],
    "analysisMode": "deliverability",
    "maxPostureScore": 70,
    "outputProfile": "minimal"
}

• Branching example — a Dify if/else node routes on the decision enum:
  • recommendedAction == "fix-now" → open a ticket / page the on-call.
  • emailAuth.spoofable == true → hold the campaign for that domain.
  • recommendedAction == "ok" → continue.
• Monitoring mode — add a watchlistName and the monitoring.driftSeverity enum lets a scheduled Dify flow alert only on critical drift (a DMARC downgrade) and ignore the rest.

The recommendedActions[] array on emailAuth is usable verbatim — concrete remediation steps ("Advance DMARC from p=none to p=quarantine, then p=reject"), no LLM rewriting needed.

---

Combine with other Apify actors

Each record carries a nextActions[] array pointing at the right sibling to run next:

Actor	Why pair it
WHOIS Domain Lookup	Registration, registrar, expiry and ownership for the same domains.
SSL Certificate Search	Subdomain enumeration and look-alike / typosquat detection via Certificate Transparency.
IP Geolocation Lookup	Geolocate and classify the resolved A/AAAA addresses and mail servers.
Website Tech Stack Detector	Cross-reference DNS with the technologies a site runs for a full infrastructure profile.

---

API

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")
run = client.actor("ryanclinton/dns-record-lookup").call(run_input={
    "domains": ["example.com", "shop.example.org"],
    "analysisMode": "deliverability",
})
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    if item.get("recordType") == "domain":
        print(f'{item["domain"]}: {item["postureGrade"]} — {item["recommendedAction"]} — {item["whyFlagged"]}')

import { ApifyClient } from "apify-client";

const client = new ApifyClient({ token: "YOUR_API_TOKEN" });
const run = await client.actor("ryanclinton/dns-record-lookup").call({
    domains: ["example.com", "shop.example.org"],
    analysisMode: "deliverability",
});
const { items } = await client.dataset(run.defaultDatasetId).listItems();
for (const it of items.filter((r) => r.recordType === "domain")) {
    console.log(`${it.domain}: ${it.postureGrade} — ${it.recommendedAction}${it.emailAuth?.spoofable ? " — SPOOFABLE" : ""}`);
}

---

What this does NOT do

• It does not probe live SMTP / STARTTLS. TLS-grade and opportunistic-TLS detection require live SMTP connections to each mail server on port 25 — a different capability from DNS resolution, and one that cloud egress commonly blocks. The DNS-native alternative (DANE / TLSA records) is also out of reach: Node's resolver exposes no TLSA record type. MTA-STS and TLS-RPT cover the DNS-resolvable side of transport security.
• It does not hunt typosquats / look-alike domains. The domains you pass in are the subjects being audited, not candidates to compare against a brand. For typosquat and look-alike discovery, use SSL Certificate Search, which scans Certificate Transparency logs.
• It does not expose TTLs. Node's dns.promises API does not return TTL values.
• Compliance mapping covers the DNS-checkable portion only. The Google / Microsoft bulk-sender pass/fail reflects SPF + DKIM + DMARC presence. It does not verify spam-rate, one-click-unsubscribe, or message formatting, which are not visible in DNS.
• It does not exhaustively enumerate DKIM selectors. It probes common selectors; domains using a custom selector may report dkim.present: false even when DKIM is configured.
• DKIM presence ≠ valid signing. It confirms a selector record exists, not that mail is correctly signed end to end.
• Results are resolver-dependent and point-in-time. Resolution reflects the nameservers Apify's infrastructure uses, at the lookupTimestamp recorded.

---

FAQ

Is my domain spoofable? The emailAuth.spoofable boolean answers it directly, with spoofableReason explaining why. A domain is spoofable when DMARC is not enforced (p=reject/p=quarantine at 100%) or SPF does not hard/soft-fail unauthorised senders.

Why does the actor say my SPF "exceeds the limit"? RFC 7208 caps SPF at 10 DNS lookups. Over the cap, receivers return a PermError and SPF silently fails — mail that should pass starts failing. Turn on expandSpfIncludes to count the real include-tree depth instead of the static lower bound.

What does recommendedAction mean? It is the single field to branch on: fix-now (critical risk), review (high), monitor (medium), ok (low/none). It is derived deterministically from the risk flags.

Do I need an API key? No. It uses Node's native DNS resolver — no third-party accounts, no external rate limits.

What happens to a domain that does not exist? It comes back with resolved: false and a clear message, is excluded from the posture statistics, and is not billed.

Can I get just the decision fields? Set outputProfile: "minimal" — you get the score, grade, spoofable, recommendedAction and the primary identifiers, ideal for Zapier / Make / n8n rules.

Can I monitor for DNS changes? Yes — set a watchlistName and schedule the run. Each record then carries a monitoring block flagging DMARC downgrades, MX / mail-provider changes, and more, with a driftSeverity for alert routing.