A domain not verifying error is frustrating because the record can look correct in a DNS dashboard while the verification service still cannot find or accept it. In nearly every case, the problem is not your REST API integration or SMTP credentials: it is an ownership record, authentication record, DNS delegation issue, or a timing mismatch between what you published and what the verifier expects.

This guide explains how to debug domain verification for any transactional email provider. It covers ownership TXT and CNAME records, SPF, DKIM, DMARC, DNS propagation, subdomains, command-line checks, and the delivery failures that can remain after a domain first becomes verified.

Start by identifying what is actually failing

“Domain verification” is often used to describe several different checks. Treating them as one problem leads to unnecessary DNS changes.

Most email platforms perform at least one of these checks:

Domain ownership verification. You publish a unique TXT or CNAME token to prove that you control a domain or subdomain.
DKIM verification. You publish a public key or provider-managed CNAME at a selector-specific hostname so mail can be cryptographically signed.
SPF authorization. You publish one SPF TXT record that authorizes mail systems to use an envelope-sender domain.
DMARC validation. You publish a DMARC TXT record that tells receiving inboxes how to handle unauthenticated mail claiming to be from the visible From domain.
Custom return-path or tracking-domain verification. You publish CNAME records for a bounce domain, link-tracking domain, or branded sending subdomain.

A provider may show a single unverified status when only one required record is missing. Read the exact record request before editing DNS. If it asks for a host such as send._domainkey.example.com, adding a TXT record at example.com will not help. If it asks for a CNAME, publishing the supplied target as a TXT value will not help either.

Ownership verification and email authentication also have different purposes. A unique ownership token proves control to the service. SPF, DKIM, and DMARC help recipient mail systems evaluate whether a message is authentic. A domain can pass ownership verification and still have poor deliverability if its mail is not properly authenticated.

Check the authoritative DNS provider first

The most common reason for a domain not verifying is editing DNS in the wrong place. Your registrar, hosting company, website CDN, and DNS host may all be different services.

For example, you may have registered example.com with one company but delegated its nameservers to Cloudflare, Route 53, Google Cloud DNS, or another DNS provider. A record added at the registrar’s default zone editor is irrelevant if public resolvers obtain the zone from different authoritative nameservers.

Use these commands from a terminal:

dig NS example.com +short
dig SOA example.com +short
dig TXT example.com +short

The NS query shows the nameservers delegated for the domain. The SOA response usually identifies the authoritative DNS operator and includes zone timing information. Compare the nameservers returned by dig NS with the provider where you made the change.

You can also ask a known public resolver directly:

dig TXT example.com @1.1.1.1 +short
dig TXT example.com @8.8.8.8 +short

If the expected value does not appear through public DNS, do not repeatedly press Verify in the email platform yet. Fix the DNS publication problem first.

Registrar versus DNS host

A domain registrar manages registration and delegation. A DNS host publishes records. They are sometimes the same company, but not always.

A useful triage sequence is:

Find the delegated nameservers with dig NS.
Sign in to the service that operates those nameservers.
Open the zone for the exact domain being verified.
Add or correct the requested record there.
Query the record publicly before retrying verification.

If your organization has separate infrastructure and marketing teams, confirm who owns the authoritative zone. It is common for an engineer to have access to a registrar account but not to the production DNS zone.

Enter the DNS host name exactly as intended

DNS dashboards differ in how they interpret the Name, Host, or Label field. A correct value can become incorrect when the dashboard automatically appends the zone name.

Suppose the domain is example.com and the email provider asks for this DKIM host:

v2026._domainkey.example.com

In a zone editor already managing example.com, the Name field usually needs only:

v2026._domainkey

If you enter the full name into a dashboard that appends the domain automatically, it can publish this invalid hostname instead:

v2026._domainkey.example.com.example.com

The same issue affects verification tokens. If the provider requests:

email-verify.example.com

the correct Name entry may be email-verify, not the full domain. Check the DNS provider’s record preview or inspect the published fully qualified domain name with dig.

Apex records and the @ shortcut

Many DNS interfaces use @, a blank Name field, or the root domain itself to mean the zone apex. For example.com, all of these may represent example.com depending on the interface:

@
blank
example.com

Do not assume the convention. Verify the resulting public record:

dig TXT example.com +short

For a record below the apex, query the full hostname:

dig TXT email-verify.example.com +short
dig TXT v2026._domainkey.example.com +short

The hostname matters as much as the value. A valid token at the wrong hostname is invisible to the verifier.

Use the required record type and value without improvising

A service normally provides a record type, host name, and value. Reproduce all three precisely. Do not convert a CNAME request into a TXT record, remove underscores, add a protocol prefix, or substitute a domain from a different account.

