Why a sending domain gets stuck on verifying
You added the DNS records, a lookup says they are there, and the sending domain still shows verifying. A sending domain stuck on verifying usually means the records public DNS returns do not yet match the records you were given. Either the change has not finished propagating, or one record differs from the expected value in its type, host name or target. Compare each record against a DNS lookup, correct the one that differs, then give the next check time to run.
The status matters because sending stays blocked until the domain's records are in place and verified. A domain that has been added but not verified leaves the account in a transitional state, set up but not yet able to send. That is the same check that underpins email authentication as a whole: receivers trust mail from a domain only when its published records match the service sending for it.
Timing is the first thing to rule out. One-click DNS setup typically takes up to 40 minutes to propagate, and a new sending domain usually resolves within the hour. A domain that has shown verifying for longer than that, with records that look correct, has a cause worth finding.
Records to compare, and what to check on each
| Record | Type | What to compare |
|---|---|---|
| SPF | TXT | One SPF record at the name, with the include you were given added to it rather than a second record beside it. |
| MX | MX | The host name and the mail server target, on the name you were given, not the root of the domain. |
| Return-path | CNAME | The host name exactly as given, pointing at the target exactly as given. |
| Tracking | CNAME | The host name and target, with no other record sitting at the same name. |
| DKIM (sending subdomain) | CNAME | Entered as a CNAME, not pasted as a TXT value. |
| DKIM (From domain) | CNAME | Entered as a CNAME on the From domain, not pasted as a TXT value. |
Causes to check, in order
- The change is still propagating. Records added in the last hour may not have reached every resolver yet. Nothing is wrong until the domain has had that hour.
- The records were added in the wrong place. The domain's nameservers point at one DNS host while the records were added at another, often the registrar. A lookup against the live nameservers then returns nothing for the new names.
- The host name was doubled. Many DNS hosts add the domain to the host field automatically. Pasting the full name produces a record at a name like
em.example.com.example.com, which no check will find. - The record type is wrong. A DKIM CNAME entered as a TXT record, or a TXT value entered as a CNAME, publishes something at the right name that still does not match.
- The value was changed on the way in. A missing or extra trailing dot on a CNAME target, quote marks around a TXT value, a stray space, or a long value cut short by the form all change what the record says.
- An old record is still at the same name. A domain can publish only one SPF record (RFC 7208, section 3.2), so a second one breaks both. A CNAME cannot share its name with any other record (RFC 1034, section 3.6.2), so a leftover TXT or older CNAME blocks the new one.
- The old value is still cached. When an existing record was edited rather than added, resolvers keep serving the old value until its TTL runs out. A record with a long TTL can look correct at the DNS host and wrong everywhere else.
- The records sit on the wrong level of the domain. Records meant for a sending subdomain added at the root of the domain, or the other way round, publish real values at names the check does not read.
The fix for each cause
Run a DNS lookup first, then apply the fix below that matches the cause it points to. Causes 3, 4 and 5 share one fix.
Start with a DNS lookup
Before changing anything, get the expected records for the domain with nitro_manage_domains, the tool that adds, verifies and authenticates sending domains. The same domain endpoints are available over the REST API at /v1/my/domains and through the Nitrosend CLI. Then look each record up from outside the DNS host, with the commands below in a terminal.
# Which DNS host serves the domain dig +short NS example.com # SPF (TXT) at the name you were given dig +short TXT example.com # MX at the name you were given dig +short MX <full record name> # Return-path, tracking and DKIM (CNAME) dig +short CNAME <full record name>
A record that is correct at the DNS host but missing from the lookup points to propagation, the wrong DNS host or caching. A record that comes back with a different value points to the entry itself.
Still propagating
Wait out the hour. Re-running verify or a DNS check does not speed things up, because the final verification check runs on its own schedule. Repeated calls in the meantime only return the same status. If you edited an existing record rather than adding a new one, the wait is that record's old TTL, as covered under cached values below.
Records at the wrong DNS host
Look up the domain's nameservers with dig +short NS and the domain name. Add the records at the host those nameservers belong to, and remove the copies from the host that is not serving the domain so nobody edits them later by mistake.
Doubled host names, wrong types and changed values
Edit the record at the DNS host so the host field holds only the part before the domain, the type matches the one given, and the value is pasted exactly, with no added quotes or spaces. If the DNS host rejects a CNAME target without a trailing dot, or adds one itself, follow its form. What the lookup returns is the part that has to match.
Old records at the same name
Merge SPF into one record. Keep the mechanisms the domain already uses and add the include for the new sending service to that same record, as the guide to SPF email authentication explains. For CNAMEs, delete whatever else sits at that exact name before adding the new record.
Cached values
Check the TTL on the old record. Lowering it now does not clear resolvers that already hold the old value, so the wait is the old TTL, counted from when the record was changed.
Wrong level of the domain
Compare the full name of each record in the lookup against the full name it was given. Move any record that sits on the root of the domain when it belongs on a subdomain, or the other way round.
Once a record has been corrected and the lookup shows the new value, recheck the domain through nitro_manage_domains so the change is picked up. If every record already matches, wait for the next scheduled check.
What to do next
Send one test message through nitro_send_message to an inbox you control, and check its headers for SPF and DKIM passes on your domain. The guides to how to authenticate an email and email authentication for Outlook cover reading those results.
Verified means the DNS records are valid. It does not mean the domain is cleared to send any volume right away. A new Free account starts at 100 commercial recipients per rolling 24 hours, which rises with sender standing, with 8,000 emails up front, then 500 a month. Plan the first sends around that allowance.
After that, set the DMARC policy that ties the records together. How SPF, DKIM and DMARC fit together sets out the order.
Go deeper
Common questions
One-click DNS setup typically takes up to 40 minutes to propagate, and a new sending domain usually resolves within the hour. Longer than that, with records that look correct, means one record differs from the value given or an old value is still cached.
No. The final verification check runs on its own schedule, so repeated verify or DNS check calls return the same status. A new sending domain usually resolves within the hour, so give it that long first. Recheck after correcting a record, not while waiting for propagation to finish.
No. Sending stays blocked until all six required DNS records resolve and the domain is verified: SPF, MX, return-path, tracking and both DKIM records. A domain that was added but not verified leaves the account in a transitional state that cannot send yet.
The check reads what public DNS returns, not what the DNS host's settings page shows. Records added at a host the nameservers do not point to, host names with the domain added twice, and old values held in cache all look right in the settings and wrong in a lookup. Compare all six records in a lookup, not only the one you last edited.
Hand the check to an agent
Ask your agent in Claude, ChatGPT or Cursor, through the Nitrosend MCP server, to fetch the domain's expected records and status with nitro_manage_domains. Paste in your dig output and it can point to the record that differs, then recheck the domain once the corrected record shows up.