A DKIM key nobody rotated, and a selector that vanished
Selectors are published once and then forgotten. We read yours on every run, measure the key behind each one, and tell you when a record changes or a key gets old enough to be worth replacing
The key behind the selector
Each published selector is fetched and the key parsed, so a 1024-bit key from years ago is named rather than left to be discovered
- RSA key length measured
- Ed25519 recognised
- Weak keys called weak
- Revoked selectors detected
When the record changes
The published record is compared with its previous value on every run, and you see the old and the new together
- Before and after, not just a flag
- Change time recorded
- Email when it breaks the check
- History kept for the domain
Verifying a real signature
Paste a message you actually received and the DKIM signature on it is verified against the published key
- Signature checked against the key
- The selector it used, named
- Works without an account
- Useful when a receiver says it failed
What the DKIM check does
DKIM fails quietly. A wrong key does not bounce mail, it just stops the signature from proving anything, and the loss shows up as a slow drift in delivery
Key strength, as a number
Not just present or absent
RSA keys are measured and graded: below 1024 bits is unusable, below 2048 is weak, 2048 is acceptable and above that is strong. Ed25519 keys are recognised and treated as modern. A selector with a weak key still signs, and still buys you nothing
A selector that stopped answering
The record that quietly went away
A selector removed during a migration leaves every message signed with it unverifiable. The published record is read on every run, so it becoming absent is a change you are told about rather than something you infer later
Age, and a nudge to rotate
At 180, 270 and 365 days
A signing key that has not changed in a year is a key that has had a year of opportunities to leak. You get a reminder as it passes 180 days, again at 270 and again at a year, so rotation happens on a schedule rather than after an incident
Verify a message you were sent
When a receiver says it failed
Paste a real message and its DKIM signature is verified against the key published at that selector. This is the check that settles an argument, because it uses the same inputs the receiver used and gives the same answer
The record as it was before
Old and new, side by side
Every published DKIM record is hashed on each run and compared with the previous value. When one changes you get both versions and the time, which is usually enough to tell a planned rotation from something nobody meant to do
What DMARC does with it
Signing is not the same as aligning
A valid signature from the wrong domain passes DKIM and fails DMARC. The reports show which of your sources sign with a domain that aligns with the From header and which only appear to be fine
What counts as a strong key, and when to replace it
A key is judged on its size and then on its age, and the second one catches far more domains than the first
| Key | Verdict | What it means in practice |
|---|---|---|
| RSA under 1024 | Very weak | Short enough to be treated as broken rather than merely dated |
| RSA under 2048 | Weak | Still verifies today, and is the size most often found on keys nobody has touched in years |
| RSA under 3072 | Fine | The size to publish if you are choosing one now |
| Ed25519 | Modern | Judged on its algorithm rather than a bit count, and short enough to fit a TXT record without splitting |
Age is tracked separately: a notice at 180 days, a warning at 270, and at 365 the reminder stops being polite
Three steps, about ten minutes
Public DNS and, if you want to verify a signature, one message you paste in
Enter the domain and a selector
The record is fetched, the key parsed and measured, and anything wrong with the record itself is named
Check a message that failed
If a receiver reported a DKIM failure, paste that message and the signature is verified against the published key
Leave it watching
On an account the record is read every ten minutes, and you get an email when it changes or when the key passes 180 days
Questions about DKIM
Key length, when to rotate, what happens when a selector disappears, and why a valid signature can still fail DMARC
A selector is a DNS label used to locate the specific public key required for signature verification. It enables multiple services and vendors to sign mail for the same domain independently, preventing configuration conflicts.
Regular rotation limits the impact of potential private key exposure. We recommend rotating keys every 6 to 12 months, and immediately upon vendor changes, personnel turnover, or suspected security compromise.
Yes. We provide full validation for RSA (including 2048-bit and higher) and modern Ed25519 keys. We flag outdated algorithms and weak key sizes to ensure your signing posture remains secure.
Canonicalization determines how much header and body modification is tolerated during transit. Overly strict settings can cause verification failures if intermediate MTAs alter message formatting, directly impacting your DMARC alignment.
No. Your private keys remain securely within your mail servers or ESP. RUA•Watcher only monitors the public keys published in your DNS and tracks their verification health to ensure continuous security.
Specifications this page relies on
- RFC 6376DomainKeys Identified Mail (DKIM) Signatures
Find out how old your signing key is
The key length behind each selector, and how long that key has been sitting there. One domain is free, with no card to enter