Ownership TXT record example

A generic ownership record might look like this:

Type: TXT
Name: email-verify
Value: provider-domain-verification=4f8b2a91d6c0e7
TTL: 300

Its public DNS representation is:

email-verify.example.com. 300 IN TXT "provider-domain-verification=4f8b2a91d6c0e7"

The token is an example only. Use the exact token generated for your account and domain. Verification tokens are usually unique and may expire or be replaced after a domain is removed and added again.

Ownership CNAME record example

Another provider may request a CNAME:

Type: CNAME
Name: verify-4f8b2a91
Target: verify.provider-validation.example
TTL: 300

The corresponding lookup is:

dig CNAME verify-4f8b2a91.example.com +short

Expected output:

verify.provider-validation.example.

A trailing dot in a zone-file target means the value is fully qualified. Most modern DNS dashboards handle this for you, but some interfaces append the current zone when a target is entered without a trailing dot. When in doubt, compare the public dig CNAME result to the exact target the provider supplied.

TXT quotation marks and long values

Many DNS interfaces display TXT values in quotation marks. Those quotation marks are normally presentation syntax, not text you should manually duplicate inside the value field.

For example, a dashboard may show:

"v=spf1 include:mail.example.net -all"

but the value you enter is commonly:

v=spf1 include:mail.example.net -all

DNS servers can split long TXT data into multiple quoted strings at the protocol level. That is valid when the combined text is identical, but manually inserting spaces or line breaks inside a DKIM public key can corrupt it. Paste DKIM values exactly as provided and let the DNS service handle formatting.

Diagnose TXT records with public lookups

TXT records are used for verification tokens, SPF, DKIM keys, and DMARC policies. Multiple TXT records at the same hostname are permitted, so seeing several results is not inherently an error.

Run a targeted query instead of relying only on the DNS dashboard:

dig TXT email-verify.example.com +short

For a successful ownership check, the output should contain the complete required token. If it returns no answer, investigate the zone, host name, nameservers, and propagation. If it returns a similar but not identical token, delete the stale verification token only after confirming that no other active service still needs it.

Common TXT mistakes include:

Publishing at example.com when the requested host is email-verify.example.com.
Typing the full host into an editor that appends the root domain.
Copying a token from a different environment, workspace, region, or provider account.
Adding invisible whitespace before or after the token.
Breaking a token across records rather than allowing DNS to concatenate properly.
Reusing an old token after the provider generated a new one.
Publishing the record in a private DNS zone that public resolvers cannot access.

Use a second independent lookup tool such as MXToolbox or Google Admin Toolbox when you need a browser-based confirmation. Different resolver locations can expose caching or delegation errors. For direct testing, dig against a public resolver and the authoritative nameserver is more decisive.

Fix CNAME conflicts and flattened aliases

CNAME-based verification fails for a special reason: a hostname with a CNAME cannot normally have other DNS data at the same name. DNS standards specify that a CNAME is an alias, not an additional record type.

That means this is invalid at the same hostname:

verify.example.com. IN CNAME verify.provider-validation.example.
verify.example.com. IN TXT "some-other-value"

It is also invalid to create a CNAME at a host already used for an A record, MX record, or another CNAME. Remove or relocate the conflicting record, then publish the CNAME alone. RFC 2181 explicitly clarifies that a CNAME cannot coexist with other resource-record data at the same owner name. (rfc-editor.org)

Do not proxy verification CNAMEs

Some DNS and CDN products offer proxying, masking, flattening, or traffic-routing options for CNAME records. Those features can be useful for web traffic but can interfere with a verification service that expects to resolve the literal CNAME target.

For a provider-issued verification, DKIM, return-path, or tracking CNAME, choose ordinary DNS-only resolution unless the email provider explicitly documents otherwise. Then query it publicly:

dig CNAME verify-4f8b2a91.example.com +short
dig CNAME v2026._domainkey.example.com +short

If a lookup returns an IP address rather than the requested canonical target, a proxy or flattening behavior may be involved. Disable it for that email-related hostname and allow the target to resolve normally.

Verify DKIM separately from ownership

DKIM is not merely a checkbox. It lets the sender sign a message and lets the receiver retrieve a public key from DNS to verify that signature. The record location depends on both the signing domain and a selector.

A typical DKIM TXT record is published at:

selector._domainkey.example.com

For example:

Type: TXT
Name: mail2026._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

The public lookup is:

dig TXT mail2026._domainkey.example.com +short

Many transactional email platforms instead provide DKIM through CNAME delegation, such as:

Type: CNAME
Name: s1._domainkey
Target: s1.domainkey.provider-mail.example

