Help & docs · Troubleshooting
Added a record but it won't validate?
The six reasons a freshly added DNS record fails verification, in the order to check them: propagation, mangled names, proxying, SPF duplicates, wrong zone, conflicts.
Last updated 18 July 2026
You added the record your email tool asked for, clicked verify, and it failed. Before assuming the instructions were wrong: in our experience the record is usually there, just not where or how the checker is looking. Work through these in order; they're sorted by how often they turn out to be the answer.
1. It hasn't propagated yet
DNS changes take time to spread. Usually minutes, sometimes hours, occasionally up to 48 for a slow provider or a long-cached old value. If you added the record less than an hour ago, wait before touching anything. Re-checking every five minutes doesn't speed it up, though it does no harm; our free checkers read your live DNS, so a re-run is an honest answer to "is it visible yet?"
2. Your DNS dashboard mangled the name
The classic. Some providers silently append your domain to whatever you type in the host field. You entered k1._domainkey.yourdomain.com, and the record was created at k1._domainkey.yourdomain.com.yourdomain.com: it exists, your dashboard looks right, and no receiver will ever find it. If your provider's host field expects only the part before your domain, enter just k1._domainkey. The same trap exists on the value side; a trailing period on the target value is the usual cure.
3. The record is proxied
Cloudflare users: a CNAME with the orange cloud on answers with Cloudflare's own addresses instead of its real target, and email verification fails. Records for email must be DNS-only (grey cloud). beehiiv setups hit this constantly with their s1/s2 keys.
4. You now have two SPF records
SPF's rule is one record per domain, full stop. If a tool's instructions said "add this include to your SPF" and you pasted it as a new TXT record beside the existing one, every SPF check on your domain now returns a permanent error, for every tool you send with. The fix is merging: one record starting v=spf1, all includes inside it.
5. You're checking the wrong zone
Records live exactly where they were added. If your tool had you set up send.yourdomain.com, the records are on that subdomain, and checking yourdomain.com reports them missing while everything is actually fine. Klaviyo's branded sending domains are the common case. Check the exact name from your tool's settings, subdomain included.
6. Something else already answers at that name
Most DNS providers refuse a CNAME where an A or TXT record already exists at the same hostname, and some refuse silently, keeping the old record. If one specific record stubbornly won't appear, look at what else is defined at exactly that name and clear the conflict.
Still failing after 48 hours?
Then it's likely not propagation, and worth a closer look at the tool side: some providers show "verified" for domain ownership while the authentication records were never added (Brevo's verification code is the well-known example). The ESP-specific checkers test the exact record names each tool uses and show you what your DNS actually answers, which usually settles the question. If it doesn't, we're happy to look: include the domain and the record you added.
Still stuck?
A human reads every message: support@inboxdecay.com. Include your workspace email and the domain in question and you'll usually have an answer within a business day.