Email deliverability

The email deliverability check reads your domain's SPF, DKIM, DMARC, and BIMI DNS records every 6 hours by default. If any record goes missing, becomes structurally invalid, or changes unexpectedly, DomainCare fires an alert. Broken email deliverability lets spam filters reject your mail and leaves your domain open to spoofing.

What it monitors

• SPF — checks the v=spf1 TXT record at the root domain; parses the all mechanism (-all, ~all, ?all, +all). When no SPF record is found on the root domain but DKIM is verified, DomainCare probes 8 common delegation subdomains (send., bounces., mail., mta., mailer., return., smtp., envelope.) — providers like Resend, Amazon SES, and Postmark delegate SPF to a subdomain rather than the root. If SPF is found on a delegated subdomain, the check passes and notes which subdomain carries the record.
• DMARC — checks the v=DMARC1 TXT record at _dmarc.<domain>; parses the p= policy (none, quarantine, reject)
• DKIM — probes 15 common selectors (default, google, s1, s2, selector1, selector2, k1, k2, k3, dkim, mail, em, mandrill, smtp, cm) at <selector>._domainkey.<domain>; validates that each found record carries a non-empty public key (p=). The v=DKIM1 version tag is optional (per RFC 6376) — keys published without it are still counted as valid. An empty p= means a revoked key and is flagged.
• BIMI — checks for a v=BIMI1 TXT record at default._bimi.<domain>

How often it runs

The email deliverability check runs every 6 hours (21,600 seconds) by default. Paid plans can override this to a faster interval per domain via per-check controls.

Check status. The check shows healthy (green) only when SPF is present with an all mechanism, DMARC is present, and at least one probed DKIM selector carries a valid key. Missing or invalid SPF, missing DMARC, missing DKIM, or DKIM with only revoked/malformed keys marks the check failing (red) — the same conditions that fire the failure alerts below. DMARC present with p=none shows needs attention (amber): mail flows, but the policy tells receivers to take no action on failures. Note the DKIM probe covers the 15 common selectors listed above — if your provider signs with a non-standard selector, the check can't see it and will read as DKIM-missing; use per-check controls to disable the check for that domain, or add a DKIM record at one of the probed selectors.

Every regression, change, and recovery is confirmed across two consecutive checks before it alerts: a record has to be observed missing (or changed) twice in a row, against a baseline where it was present, before the event fires. A single odd read — a resolver hiccup, an authoritative server dropping one query — never produces an alert, and recoveries are gated the same way as failures, so you never get a paired false "missing"/"restored" pair. The trade-off: a genuine regression alerts one check cycle later than it is first observed.

A transient DNS failure — a resolver timeout, SERVFAIL, or temporary lookup error — is not treated as a missing record. Each lookup retries in-run with backoff, switching to an independent public resolver before DomainCare concedes it couldn't check. If the state still can't be determined, the check is marked unavailable for that run, and no "record missing" alert — nor a later "recovered" notice — is sent. The same applies per DKIM selector: a selector whose lookup stays transient is treated as unknown for that run (the run shows as a grey partial bar in the history), not as removed.

When a genuine change is first observed, DomainCare doesn't wait a full interval to confirm it: a fast-confirm re-check runs about 10 minutes later, so a real record deletion alerts within minutes while a one-off blip dies silently.

Alerts this check produces

Event	Tone	When it fires
spf_record_missing	Failure	No v=spf1 TXT record found at the domain root for two consecutive checks (immediately on first scan)
spf_record_invalid	Failure	A previously-valid SPF record lost its all mechanism (e.g. dropped -all or ~all) and the broken state held across two checks. Does not fire on first scan or when SPF is missing — that's spf_record_missing.
spf_record_changed	Warning	SPF record content changed and the new value held across two checks (suppressed for delegation-sourced records to avoid noise from subdomain probe variance)
spf_recovered	Recovery	SPF record is present again for two consecutive checks after a confirmed missing event
dmarc_record_missing	Failure	No v=DMARC1 TXT record found at _dmarc.<domain> for two consecutive checks (immediately on first scan)
dmarc_record_changed	Warning	DMARC record content changed and the new value held across two checks
dmarc_policy_changed	Warning	The p= policy in the DMARC record changed (e.g. none → quarantine) and the new policy held across two checks
dmarc_recovered	Recovery	DMARC record is present again for two consecutive checks after a confirmed missing event
dkim_record_missing	Failure	No probed selector returned a valid DKIM record for two consecutive checks (immediately on first scan)
dkim_selector_changed	Warning	The set of selectors with valid DKIM records changed and the new set held across two checks
dkim_public_key_issues	Failure	A DKIM record was found whose public key is missing or empty (p= — revoked key), confirmed across two checks. Reported once per selector, not repeatedly.
dkim_recovered	Recovery	A valid DKIM record is present again for two consecutive checks after a confirmed missing event
bimi_record_missing	Warning	The previously-present v=BIMI1 record has been absent for two consecutive checks
bimi_recovered	Recovery	BIMI record is present again for two consecutive checks after a confirmed missing event

What to do when alerts fire

• spf_record_missing / spf_record_invalid — add or repair the SPF TXT record at your domain root. A minimal strict record looks like v=spf1 include:_spf.yourmailprovider.com -all. Use -all (hard fail) rather than ~all (soft fail) for strongest protection. Avoid multiple SPF records — only one v=spf1 record is allowed.
• dmarc_record_missing — add a _dmarc.<domain> TXT record. Start with v=DMARC1; p=none; rua=mailto:reports@example.com to collect reports without blocking mail, then move to quarantine or reject once you are confident all legitimate senders are covered by SPF and DKIM.
• dmarc_policy_changed — verify the change was intentional. An accidental drop from reject to none removes your phishing protection.
• dkim_record_missing / dkim_public_key_issues — check with your email sending service for the correct selector and key. DKIM selectors are provider-specific; if you recently switched providers the old selectors may still be in DNS while the new ones are missing. DomainCare probes 15 common selectors — if your provider uses a non-standard selector it will not be detected.
• spf_record_changed / dmarc_record_changed — confirm the change was intentional (e.g. adding a new mail sender). Unauthorized changes may indicate DNS compromise; check your DNS provider's audit log.

Related

• DNS checks — email auth records live in DNS; DNS change alerts can precede email auth alerts
• What is DMARC?
• Alert reference