Both patterns are normal. The provider’s requested record is authoritative for that integration. DKIM uses the selector from the s= tag and domain from the d= tag in the message’s DKIM-Signature header to locate the relevant DNS key. (datatracker.ietf.org)

DKIM failures after DNS looks correct

If a DNS checker finds the record but the provider still reports DKIM as pending or invalid, compare these details:

The full selector hostname is correct, including _domainkey.
The CNAME target or TXT public key exactly matches the current provider request.
The domain in the provider setup is the same domain or subdomain represented by the record.
No old record with the same selector is conflicting with the intended key.
The provider has finished polling DNS; some platforms do not recheck immediately.
DNSSEC is correctly signed if your zone uses it. A broken DNSSEC chain can cause resolvers to return SERVFAIL even when the record appears in a control panel.

After verification succeeds, send a real test message and inspect the delivered headers. Gmail’s Show original view and mail-tester.com can report whether DKIM actually passed. A published key alone does not prove the provider is signing your messages with the expected domain.

Consolidate SPF instead of adding another SPF record

SPF authorizes infrastructure to send mail for the domain used in the SMTP envelope sender, also called the Return-Path or MAIL FROM domain. It is stored as a TXT record and begins with v=spf1.

A simple example is:

v=spf1 include:spf.transactional-provider.example -all

If you also send from a business mailbox provider, help desk, CRM, or marketing platform, you still need one SPF policy at the same hostname—not one record per vendor. For example:

v=spf1 include:_spf.google.com include:spf.transactional-provider.example include:spf.helpdesk.example -all

Do not publish this:

v=spf1 include:_spf.google.com -all
v=spf1 include:spf.transactional-provider.example -all

Multiple SPF policy records can cause an SPF permanent error because receivers cannot reliably choose between them. SPF evaluation also has a limit of ten DNS-querying terms, including mechanisms such as include, a, mx, exists, and redirect. (datatracker.ietf.org)

SPF is often not the ownership-verification blocker

A provider may allow a domain to be verified while showing SPF as recommended, incomplete, or not applicable. Other providers require SPF before production sending. Keep the distinction clear:

A missing ownership token blocks proof of domain control.
A missing DKIM record may block authenticated sending.
A broken SPF record can hurt authentication or DMARC alignment.
An SPF record for the root domain may not authorize a separate custom bounce subdomain.

Use the domain the provider asks you to authorize. If it recommends a custom envelope sender such as bounce.example.com, the SPF record may belong on that subdomain rather than at the root.

Add DMARC carefully, then test alignment

DMARC uses the visible From domain and checks whether SPF or DKIM passes with an aligned domain. The policy is published as a TXT record at _dmarc.

A conservative monitoring record is:

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

That resolves as:

dig TXT _dmarc.example.com +short

DMARC is not usually required to prove ownership to an email API provider, but it is essential to a complete sending-domain setup. Gmail requires all senders to have SPF or DKIM, while bulk senders must set up SPF, DKIM, and DMARC; Google defines bulk sending as roughly 5,000 or more messages to personal Gmail accounts in a 24-hour period. (support.google.com)

Start with p=none while you observe reports and verify every legitimate sender. Move to p=quarantine or p=reject only after you understand which systems send mail for the domain and whether each stream aligns.

Alignment catches a subtle but common issue

Consider this message:

From: receipts@example.com
Return-Path: bounce@mailer-provider.example
DKIM d=mailer-provider.example

SPF may pass for mailer-provider.example, and DKIM may pass for mailer-provider.example, but neither identifier aligns with example.com. DMARC can therefore fail.

A properly configured transactional provider normally solves this by signing with your domain or a related subdomain, and by configuring a custom return-path domain where appropriate. Test the final delivered message rather than assuming that a green DNS status guarantees alignment.

Wait for DNS correctly, not indefinitely

DNS propagation is real, but “wait 48 hours” is not a diagnosis. Most changes become visible quickly when published in the correct authoritative zone, while resolver caches can continue serving older answers until the previous TTL expires.

Before making a record change, choose a reasonable TTL such as 300 seconds when your DNS provider allows it. This does not instantly erase values already cached under the old TTL, but it makes future updates faster to observe. After the record is stable, you can raise the TTL if desired.

Use this progression:

Query the authoritative nameserver if you know it.
Query public resolvers such as 1.1.1.1 and 8.8.8.8.
Confirm the exact record type, full hostname, and value.
Retry the provider’s verification check after public DNS is correct.
Avoid deleting and recreating records repeatedly unless the published result is wrong.

Repeated changes can reset expectations, create stale records, or make it harder to tell which value the verifier is seeing. If authoritative DNS returns the exact requested record but verification remains pending after a reasonable provider polling interval, contact support with the fully qualified hostname, record type, expected value or target, dig output, and the time you published it.

