A selector monitor can tell you that verification data changed or disappeared. It cannot establish that a service is still sending, that its private key matches the published key, or that its messages arrive with aligned DKIM. Build separate checks for published configuration and observed message behavior.
Start with known sending routes
Create an inventory from authorized sender configuration and representative received messages. For each route record the business owner, d domain, selector, DNS owner, expected TXT or CNAME arrangement, last observed signing time and lifecycle state. Do not assume that guessing common selectors discovers every signer. DKIM supplies the selector in each signature rather than defining a complete DNS enumeration service.
For a signature using s=invoice2 and d=brand.example, inspect invoice2._domainkey.brand.example under RFC 6376 §3.6.2.1. Follow an expected CNAME to its verification data. Store an observation timestamp and a public-key fingerprint so a change can be compared with an approved rotation. Never collect private keys into the monitoring system.
Separate the monitor's findings
A missing answer, DNS timeout, revoked key and changed key are different events. RFC 6376 §6.1.2 distinguishes key-query failure from an absent key, and an empty p value represents revocation under RFC 6376 §3.6.1. Record response details rather than translating every error into a generic outage.
A present key still needs syntax and algorithm checks. RFC 8301 §3.1 prohibits rsa-sha1 signing and verification; RFC 8301 §3.2 updates RSA size requirements: signers must use at least 1024 bits and should use at least 2048. Product support and current organizational cryptographic policy may be stricter. A fingerprint change alone cannot tell you whether a rotation was authorized.
Add a live evidence loop
Send controlled messages through each important production route to a mailbox whose raw message and trusted authentication result you can inspect. Record the observed d and s, verification outcome and alignment with From. Exercise the message variants that downstream processing could affect, such as HTML and attachments.
Illustrative monitor: DNS continues serving invoice2, but a fresh message contains no DKIM-Signature. The publication check passes while the signing check fails. In another case, the signature exists but its body hash fails after a gateway footer change. Neither incident is resolved by declaring the DNS record healthy. These are synthetic test cases, not measured service incidents.
Synthetic tests also have limits. A daily probe does not prove every message between probes passed. Combine it with receiver reports and incident evidence, while acknowledging reporting coverage and delay.
Route actionable alerts
Attach alerts to a route and owner. Suppress only an explicitly approved maintenance window, preserve the event history and confirm the new signer with fresh mail after rotation. Escalate unexpected key changes as possible security events without declaring compromise from a change alone.
Retire stale inventory rows deliberately. An old public key may remain for delayed-message verification even when new signing has stopped. Distinguish that planned state from an abandoned delegation. The dashboard should say what was observed, when and by which method, so DNS health never masquerades as proof of live signing.
Reproduce the alert decision
Use four synthetic probes to keep the alert layers separate. A signature with d=brand.example and s=invoice2 maps to invoice2._domainkey.brand.example. If its public key is present but the supplied receiver outcome is a body-hash failure, raise a message-verification alert. If its key is absent, raise a key-absence alert. If the expected record is present but the message has no signature, raise a missing-signing alert. A present key plus a supplied passing result yields no alert for that probe alone.
These four decisions are an illustrative decision model with invented DNS states and supplied receiver results. No live DNS query, signing test or cryptographic verification was performed for this review. To commission the monitor, replace them with dated public answers and raw messages carrying results from your trusted receiving boundary. Preserve that linked evidence before describing a route as operationally verified.
Evidence needed for the next decision
For a body-hash alert, preserve the supplied result and investigate body representation, c/l settings, bh value and implementation behavior; a mismatch alone does not prove a gateway modified content. Mark a route with no fresh probe as unobserved, even if its key is present. Record separately whether alignment was checked, since DKIM pass alone is not aligned pass.