Domain Verification Record Not Found: Why Google, Microsoft, or Cloudflare Cannot Verify Your Domain

Quick answer: why verification records are not found

If Google, Microsoft, Cloudflare, or another provider cannot verify your domain, check these first:

Before changing the value repeatedly, confirm whether the verification record is visible at the authoritative DNS host.

If you want the broader email DNS order before editing anything, start with the email DNS checker guide.

What domain verification means

Domain verification is how a service confirms that you control a domain.

A platform may require verification before it lets you use a custom email domain, activate Google Workspace or Microsoft 365, add a domain to Cloudflare, use a custom sending domain, set up DKIM, use a branded tracking domain, connect a website domain, verify a business account, or issue SSL certificates for a custom hostname.

The provider usually proves control by asking you to add a unique DNS record.

If you can add that record to the live DNS zone, you likely control the domain.

Common domain verification record types

Verification can use several methods.

For email and DNS setup, TXT and CNAME are the most common.

Verification is not the same as email setup

Verifying a domain proves ownership. It does not automatically finish email setup.

After domain verification, you may still need MX records, mailboxes or aliases, SPF, DKIM, DMARC, autodiscover for Microsoft 365, email routing rules, or third-party sender authentication.

For example, you may add a Google verification TXT record successfully and Google verifies the domain, but email still does not receive messages because MX records still control where incoming email is delivered.

Read the MX Record Checker guide if incoming email does not arrive, and use the business email setup checklist for the full launch sequence.

Step 1: confirm active nameservers

This is the first and most important check. Nameservers tell the internet which DNS provider is authoritative for the domain.

In that setup, Cloudflare controls live DNS. If Google gives you a TXT verification record, you must add it in Cloudflare, not Namecheap, because Cloudflare is the active DNS host.

A common mistake is buying the domain at Namecheap, adding the verification TXT record in Namecheap, and then missing that the nameservers point to Cloudflare.

Result: Namecheap shows the record, public DNS does not show the record, and Google or Microsoft cannot verify the domain.

Step 2: identify the exact domain being verified

Providers may ask you to verify a root domain or a specific subdomain.

example.com
www.example.com
mail.example.com
app.example.com

If you add a verification record for example.com, it may not verify app.example.com unless the provider treats root-domain ownership as sufficient. Always follow the provider's exact instruction.

Step 3: use the exact verification value from the provider

Verification values are unique. Do not copy values from a blog post, another domain, another Google Workspace account, another Microsoft 365 tenant, another Cloudflare zone, a previous setup, or a screenshot for a different domain.

Example Google-style value:

google-site-verification=example_token_here

Example Microsoft-style value:

MS=ms12345678

These are examples only. Your real value must come from the provider's admin panel.

• No missing characters
• No extra spaces
• No extra line breaks
• No missing prefix such as MS=
• No smart quotes
• No copied label text
• No old token from a previous setup
• No token from another domain

A one-character mismatch can cause verification to fail.

Step 4: understand the Name or Host field

The Name or Host field tells DNS where the record lives.

For root-domain verification, many providers use one of these values:

@
blank
example.com

If the provider says leave blank or enter @, do that. Do not enter www unless the provider specifically says to verify www.example.com.

Step 5: avoid the full-domain-twice mistake

Many DNS dashboards automatically append the domain name.

For example, if your DNS zone is example.com, the safer Name field for google._domainkey.example.com may be google._domainkey, depending on the dashboard.

Example mistake:

Wanted: _dmarc.example.com
Entered: _dmarc.example.com
Possible published result: _dmarc.example.com.example.com

That record will not verify because it is in the wrong place.

After adding any record, check the final published hostname. Do not rely only on what you typed.

This matters for verification records, DKIM selectors, DMARC, and branded sending domains.

Step 6: add TXT verification records correctly

TXT records are commonly used for domain verification.

Example root TXT verification:

