Email authentication can fail long before anyone notices a delivery-rate change. A scheduled web cron check can inspect SPF, DKIM, and DMARC records, compare them with an approved baseline, and alert when a DNS edit weakens protection or breaks legitimate mail.
What the check should cover
SPF identifies servers allowed to send for a domain. DKIM publishes keys that recipients use to verify signed messages. DMARC connects those signals to a policy and reporting address. Monitor all three because a healthy record in one area does not compensate for a missing or invalid record elsewhere.
Build an explicit inventory
List every domain that sends mail, including marketing, transactional, support, and subdomain traffic. Record the expected SPF mechanisms, DKIM selectors, DMARC policy, alignment mode, percentage, and report destinations. Include providers that manage records on your behalf so an authorized rotation is not mistaken for an incident.
Create a protected validation endpoint
Your endpoint should query TXT records through a trusted resolver, parse the results, follow legitimate SPF include chains, and validate syntax. Return a compact result for each domain and selector:
{
"domain": "example.com",
"spf": "healthy",
"dkim": "healthy",
"dmarc": "healthy",
"warnings": [],
"status": "healthy"
}Return HTTP 200 when the lookup succeeds and required controls match policy. Use a non-2xx response for missing records, duplicate SPF policies, invalid syntax, excessive SPF DNS lookups, missing DKIM keys, or an unexpected DMARC downgrade.
Validate SPF without oversimplifying
- Require exactly one SPF record beginning with
v=spf1.
- Count DNS-triggering mechanisms and warn before the ten-lookup limit is exceeded.
- Detect recursive include loops and unavailable included records.
- Flag an unexpected
+allor policy change from hard fail to soft fail.
- Compare approved sender services rather than requiring a fixed record order.
Monitor DKIM selectors and rotations
DKIM records live below selector-specific names, so the monitor needs an approved selector list. Validate that public keys are present, parseable, and strong enough for your policy. During rotation, allow old and new selectors for a documented overlap window. Alert when an active selector disappears before the sending service has stopped using it.
Watch DMARC policy and reporting
Confirm that the _dmarc record exists and contains one valid policy. Monitor changes to p, sp, pct, alignment modes, and report destinations. A move from reject to none, an unexpected pct reduction, or a removed reporting address deserves immediate review.
Schedule checks at the right cadence
Run every 15 to 60 minutes for important sending domains and after planned DNS changes. Use consecutive-failure logic for resolver timeouts, but alert immediately on a confirmed policy downgrade. Prevent overlapping work using the cron job locking pattern.
Store useful evidence
Keep timestamps, normalized record values, DNS response status, selector name, validation warnings, and a hash of the previous approved state. Redact unnecessary reporting addresses from broad notifications. This history makes it easier to distinguish propagation from an unauthorized change.
Respond to an authentication alert
- Confirm the result through a second resolver.
- Compare the record with the approved change request and provider documentation.
- Check recent domain, DNS, and email-platform access.
- Restore the last known-good policy only after confirming current senders.
- Send a real test message and inspect authentication results.
Pair this check with DNS record change monitoring for broader visibility and domain expiration monitoring for ownership continuity.
Production checklist
- Inventory every sending domain, provider, and DKIM selector.
- Parse records semantically instead of comparing raw text order.
- Detect SPF lookup limits, include loops, and permissive policies.
- Allow documented DKIM rotation overlap.
- Alert immediately on DMARC enforcement downgrades.
A lightweight scheduled validator will not replace delivery analytics, but it catches configuration drift at the source. With an approved baseline and clear alerts, a web cron job can protect email authentication before reputation and inbox placement suffer.