Separate verification errors from sending errors

A verified domain does not make every message deliverable. Once your REST email API or SMTP relay accepts mail, the next failure can occur during provider validation or recipient delivery.

HTTP APIs commonly use status codes such as 400 Bad Request, 401 Unauthorized, 403 Forbidden, 422 Unprocessable Content, or 429 Too Many Requests, but the exact code and JSON error schema are provider-specific. Read the response body and request ID rather than assuming every 403 means the same thing. It may indicate an unverified sender identity, account restriction, invalid From address, or an authorization scope problem.

SMTP relays can return a response during submission, or the message can be accepted and later bounce. A generic policy-related bounce may include:

550 5.7.1 Delivery not authorized, message refused

The enhanced status code 5.7.1 is broad: it means the sender is not authorized to deliver to the destination and may result from per-host or per-recipient policy filtering. It does not by itself prove that domain verification failed. (datatracker.ietf.org)

Look for the full diagnostic text. It may identify DMARC rejection, SPF failure, missing reverse DNS, an IP reputation issue, relay authentication failure, recipient policy, or content filtering. Treat an SMTP bounce as delivery evidence, not as a substitute for checking DNS.

A practical domain verification checklist

Before escalating a domain not verifying problem, complete this checklist from top to bottom:

Confirm the exact domain being verified: example.com and mail.example.com are different DNS names.
Identify whether the requested record is TXT or CNAME.
Confirm that you edited the authoritative DNS zone, not merely the registrar’s unused zone.
Check that the record Name does not duplicate the root domain.
Copy the provider-issued value or target exactly, with no added spaces or altered punctuation.
Ensure a CNAME hostname has no TXT, A, MX, or competing CNAME record.
Disable DNS proxying or flattening for email-verification and DKIM CNAMEs unless explicitly supported.
Query public DNS with dig before retrying verification.
Verify DKIM, SPF, and DMARC as separate requirements rather than treating one green status as proof that all authentication works.
Send a real message and inspect headers after DNS verification succeeds.

For implementation-specific field names, required records, and SMTP or REST sending examples, consult the platform’s email API reference and setup guides. The correct provider-issued values always override generic examples in this article.

Prevent repeat verification problems

Domain verification becomes easier when DNS changes are treated as infrastructure changes rather than one-off dashboard edits.

Keep a record of every email-related hostname, its purpose, its owner, and the service that depends on it. Include ownership tokens, DKIM selectors, SPF policy sources, DMARC reporting addresses, custom return-path domains, and tracking domains. A simple repository-managed DNS configuration or runbook reduces accidental deletion during website, CDN, or registrar migrations.

Use separate sending subdomains when practical. For example, notify.example.com for transactional mail and news.example.com for campaigns can isolate reputation and make ownership clearer. The visible From address can still be designed around your product, but each subdomain should have an intentional authentication configuration.

Before changing a provider, exporting a DNS zone, or enabling a new CDN, inventory the current records. DKIM CNAMEs and verification tokens are easy to overlook because they do not affect the website. Deleting them can silently break future signing, bounce handling, or platform access.

FAQ

Why is my TXT record visible in DNS but my domain is still not verifying?

First confirm that the visible TXT record is at the exact hostname and has the exact token requested by the provider. Then check whether the service expects TXT rather than CNAME, whether it has generated a newer token, and whether it polls DNS on a schedule. If public dig output matches the provider request, give the service a short interval to recheck and then contact support with that evidence.

Can I have multiple TXT records on one domain?

Yes. A domain can publish multiple TXT records, such as one for SPF, one for Google verification, and another for a separate service. The important exception is SPF: publish one SPF policy beginning with v=spf1 per hostname and combine authorized services into that policy.

Why does my DKIM record say pending when SPF is valid?

SPF and DKIM are independent. SPF usually lives at an envelope-sender domain, while DKIM uses a selector-specific host such as selector._domainkey.example.com. Check the selector, record type, CNAME target or public key, and public DNS result for that exact DKIM hostname.

Does a verified domain guarantee inbox placement?

No. Verification proves control, and authentication helps establish legitimacy, but inbox placement also depends on message content, recipient engagement, complaint rates, sending patterns, IP and domain reputation, and recipient-server policy. Test authentication with delivered message headers and monitor bounces after sending begins.

Should I remove the verification record after the domain is approved?

Usually no. Keep ownership, DKIM, custom return-path, and tracking records unless the provider explicitly says they are temporary. Removing a record can break revalidation, signing, bounce processing, or a future account review. Document the record before changing it.

Domain Not Verifying? A Developer’s DNS Troubleshooting Guide