• A domain can usually have multiple TXT records.
• Do not delete SPF or DMARC just to add a verification TXT.
• Do not create duplicate SPF records while adding verification records.
• Do not add the verification token into your SPF record.
• Let the DNS dashboard handle quotes unless it instructs otherwise.
• Copy the full value exactly.

Wrong:

v=spf1 include:_spf.google.com google-site-verification=example_token ~all

Correct:

TXT @ v=spf1 include:_spf.google.com ~all
TXT @ google-site-verification=example_token

SPF and verification are separate TXT records. The SPF Record Checker guide explains why duplicate SPF records are different from multiple TXT records.

Step 7: add CNAME verification records correctly

Some providers use CNAME records for verification.

Example CNAME verification:

Do not proxy verification CNAMEs through Cloudflare unless the provider specifically says to.

• CNAME is proxied.
• CNAME is flattened.
• CNAME target has a typo.
• CNAME was added at the wrong DNS host.
• CNAME name is wrong.
• Full domain was entered twice.
• Another DNS record already exists at the same name.
• NS record delegates that subdomain elsewhere.

If the provider cannot find your CNAME, check whether the public DNS answer shows the target exactly as expected.

Step 8: watch for CNAME conflicts

A CNAME record usually cannot coexist with other record types at the same name.

verify.example.com CNAME provider.example
verify.example.com TXT another-token

app.example.com CNAME provider.example
app.example.com A 192.0.2.10

Some DNS dashboards reject this. Others may show confusing behavior.

If a provider requires a CNAME at a hostname that already has other records, do not delete records blindly.

• Is that hostname already serving a website?
• Is it already used by another provider?
• Can the provider verify with TXT instead?
• Can you use a different hostname?
• Is the old record still needed?
• Will changing it break a live service?

Choose the verification method that does not disrupt existing services.

Step 9: check if Cloudflare proxy or flattening is hiding the CNAME

In Cloudflare, CNAME verification records should usually be DNS-only.

If the record is proxied, the outside provider may not see the CNAME target it expects.

Provider expects: verify.example.com CNAME verify.provider.com
Public result when proxied: expected CNAME target may be hidden

For verification CNAMEs:

• Set proxy status to DNS-only.
• Avoid flattening if the provider needs to see the CNAME.
• Confirm the public CNAME answer matches the provider's expected target.
• Check whether an NS record delegates that subdomain elsewhere.

This matters for website platforms, SaaS custom hostnames, email platforms, and branded tracking domains.

If you are setting up Cloudflare with email providers, the Google Workspace Cloudflare DNS guide and Microsoft 365 Cloudflare DNS guide cover the larger email setup context.

Step 10: check for delegated subdomains

Sometimes a subdomain is delegated to another DNS provider using NS records.

app.example.com NS ns1.otherprovider.com
app.example.com NS ns2.otherprovider.com

If app.example.com is delegated, records for that subdomain may need to be added at the delegated DNS provider, not the root domain's DNS provider.

Check whether NS records exist for the subdomain. If yes, identify which provider is authoritative for that subdomain.

Step 11: understand propagation and cache

After adding a verification record, it may not be visible everywhere instantly.

DNS resolvers cache answers based on TTL. There can also be negative caching, where a previous record not found answer is cached temporarily.

1. Provider checks for TXT record.
2. Record does not exist yet.
3. Not found result is cached.
4. You add the TXT record.
5. Provider still says not found for a while.

If authoritative DNS is correct, wait and retry provider verification. Do not delete and recreate the record every few minutes, and do not change the token unless the provider gives a new one.

Read the Email DNS Propagation guide if records still look wrong after updating DNS.

Step 12: check authoritative DNS, not only your dashboard

Your DNS dashboard shows what you saved. Authoritative DNS shows what the live DNS host is actually publishing. These are not always the same.

If authoritative DNS does not show the record, the provider cannot verify it. If authoritative DNS shows the correct record but the provider still fails, the issue may be cache, provider delay, or an exact-match problem.

