Domain Health Checker: SPF, DMARC, SSL Expiry

This domain health checker audits a list of domains (SPF, DMARC, DKIM, SSL certificate expiry and DNS) and gives you one row per domain with the checks that decide whether your website stays up and your email lands in the inbox: SSL certificate expiry and issuer, SPF (present, valid, too many lookups), DMARC policy, DKIM at the common selectors, MX, A/AAAA, HTTP to HTTPS redirect and HSTS. Each row has a 0-100 health score and plain-English fix hints.

It reads DNS directly and makes one TLS connection per domain. No WHOIS, no crawling, no third-party API. Built for agencies auditing client portfolios, sales teams qualifying prospects ("their DMARC is p=none and their certificate expires in 9 days"), and anyone who wants a scheduled domain monitoring run: put it on an Apify schedule and alert on the score or sslDaysToExpiry.

Pricing: $0.004 per domain plus $0.005 per run. 1,000 domains cost $4.005.

Why use this domain health checker

Most domain actors give you either a certificate check or a WHOIS/DNS dump. This one puts the email-deliverability checks and SSL expiry in the same row, with a score you can sort by.

	Domain Health Audit	SSL-only checkers (e.g. automation-lab/ssl-certificate-checker)	WHOIS/DNS dump actors (e.g. santamaria-automations/domain-whois-dns)
SSL expiry, issuer, hostname match	Yes	Yes	Varies
SPF validity and the 10-lookup limit	Yes	No	Raw records only
DMARC policy, DKIM selectors	Yes	No	Raw records only
HTTP to HTTPS redirect, HSTS	Yes	Sometimes	No
Score and fix hints	Yes	No	No
WHOIS registrant / registrar data	No	No	Yes

If you need registration dates, registrar or registrant details, use a WHOIS actor. This actor deliberately does not do WHOIS.

What the SPF, DMARC and SSL checker returns per domain

