Domain verification
Domain verification is proving you control the domain you want to send from. You add the domain, publish the DNS records you are handed, and wait for them to resolve everywhere. Until they do, mail from that domain is unauthenticated and receiving servers treat it as such. Verification is per domain, and it is the first thing to do with a new one.
At a glance
- Category
- Domain authentication
- Proves
- That you control the domain's DNS
- Typically publishes
- A DKIM key, an SPF record and a return path
- Bounded by
- DNS time to live, not by the service
- Rechecked
- Continuously, so a removed record is noticed
How it works
Adding a domain produces a record set that only somebody with access to that domain's DNS can publish: a public key under a selector, a record for the return path, and whatever else the sending path needs. Checks then run repeatedly until every record resolves. Because resolvers cache, the wait is governed by the time to live on the records being replaced rather than by the service. Once everything resolves, the domain is verified and mail from it can be authenticated.
Why it matters
An unverified domain is not merely unfinished, it is actively worse than not sending: the mail goes out unauthenticated, fails DMARC wherever the domain publishes a policy, and starts building the wrong reputation. Verification also has to keep running. A record removed during an unrelated DNS cleanup is invisible until deliverability falls, so a service that rechecks and tells you is the difference between an afternoon of confusion and a week of it.
Example
A team adds example.com, publishes the three records in their DNS provider's panel and waits. The DKIM record appears within minutes because that name had never been looked up before, while the return path record takes an hour because an old value was cached. Verification passes, and mail starts sending from the domain. Two months later somebody prunes the zone and removes the return path record; the recheck fails and the team is told before customers notice.
Common mistakes
- 01Publishing the records at the wrong level, so a panel that appends the domain automatically produces names ending in the domain twice.
- 02Verifying once and never watching, so a later DNS tidy-up silently unauthenticates every message.
- 03Sending production mail from a domain that has not finished verifying, which teaches receiving servers the wrong thing about it.
- 04Publishing the records through a provider that silently rewrites TXT values, so the key that resolves is not the key that was issued.
In Rasket
Checks run on their own until every record resolves, and keep running afterwards, so you hear about it if a record is later changed or removed. Domains
Related terms
Frequently asked questions
Why is my record not being found?
Most often the name is wrong because the DNS panel appended the domain to a value that already contained it. Query the exact name your provider shows and compare it with what the panel actually created.
Do I need to verify every subdomain?
Yes, if you intend to send from it. Authentication records are published per name, so a verified parent domain does not authenticate mail from a subdomain on its own.
Can I send while verification is pending?
You should not. Mail from an unverified domain is unauthenticated, which fails DMARC wherever a policy exists and starts the domain's reputation from a bad position.
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.