Step 13: Google Workspace verification record not found

Google Workspace commonly verifies domain ownership with a TXT record. The verification value comes from Google Admin and may look like:

google-site-verification=...

Use the exact value Google gives you.

• You are signed in to the correct Google Admin account.
• You are verifying the correct domain.
• The TXT record was added at the active DNS host.
• The Name/Host is blank, @, or exactly what Google instructs.
• The value is copied completely.
• No extra spaces or missing characters exist.
• The record is visible in public DNS.
• You clicked Verify again in Google Admin.
• You waited for DNS propagation if needed.

Common mistake: adding the verification TXT record at the registrar while DNS is managed by Cloudflare. Add the TXT record at the active DNS host instead.

Step 14: Microsoft 365 verification record not found

Microsoft 365 commonly verifies a custom domain with a TXT record. The value often looks like:

MS=ms12345678

This is only an example. Use the exact value from Microsoft 365 admin center.

• Domain was added in Microsoft 365.
• You copied the current TXT verification value.
• The value includes the full MS=ms... text.
• Record was added at the active DNS host.
• Name/Host is correct, often @ for root-domain verification.
• The TXT record is visible in authoritative DNS.
• You clicked verify again in Microsoft 365.
• Enough time has passed for DNS/provider checks.

Microsoft may offer an MX-based verification method in some flows. Only use that if Microsoft specifically instructs you to. Do not replace your real mail-routing MX record with a verification MX unless you understand the effect.

Step 15: Cloudflare verification record not found

Cloudflare-related verification can happen in different situations, including adding a zone, partial/CNAME setup, custom hostname validation, Cloudflare for SaaS, certificate/domain control validation, Email Routing, or service-specific setup checks.

Cloudflare may ask for a TXT record, CNAME record, or HTTP validation depending on the product.

• You are using the correct Cloudflare account.
• You are working in the correct zone.
• The verification record was added at authoritative DNS.
• The Name and Value match exactly.
• If using CNAME verification, the record is DNS-only.
• CNAME flattening is not hiding the expected target.
• No NS record delegates the hostname elsewhere.
• The hostname points where Cloudflare expects if required.
• Enough time has passed for Cloudflare to recheck.

Common issue: a CNAME verification record is proxied, so the external verification system cannot see the CNAME target it expects. Set the CNAME to DNS-only and retry verification.

Step 16: domain verification for email platforms

Email marketing, CRM, and transactional platforms often require domain verification. Examples include Mailchimp, HubSpot, Klaviyo, SendGrid, Mailgun, Postmark, Brevo, Amazon SES, Shopify, Stripe, helpdesk platforms, and booking platforms.

They may ask for:

• TXT verification record
• DKIM CNAME records
• DKIM TXT records
• Custom return-path CNAME
• Branded tracking CNAME
• DMARC record
• SPF include

Verification records and authentication records are related but not always the same. A platform may first verify ownership, then require DKIM or return-path records for sending.

Make sure every required record is added, not just the first verification TXT. For third-party sending and spam placement, use the Email Going to Spam guide.

Step 17: domain verification for website platforms

Website platforms may require DNS verification when connecting a custom domain.

Examples include Vercel, Netlify, Shopify, Wix, Squarespace, Webflow, WordPress hosting, and custom SaaS platforms.

They may ask for an A record, CNAME record, TXT verification, CAA check, SSL validation, or nameserver change.

Website verification and email verification are separate. A website platform verifying www.example.com does not automatically mean Google Workspace or Microsoft 365 can use example.com for email.

Do not delete email DNS records while fixing website verification. If the site works but email verification or delivery fails, use the Website Works but Email Does Not guide.

Step 18: multiple TXT records are usually okay

A domain can have multiple TXT records for different purposes.

TXT @ google-site-verification=...
TXT @ MS=ms...
TXT @ v=spf1 include:_spf.google.com ~all
TXT _dmarc v=DMARC1; p=none;