Group	Fields
Overall	domain, status, score (0-100), scoreBreakdown, fixHints, notes, checkedAt
DNS	resolves, ipv4, ipv6, mxPresent, mxNull, mxRecords
SPF	spfPresent, spfValid, spfPolicy (fail (-all) / softfail (~all) / ...), spfLookups, spfTooManyLookups, spfRecord, spfErrors
DMARC	dmarcPresent, dmarcValid, dmarcPolicy (none / quarantine / reject), dmarcSubdomainPolicy, dmarcPct, dmarcRua (the aggregate-report address(es) from the record's rua= tag, or null), dmarcRecord
DKIM	dkimSelectorsChecked, dkimSelectorsFound (checks google, selector1, selector2, default, k1, plus up to 5 of your own)
SSL	sslReachable, sslIssuer, sslSubject, sslNotAfter, sslDaysToExpiry, sslExpired, sslHostnameMatch, sslSelfSigned, chainTrusted, tlsVersion, sslError
Web	httpRedirectsToHttps, httpStatus, httpsStatus, hsts, hstsMaxAge

A value of null means "could not be assessed" (for example the website's robots.txt blocked the request), never "failed". null checks are left out of the score.

Input

Field	Description
domains	Domain names (example.com). URLs are reduced to their host name. Duplicates are audited once. Up to 5,000 per run.
extraDkimSelectors	Optional, up to 5 extra DKIM selectors to check (e.g. s1, mandrill).

Run it with no input and you get a 3-domain sample (apify.com, github.com, example.com).

Example input

{
    "domains": ["example.com", "github.com", "https://www.apify.com/pricing"],
    "extraDkimSelectors": ["s1"]
}

Example output (shortened)

{
    "domain": "apify.com",
    "status": "audited",
    "score": 100,
    "mxPresent": true,
    "spfPresent": true,
    "spfValid": true,
    "spfPolicy": "fail (-all)",
    "spfLookups": 10,
    "dmarcPresent": true,
    "dmarcPolicy": "reject",
    "dkimSelectorsFound": ["google"],
    "sslIssuer": "Amazon",
    "sslDaysToExpiry": 87,
    "sslHostnameMatch": true,
    "httpRedirectsToHttps": true,
    "hsts": true,
    "hstsMaxAge": 15768000,
    "fixHints": [],
    "checkedAt": "2026-10-21T19:39:49+00:00"
}

A domain with problems gets hints such as: "The TLS certificate expires in 5 days. Renew it (check that automatic renewal is working).", "SPF needs 12 DNS lookups (limit 10). Remove unused includes or flatten the record.", "Plain HTTP is served without redirecting; add a permanent (301) redirect from http:// to https://."

How the score works

Points are earned out of 110 and rescaled to 0-100 (also rescaled if some checks could not be assessed):

Check	Points
Domain resolves (A/AAAA)	10
MX present (a null MX counts)	5
SPF: valid record 8, within 10 lookups 3, ends in -all/~all 4	15
DMARC: valid record 8, quarantine +6 or reject +12	20
DKIM key found at a checked selector	5
TLS: handshake works and certificate not self-signed 5, not expired 10, 30+ days left 10 (14-29 days: 5), chain trusted 10, hostname matches 10	45
HTTP redirects to HTTPS	5
HSTS sent over HTTPS	5

scoreBreakdown shows [earned, max] for every check, so you can build your own weighting.

Pricing (pay per event)

Event	Price	When it is charged
Actor start	$0.005	Once per run
Domain audited	$0.004	Per domain audited (invalid names, NXDOMAIN, duplicates and failed audits are free)

Domains	Approximate cost
100	$0.405
1,000	$4.005
5,000	$20.005

• Actor start: $0.005 per run (Apify's apify-actor-start event). Maximum run memory is capped at 1,024 MB so the start event is never multiplied.
• Domain audited: $0.004 per domain (domain-audited event), charged after the row is saved.
• Not charged: invalid names, non-existent domains (NXDOMAIN), duplicates, and audits that failed or timed out. They still get a row with a status (invalid-domain, nxdomain, dns-error, error) so you can match results to your list.
• A domain with working DNS but no website, or a website that blocks the check, is still an audit and is charged.

Example: 500 client domains weekly = $2.005 per run. The run stops cleanly if you set a maximum cost per run.

What the actor connects to

For every domain, and nothing else:

1. DNS queries (A, AAAA, MX, TXT, _dmarc TXT, the DKIM selector TXT names, and the TXT records of SPF include: / redirect= targets, at most 14 SPF names) through the system resolver.
2. One TLS handshake on port 443 of the domain's public IP, which provides the certificate, and a second handshake with certificate verification on (system CA store plus the certifi bundle) that only reports whether the chain is trusted (chainTrusted); no HTTP request is sent on it.
3. robots.txt and one HEAD / request on https, reusing that connection (this is also where the HSTS header comes from).
4. robots.txt and one HEAD / request on http (port 80) for the redirect check.

No page is ever downloaded and nothing is crawled. The HEAD is never redirected or followed; a redirect is read from its Location header. The actor identifies itself with a Venture100-DomainHealthAudit User-Agent.

Compliance and safety

• robots.txt: honoured per RFC 9309 (wildcards, $, longest match). If robots.txt cannot be fetched (timeout, connection error, 5xx or 429) the request fails closed: the HEAD is skipped and the field is null with a note. A 4xx means no restrictions. This cannot be switched off.
• SSRF protection: a domain that resolves to a private, loopback, link-local or otherwise non-public address is never contacted over HTTP(S). The address is checked first and the connection is pinned to that checked address (no second DNS lookup), and every redirect hop of robots.txt is checked again.
• Rate: requests to one host are spaced about 1 second apart (so a domain takes roughly 4-6 seconds; up to 20 domains run in parallel). At most 4 requests or handshakes are in flight to any one IP address at a time, so many domains on one shared server are not hit in parallel.
• Licences: dependencies are the Apify SDK (Apache-2.0), dnspython (ISC), httpx (BSD-3-Clause) and cryptography (Apache-2.0 or BSD-3-Clause). certifi (MPL-2.0, weak copyleft, installed with httpx and listed in requirements) is used unmodified as a CA-bundle data package. No GPL/AGPL dependency.
• Data you submit / what is stored: the audit rows are stored in the run's default dataset; your input (including the domain list) is stored in the run's key-value store as the INPUT record, alongside a small PROGRESS record (counters only). All of it is kept under standard Apify storage retention. You can delete them at any time. Nothing is sent to third parties other than the DNS and web requests above to the domains' own servers. Audit only domains you are entitled to examine; these are the same lookups any mail server or browser makes, but you are responsible for your use of the results.

Restarts and monitoring

Progress is saved to the key-value store, so a restart or migration continues without re-pushing or re-charging rows that were already delivered. Delivered rows are recorded in the progress record, so a lagging dataset item count cannot re-charge them. If a run is killed in the middle of a single save-and-charge call, that one group of rows (at most 20) is audited again and saved without a charge, marked recoveredAfterRestart: true, so nothing is lost or charged twice (a duplicate row is possible). For monitoring, schedule the actor (daily or weekly) and compare score, sslDaysToExpiry, dmarcPolicy between runs, or alert on sslDaysToExpiry < 14 with an Apify webhook or integration.

Not benchmarked at scale: a 3-domain sample run took about 8 seconds on a local machine, and memory use is small because domains are processed in batches of 20.

Limitations

• Certificate checks. The actor reads the certificate the server presents and checks dates, hostname (Subject Alternative Names, with RFC 6125 wildcard rules) and self-signed status. chainTrusted comes from a second handshake with verification on against the system CA store plus certifi; it is null (not scored) when that handshake cannot be made or the certificate is expired/not yet valid, since dates are scored separately. Trust is judged on the actor's CA store, which can differ from your own devices' store. Servers that only speak TLS 1.0/1.1 fail the handshake and show as having no HTTPS.
• The certificate is read from the apex name you give, not from other hostnames (a www. host is separate: add it as its own domain).
• DMARC is read at _dmarc.<the domain you give> only. A subdomain with no DMARC record of its own is reported as missing even though receivers would fall back to the parent domain's policy. Audit apex domains for email checks.
• DKIM: only the listed selectors are tried. "No DKIM found" means none of those selectors exist, not that the domain does not sign mail. Custom selectors can be added with extraDkimSelectors.
• SPF lookups are counted per RFC 7208 (include, a, mx, ptr, exists, redirect) by following includes; the per-mx/a address lookups are not expanded, and ptr/exists macros are not evaluated.
• HTTP to HTTPS redirect looks at the first response only. If http:// redirects to another http:// address first (for example to www), the result is null with a note, as later hops are not followed.
• Some servers answer HEAD with errors (405/501); httpRedirectsToHttps is then null.
• No WHOIS, domain age, blacklist, open-port, web-content or subdomain checks. Internationalised domains are converted to punycode.
• Results are a point-in-time snapshot from the datacentre the run executes in; DNS answers can vary by resolver.

FAQ

How do I check SPF and DMARC for many domains? Add the domains to domains. Every domain gets one row with SPF validity and lookup count, the DMARC policy and DKIM selectors found, plus fix hints.

Can it warn me before an SSL certificate expires? Yes. Each row has sslDaysToExpiry and sslExpired. Put the actor on an Apify schedule and alert when sslDaysToExpiry is below 14.

Does it do WHOIS or domain age lookups? No. It reads DNS and makes one TLS connection per domain; use a WHOIS actor for registrar data.

Am I charged for domains that do not exist? No. Invalid names, non-existent domains, duplicates and failed audits are free.

Related Actors

• Email Validator & List Cleaner: validate and clean email lists (MX, disposable domains, typos).
• Phone Number Validator & Formatter: validate and format phone numbers in bulk, offline.
• PDF to Markdown for RAG: turn PDF, DOCX, PPTX and HTML into Markdown for LLMs.