Email DNS Audit: SPF, DMARC & DKIM Evidence

Collect verifiable email-domain configuration evidence for agency onboarding, DNS change reviews and recurring checks. Each domain gets its MX records, SPF dependency tree, DMARC records and optional DKIM key-presence checks.

Who this is for

For agencies onboarding client domains and IT teams reviewing DNS changes. Bring domain names and any known DKIM selectors; the output supports configuration review without sending mail.

Start with at most 10 result rows: the Actor event charges for that batch are at most $0.05 at the listed rate. Set both maxResults and the run's maximum charge before starting.

Quick start

Open the Input tab, paste your input and run. A small example:

{
  "domains": [
    "github.com",
    "google.com"
  ],
  "dkimSelectors": [],
  "maxResults": 10
}

Evidence instead of a deliverability score

The output includes raw DNS records, a bounded SPF include/redirect tree, static DNS-term counts, cycles and selected configuration findings. For DMARC, the Actor returns the exact-domain policy, DNS tree evidence and a legacy Public Suffix List candidate. RFC 9989 introduced a new discovery model in 2026; the output helps compare the evidence without claiming to reproduce every receiver's policy decision.

DKIM requires the selectors you already know. keyPublished indicates a non-empty public key field in DNS; it does not verify message signatures, key strength or sender authorization. No emails are sent, inboxes read, addresses discovered or mail servers probed.

Changes between runs

Supply earlier output rows in previousResults. Each domain's normalized DNS evidence is fingerprinted, and the Actor returns comparison and changedFields. DNS answers are taken from Google Public DNS over HTTPS at the stated checkedAt time; resolver caches and propagation can affect what is observed.

Important interpretation limits

SPF analysis expands at most 20 nodes and does not evaluate a sender IP. Macros require message context; MX/PTR subqueries are not counted in the static estimate. DMARC checks cover selected tags and tree evidence, not full RFC compliance or an effective inherited-policy verdict. Legacy pct, rf and ri tags are flagged for transition review. A monitoring policy is a factual finding, not an automatic vulnerability. Unknown selectors and absent records remain explicit; resolver failures are errors rather than false missing-policy findings.

Technical references: SPF RFC 7208, DMARC RFC 9989.

Pricing and limits

$5 per 1,000 delivered domain DNS audit results ($0.005 each). There is no Actor startup fee. Standard platform usage is included in this Actor's event price. A successfully delivered dataset row triggers one charge; error diagnostics live in RUN_SUMMARY and are not chargeable rows. Repeated runs are new checks and may return the same item again. The Pricing tab is authoritative.

Use the run's maximum charge setting and maxResults to control spending. No proxy subscription or external API key is required. Runs use 256 MB by default. For large batches, raise the run timeout or split the input; a hard timeout may leave an incomplete dataset. The presence of a finished RUN_SUMMARY helps distinguish completed processing from interrupted runs.

Export and integrations

Use the Output tab to inspect results and the summary. Download JSON, CSV or Excel from the dataset, or use Apify's API, Make, Zapier or n8n to pass the output into your existing workflow. Nested evidence is most faithfully preserved in JSON. The default dataset belongs to the run; no external destination receives results automatically.

An API client can start kirozhang/email-dns-auth-audit with the JSON above, wait for completion and read its default dataset. Set your Apify token in the client's credential store, never inside the input URLs.

Troubleshooting

Read RUN_SUMMARY.errors and limitReasons first. A partial run may contain useful rows; it must not be treated as exhaustive. All-target failure marks the run failed. A valid search with no matches can succeed with zero rows. For support, open an Issue on this Actor with the run ID, expected behavior and a public example target. Remove credentials and private data from your report.

Example output

Illustrative excerpt from a real verification run; values change over time.

{
  "domain": "github.com",
  "mx": [
    "0 github-com.mail.protection.outlook.com."
  ],
  "findings": [
    "LEGACY_DMARC_TAG_PCT"
  ],
  "comparison": "no_baseline",
  "checkedAt": "2026-11-06T12:35:56.490Z"
}

Workflows and questions

Client-domain checks after a DNS change

1. Run the supplied domain example first. For your domains, add only the DKIM selectors confirmed by the mail provider.
2. Export JSON and retain key, the normalized evidence and fingerprint fields.
3. Repeat with the earlier rows in previousResults. Review changed evidence alongside your DNS change record.
4. For a weekly task, pass the preceding dataset into the next run through your workflow. A saved task does not advance its own baseline automatically.

Common questions

Does this test inbox placement or send a message? No. It inspects public DNS only; it cannot establish deliverability or verify a message signature.

Will it find my DKIM selector? No. Ask the provider or inspect a message you control, then supply the selector. An empty selector list skips DKIM checks.

Is a DMARC monitoring policy a failure? It is a configuration fact for review. The Actor does not invent an overall security grade or claim to reproduce every receiver's DMARC decision.

API quick start

Save the Quick start JSON as input.json. Put your Apify token in the APIFY_TOKEN environment variable through your usual secret store, then run:

curl --fail-with-body --max-time 200 \
  --request POST \
  --header "Authorization: Bearer $APIFY_TOKEN" \
  --header "Content-Type: application/json" \
  --data-binary @input.json \
  "https://api.apify.com/v2/acts/kirozhang~email-dns-auth-audit/run-sync-get-dataset-items?timeout=180&memory=256&maxTotalChargeUsd=0.10&format=json&clean=true" \
  --output results.json

This example starts a real run and applies a $0.10 charge ceiling. The smaller maxResults cap still applies. An empty array can be a valid no-match result; inspect the run and RUN_SUMMARY in Console. If the connection times out, check Console before retrying, since the run may already exist. For larger exports, use the asynchronous API shown on this Actor's API tab and read the dataset after the run finishes.

Scheduling and workflow tools

After a successful small run, save a task with your production input. Apify schedules can run that task regularly. In Make, Zapier or n8n, store the token in the connection credentials, run this Actor, wait for completion, and read its dataset. Configure your own destination explicitly; this Actor does not send emails or post messages automatically. Each scheduled run may incur charges, including repeated results.

Related tools for different steps

• Extend client onboarding with a public website technology inventory.
• For a website move on the same domain, check redirects and canonical URLs separately.