Multiple TXT records are okay. Multiple SPF records at the same hostname are not okay.

Wrong:

TXT @ v=spf1 include:_spf.google.com ~all
TXT @ v=spf1 include:spf.protection.outlook.com -all

Correct if both providers genuinely send:

TXT @ v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Do not delete verification TXT records just because SPF also uses TXT.

Step 19: do not put verification records inside SPF or DMARC

Verification records should usually be separate DNS records.

Wrong:

v=spf1 include:_spf.google.com google-site-verification=abc123 ~all

v=DMARC1; p=none; MS=ms12345678

Correct:

TXT @ v=spf1 include:_spf.google.com ~all
TXT @ google-site-verification=abc123
TXT @ MS=ms12345678
TXT _dmarc v=DMARC1; p=none;

SPF, DMARC, and verification tokens have different formats and should not be merged together.

Use the DMARC Record Checker guide if DMARC is missing or invalid, the DKIM Record Checker guide if provider-generated DKIM records are not found, and the SPF vs DKIM vs DMARC guide if you need the plain-English difference between ownership verification and email authentication.

Step 20: check whether the record was added to www by mistake

This is a very common mistake. The provider asks you to verify example.com, but the TXT record is added under www.example.com.

Result: the provider cannot verify the root domain.

Only use www if the provider specifically asks you to verify www.example.com.

Step 21: check whether the provider expects root or subdomain

Some platforms verify the root domain. Others verify a specific subdomain.

The host/name field must match the provider's expected hostname. Do not simplify it unless you know how your DNS dashboard appends the domain.

Step 22: check for old verification records

Old verification records usually do not break anything, but they can clutter DNS and confuse troubleshooting.

google-site-verification=old-token
MS=old-ms-token
facebook-domain-verification=old-token

Before deleting old records, ask:

• Is the service still used?
• Does the provider still need the record?
• Was the domain verified long ago?
• Will removing it break access, sending, tracking, or SSL validation?
• Is it linked to another account?

Do not delete old verification records blindly. Document them so you know what each one is for.

Step 23: check if verification record can be removed later

Some providers only need the record during initial verification. Others recommend keeping it.

• Check the provider's documentation.
• Confirm the domain remains verified.
• Confirm no recurring validation depends on it.
• Confirm SSL or sending validation does not rely on it.
• Keep a screenshot or note of what it was for.

For email authentication records such as SPF, DKIM, and DMARC, do not remove them after verification. They are ongoing email authentication records, not one-time verification records.

Step 24: verification failed after nameserver change

If domain verification worked before but failed after changing nameservers, the new DNS host may not contain the verification record.

Before: Namecheap DNS contains Google verification TXT
After: Cloudflare nameservers active

If the verification TXT was not copied into Cloudflare, Google may no longer find it.

When changing nameservers, copy all important DNS records: website A/AAAA/CNAME, MX, SPF, DKIM, DMARC, verification TXT/CNAME, autodiscover CNAME, and provider-specific records.

Nameserver changes can break verification, email, and website setup if records are missing in the new DNS zone.

Step 25: verification failed after website migration

Website migrations often focus on website records and forget email or verification records.

A developer may move the website to Vercel or Netlify and keep A and CNAME records, but remove or forget TXT verification, MX, SPF, DKIM, and DMARC.

Result: the website works, but email provider setup fails, domain verification fails, and email authentication breaks.

Compare the old DNS zone and new DNS zone. Restore required verification and email records.

Step 26: verification failed because of wrong account

Sometimes the DNS record is correct, but the provider account is wrong.

• You are logged into the wrong Google Admin account.
• You are verifying the domain in the wrong Microsoft 365 tenant.
• The domain was already added to another tenant.
• You are using the wrong Cloudflare account.
• The domain is inside another workspace or project.
• A previous agency or developer controls the account.
• The provider generated a new token, but DNS still has the old token.

