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 contains v=DKIM1 and a non-empty public key (p=)
• 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. Pro and Business plans can override this to a faster interval per domain via per-check controls. A single check result showing a missing or invalid record triggers an alert — there is no consecutive-failure debounce because a missing SPF or DMARC record is immediately actionable.

Alerts this check produces

Event	Tone	When it fires
spf_record_missing	Failure	No v=spf1 TXT record found at the domain root
spf_record_invalid	Failure	Fires when a previously-valid SPF record loses its all mechanism (e.g. drops -all or ~all). Does not fire on first scan or when SPF is missing — that's spf_record_missing.
spf_record_changed	Warning	SPF record content changed from the previous snapshot (suppressed for delegation-sourced records to avoid noise from subdomain probe variance)
spf_recovered	Recovery	Valid SPF record is present again after a missing/invalid event
dmarc_record_missing	Failure	No v=DMARC1 TXT record found at _dmarc.<domain>
dmarc_record_changed	Warning	DMARC record content changed
dmarc_policy_changed	Warning	The p= policy in the DMARC record changed (e.g. none → quarantine)
dmarc_recovered	Recovery	Valid DMARC record is present again after a missing event
dkim_record_missing	Failure	None of the probed selectors returned a DKIM record
dkim_selector_changed	Warning	The set of selectors with valid DKIM records changed
dkim_public_key_issues	Failure	A DKIM record was found but the public key is missing or empty (p=)
dkim_recovered	Recovery	A valid DKIM record is present again after a missing/invalid event
bimi_record_missing	Warning	No v=BIMI1 TXT record found (only fires if BIMI was previously present)
bimi_recovered	Recovery	BIMI record is present again after a 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