How to monitor your SPF, DKIM, and DMARC records

SPF, DKIM, and DMARC are TXT records sitting at three precise locations in your DNS zone. Monitoring them means watching those three locations and getting an alert when their content changes. The reason this matters: a broken record does not stop your email from going out. Messages still leave your server, they just start landing in spam or getting rejected outright, and you usually find out days later when a customer mentions a missing invoice or your open rates fall off a cliff. This article maps where each record lives, covers the ordinary operations that break them, and shows how to put an alert on all three.

Where SPF, DKIM, and DMARC live in your DNS

Mechanism	DNS location	What the record looks like
SPF	TXT record at the apex (example.com)	v=spf1 include:_spf.google.com ~all
DMARC	TXT record at _dmarc.example.com	v=DMARC1; p=quarantine; rua=mailto:reports@example.com
DKIM	TXT record at <selector>._domainkey.example.com	v=DKIM1; k=rsa; p=MIGfMA0GCSq...

The DKIM selector is chosen by your email provider, not by you. Google Workspace uses google, Microsoft 365 uses selector1 and selector2, and every sending tool (Mailchimp, SendGrid, Brevo) brings its own. A domain that sends through three tools typically has three or more DKIM selectors published, and some providers publish them through CNAME delegation rather than a direct TXT record. If you want a refresher on how TXT records work in general, see DNS record types explained.

How these records break in practice

None of the failure modes below involve an attacker. They are routine operations done by well-meaning people.

The SPF overwrite

A domain is allowed exactly one SPF record. This is the single most common way email authentication breaks: a colleague adds a new CRM or newsletter tool, follows the vendor's setup guide, and pastes the vendor's SPF record into DNS as a new entry or in place of the existing one. Either way, the merge that should have happened didn't, and every other sender on the domain now fails SPF.

The second SPF trap is the 10 DNS lookup limit. Each include: costs lookups, and nested includes count too. Add enough tools and the record exceeds the limit, at which point receivers treat the whole thing as a permanent error even though every entry in it is legitimate.

DKIM key rotation

Email providers rotate signing keys. When they do, an old selector stops validating, or a new selector appears that nobody published in DNS. The variant that stings the most is CNAME cleanup: many providers delegate DKIM through CNAME records pointing into their own zone, and a well-intentioned "remove unused records" pass deletes the delegation. Signing fails from that moment, silently.

The DNS migration that drops TXT records

When a domain moves to a new DNS provider, the visible records travel fine. A, MX, and CNAME records get copied because the website and inbox would break loudly without them. The underscore-prefixed records, _dmarc and everything under _domainkey, are the ones most often left behind, precisely because nothing visibly breaks when they are missing.

What a strict DMARC policy amplifies

DMARC with p=none only observes. With p=quarantine or p=reject, receivers act on failures: your own legitimate email gets junked or refused whenever SPF and DKIM both fail alignment. That is the entire point of the mechanism, since it is what stops phishing emails sent in your name. But it cuts both ways. A hardened policy turns a quiet SPF overwrite into an immediate delivery outage.

Since 2024, Gmail and Yahoo require a DMARC record from bulk senders. If that requirement pushed you to publish one, the safe order of operations is monitoring first, then tightening the policy.

Putting all three under watch with Domain Sentinel

Here is the actual flow with DNS monitoring in Domain Sentinel. Add your domain to the watchlist and enable DNS monitoring. The default checks cover the TXT records at the apex, so your SPF record is watched without further setup. For the other two locations, add the hostnames under Extra names: _dmarc, plus each DKIM selector you use, such as google._domainkey or selector1._domainkey. You get ten extra names per domain, enough for a handful of sending tools.

One honest caveat: Domain Sentinel does not discover DKIM selectors for you. You need to know which selectors your providers use, and the list lives in each provider's authentication settings. Take five minutes to collect them before setting up the watch.

Records are checked once a day. When a watched TXT record changes, you get an email showing the previous and the new value, so an SPF overwrite or a vanished _dmarc record surfaces the next day instead of weeks later. Domain Sentinel detects changes; it does not evaluate whether your SPF syntax or DMARC policy is correct. For that one-time validation, use a dedicated checker, then let monitoring guard the result. How this fits into watching a domain more broadly is covered in what DNS monitoring is.

Check the current state

Before setting up anything, look at what is published right now:

dig TXT example.com
dig TXT _dmarc.example.com
dig TXT google._domainkey.example.com

Swap in your own domain and selectors. No terminal at hand? The DNS lookup tool takes a hostname, so you can read _dmarc and each of your DKIM selectors from the browser.

Three concrete steps for this week: inventory every tool that sends email for your domain and note its DKIM selector, run the three queries above and fix what is missing, then put the three locations under watch. Only after that should you consider moving DMARC from p=none to something stricter.