What these alerts mean
Every change Watchtower emails you about is listed here, with what it does to mail you send and the one thing to do about it. Alerts link straight to their entry, so you can go from the email to the explanation in one click.
A note on how we decide: an alert only goes out when we are confident the change is real. If a DNS lookup doesn't answer, we skip that check rather than record your record as missing — and before we ever tell you something disappeared, a second, independent DNS provider has to agree that it did.
Fix now
Mail you send is being blocked, refused or spoofable right now.
DMARC record removed
What this means for your mail. DMARC is the record that tells Gmail, Outlook and everyone else what to do with mail that fails authentication in your name. With it gone, that instruction is gone: spoofed mail claiming to be you is no longer rejected or quarantined anywhere. You also stop receiving DMARC reports, so you lose the only view you had of who is sending as your domain.
What to do. Re-publish the _dmarc TXT record. If you didn't remove it, treat it as a DNS access question — find out who did.
DMARC policy downgraded
What this means for your mail. Your policy is the enforcement level receivers apply to mail that fails authentication as you. Moving down the scale (reject → quarantine → none) means more of that mail gets delivered instead of blocked. At p=none nothing is enforced at all — DMARC is only watching, not protecting.
What to do. If this was a deliberate step back while fixing a sender, put a date on moving it forward again. If it wasn't deliberate, restore the previous policy.
SPF record removed
What this means for your mail. SPF is the list of servers allowed to send as your domain. With no record, receivers have no way to authorise mail by the server it came from — so unless DKIM signs every single message you send, mail now fails DMARC. If your DMARC policy is at quarantine or reject, failing mail is sent to spam or refused outright rather than delivered.
What to do. Re-publish the SPF TXT record. If you didn't remove it, check who has access to your DNS.
SPF over the lookup limit
What this means for your mail. The standard allows an SPF record to trigger at most 10 DNS lookups while it is being evaluated; yours now needs more. Receivers stop evaluating and return a permanent error, which counts as a failure — so SPF fails for every message you send, no matter which server it came from. This usually happens without anyone touching your record: a provider you include added an include of their own.
What to do. Get back under 10 lookups — drop providers you no longer send through, or flatten the worst include. This is not something you can wait out.
DKIM key removed
What this means for your mail. DKIM is the cryptographic signature on your mail; the key that verifies it lives in DNS. With the key gone, every message already signed with it now fails verification. If mail from that source relied on DKIM to pass DMARC, it now fails DMARC too, and your policy decides whether it is spammed or refused.
What to do. Restore the key at that selector, or stop signing with it. Note we only watch selectors your own DMARC reports show you actually signing with — so this is a key that was in live use.
New blocklist listing
What this means for your mail. A blocklist is a list of senders that receiving mail servers refuse or distrust, and it's one of the most common silent causes of a delivery drop — the rejection happens at the far end, so you often get no bounce naming the list. Listings affect reputation rather than authentication: your SPF, DKIM and DMARC can all be perfect and mail can still be refused.
What to do. Open your dashboard to see which address is listed and use that list's removal form. Fix the cause first — a delisting without one usually re-lists.
Worth a look
Nothing is broken today, but this is how breakage starts.
DMARC enforcement sampled down
What this means for your mail. A pct below 100 tells receivers to apply your policy to only that share of failing mail and deliver the rest normally. Enforcement is now partial, so spoofed mail gets through in proportion to what you left unenforced.
What to do. Raise pct back to 100 once the sender you were protecting is fixed. Note the newer DMARC standard (RFC 9989) retires pct in favour of a t= testing flag, so plan to move off it.
SPF close to the lookup limit
What this means for your mail. Nothing is broken today. But you're near the 10-lookup ceiling, and the next lookup can be added by any provider in your chain without telling you — at which point SPF fails for all of your mail at once.
What to do. Trim the record now while it's cheap, rather than after a provider tips it over.
SPF pointing at names that don't resolve
What this means for your mail. Parts of your SPF record reference hostnames that no longer exist — usually a provider you stopped using. The standard allows two of these; past that, evaluation can fail permanently, which fails SPF for all your mail.
What to do. Remove the mechanisms pointing at dead hostnames.
SPF 'all' qualifier weakened
What this means for your mail. The qualifier at the end of your SPF record says what receivers should do about servers NOT on your list. Weakening it tells them to be more forgiving of unlisted senders — and at +all, you are telling the entire internet that every server on it is authorised to send as you, which makes SPF worthless and hands spoofers a pass.
What to do. Set it back to -all, or ~all if you're still discovering legitimate senders.
DKIM key revoked
What this means for your mail. The record is still there but its key is empty, which is the standard way of announcing a key has been retired. That is exactly right if you rotated it deliberately, and a live problem if anything is still signing with that selector — those signatures cannot be verified.
What to do. If the rotation was yours, nothing to do. If it wasn't, find out who published it.
DKIM key weakened
What this means for your mail. The new key is shorter than the one it replaced. Short RSA keys are cheaper to break, which is why the standard sets 1024 bits as the floor and asks for 2048 or more; some receivers ignore signatures below the floor entirely, which costs you the DKIM pass.
What to do. Re-issue the key at 2048 bits or more.
DKIM key in testing mode
What this means for your mail. The t=y flag tells receivers to treat your signatures as an experiment and ignore it when one fails. Nothing breaks today, but DKIM is giving you no real protection while it's set — which matters if it was left on by accident after a rollout.
What to do. Remove t=y from the selector's record once you've finished testing.
MTA-STS policy removed
What this means for your mail. This one is about mail coming TO you, not mail you send — it's why it doesn't affect your sending score. MTA-STS is how you tell other servers to insist on an encrypted connection when delivering to you. Without it, a server that can't negotiate TLS will quietly deliver in the clear instead of refusing.
What to do. Re-publish the _mta-sts record and its policy file if the removal wasn't deliberate.
For your records
A change we noticed. Expected if you made it.
DKIM key rotated
What this means for your mail. The key at this selector changed. Routine key rotation is good hygiene and we're only telling you so an unexpected one doesn't go unnoticed.
What to do. Nothing — this one needs no action from you.
Improvement
Your posture got better. No action needed.
DMARC record published
What this means for your mail. Receivers now have a published instruction for mail that fails authentication in your name, and you can start collecting DMARC reports on who is sending as you. How much protection that buys depends on the policy named above: p=reject and p=quarantine are enforced by receivers, while p=none only watches and blocks nothing.
What to do. Nothing — this one needs no action from you.
SPF record published
What this means for your mail. Receivers can now authorise your mail by the server it was sent from, which is one of the two ways a message can pass DMARC.
What to do. Nothing — this one needs no action from you.
MTA-STS policy published
What this means for your mail. You're now advertising that mail delivered to you should require an encrypted connection. This protects inbound mail and doesn't change how your outbound mail is treated.
What to do. Nothing — this one needs no action from you.
Monitoring is read-only — we never change your DNS. Monitor a domain →