Check the correct provider account, project, workspace, tenant, domain spelling, current verification token, whether the domain is already claimed elsewhere, and whether admin access is complete.

This is not a DNS propagation issue. It is an account ownership/setup issue.

Step 27: verification failed because of domain spelling

Check the exact domain.

If the domain was typed incorrectly in the provider, the verification record may be correct for the wrong domain.

Step 28: verification failed because DNSSEC is broken

DNSSEC is not the most common cause, but it can break DNS resolution if misconfigured.

• Some resolvers cannot find your records.
• DNS works in one place but fails in another.
• Provider cannot verify even though records look correct.
• Domain recently changed DNS hosts.
• DS records at the registrar do not match the DNS provider.

If DNSSEC is enabled and DNS results are inconsistent, check DS records at the registrar, DNSSEC status at the DNS host, whether nameservers recently changed, and whether DNSSEC was disabled at one provider while DS records remain at the registrar.

If you are not using DNSSEC intentionally, get help before changing it, because incorrect DNSSEC changes can affect the whole domain.

Step 29: use a safe troubleshooting workflow

Use this workflow when a provider says verification failed:

1. Identify the exact domain or subdomain being verified.
2. Copy the current verification record from the provider.
3. Confirm active nameservers.
4. Add the record at the active DNS host.
5. Use the correct record type.
6. Use the correct Name/Host field.
7. Use the exact Content/Value field.
8. Keep CNAME verification records DNS-only if using Cloudflare.
9. Check authoritative DNS.
10. Wait for propagation if authoritative DNS is correct.
11. Return to the provider and click Verify again.
12. Check for wrong account or wrong tenant if it still fails.
13. Do not make random DNS changes while waiting.

This sequence separates real DNS errors from propagation and provider delays.

Common verification scenarios

What not to do

• Do not keep changing the verification token randomly.
• Do not add the record at the registrar if DNS is managed elsewhere.
• Do not put verification tokens inside SPF or DMARC records.
• Do not delete SPF, DKIM, DMARC, or MX records to add verification TXT.
• Do not add verification to www unless instructed.
• Do not proxy CNAME verification records unless the provider says to.
• Do not delete existing CNAME/A records without checking what they do.
• Do not assume a working website means verification DNS is correct.
• Do not assume propagation will fix a wrong hostname or wrong value.
• Do not ignore wrong account or wrong tenant possibilities.
• Do not remove verification records unless you know they are no longer needed.
• Do not change nameservers without copying all required DNS records.

Final checklist: fix verification record not found

Use this checklist:

• Correct domain is being verified.
• Correct provider account is used.
• Current verification token is copied.
• Active nameservers are confirmed.
• DNS is edited at the active DNS host.
• Record type matches provider instruction.
• Name/Host field is exact.
• Value/Content field is exact.
• Full domain was not entered twice.
• TXT record is separate from SPF and DMARC.
• CNAME record is DNS-only if required.
• CNAME flattening is not hiding the expected target.
• No conflicting record blocks the CNAME.
• No NS record delegates the hostname elsewhere.
• Authoritative DNS shows the record.
• Provider verification has been retried.
• Enough time has passed for propagation/provider refresh.
• Wrong account, tenant, or project has been ruled out.

If authoritative DNS does not show the verification record, fix DNS. If authoritative DNS shows the exact record, wait briefly and retry verification before changing more records.

Run a domain verification DNS check

Use Domain Email Doctor to scan your domain's public DNS records before changing more settings.

A scan can help show whether nameservers point to the expected DNS host, whether TXT records are visible, whether MX records are present, and whether email DNS records such as SPF, DKIM, and DMARC may also need attention.

Start by confirming the record is published in the right place. Most verification failures are not mysterious: they are wrong DNS host, wrong name, wrong value, proxy/flattening, or propagation delay.

If verification is part of a forwarding setup, the Email Forwarding Not Working guide can help you separate ownership verification from routing and mailbox checks.