{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/", "item": { "id": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/", "slug": "verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard", "url": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard.md", "json": "https://update.dsesecurity.com/api/v1/posts/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/" }, "title": "Verify a Cloudflare CNAME proof at the authoritative provider, not only in the dashboard", "summary": "Proxying, flattening, or a child delegation can hide the exact alias a third party expects.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:57+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 256, "potentially_affected": "This concerns third-party verification that requires seeing a CNAME answer.", "dse_recommendation": "DSE recommends copying the exact requested owner name and target into the change record before editing.", "primary_source": { "name": "Cloudflare — Cannot verify a domain with CNAME", "url": "https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/cname-domain-verification/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Proxying, flattening, or a child delegation can hide the exact alias a third party expects.

\n

Source facts

\n

Cloudflare lists several causes of failed CNAME domain verification: a proxied record, all-record or per-record flattening, and an NS delegation making another provider authoritative. Its remedy includes keeping the proof DNS-only with flattening off and ensuring the record exists at the nameservers that actually serve the subdomain.

\n

Source: Cloudflare — Cannot verify a domain with CNAME.

\n

Applicability

\n

This concerns third-party verification that requires seeing a CNAME answer.

\n

DSE recommendation

\n

DSE recommends copying the exact requested owner name and target into the change record before editing. Check delegation first, then proxy and flattening settings. Do not remove an NS record casually to make one proof visible; inventory the child services and coordinate any authority change. Preserve existing mail authentication records and verify that a new proof does not collide with another record at the same name. Keep the third party’s requested CNAME value beside the authoritative answer, without substituting an address lookup for the alias check. If the child-zone owner differs, assign the request there before changing proxy settings in the parent. Record provider verification as a separate completion step.

\n

Verification

\n

Query the proof’s authoritative nameservers for the CNAME itself and compare the returned target with the provider’s instructions. Repeat from a representative recursive resolver after cache expiry, then run the provider’s verification. Record the visible alias and authority path rather than treating a saved dashboard row as successful validation.

\n

Official reference

\n

Cloudflare — Cannot verify a domain with CNAME. Reviewed October 20, 2026.

", "content_text": "Proxying, flattening, or a child delegation can hide the exact alias a third party expects.\nSource facts\nCloudflare lists several causes of failed CNAME domain verification: a proxied record, all-record or per-record flattening, and an NS delegation making another provider authoritative. Its remedy includes keeping the proof DNS-only with flattening off and ensuring the record exists at the nameservers that actually serve the subdomain.\nSource: Cloudflare — Cannot verify a domain with CNAME.\nApplicability\nThis concerns third-party verification that requires seeing a CNAME answer.\nDSE recommendation\nDSE recommends copying the exact requested owner name and target into the change record before editing. Check delegation first, then proxy and flattening settings. Do not remove an NS record casually to make one proof visible; inventory the child services and coordinate any authority change. Preserve existing mail authentication records and verify that a new proof does not collide with another record at the same name. Keep the third party’s requested CNAME value beside the authoritative answer, without substituting an address lookup for the alias check. If the child-zone owner differs, assign the request there before changing proxy settings in the parent. Record provider verification as a separate completion step.\nVerification\nQuery the proof’s authoritative nameservers for the CNAME itself and compare the returned target with the provider’s instructions. Repeat from a representative recursive resolver after cache expiry, then run the provider’s verification. Record the visible alias and authority path rather than treating a saved dashboard row as successful validation.\nOfficial reference\nCloudflare — Cannot verify a domain with CNAME. Reviewed October 20, 2026.", "content_markdown": "Proxying, flattening, or a child delegation can hide the exact alias a third party expects.\n\n## Source facts\n\nCloudflare lists several causes of failed CNAME domain verification: a proxied record, all-record or per-record flattening, and an NS delegation making another provider authoritative. Its remedy includes keeping the proof DNS-only with flattening off and ensuring the record exists at the nameservers that actually serve the subdomain.\n\nSource: [Cloudflare — Cannot verify a domain with CNAME](https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/cname-domain-verification/).\n\n## Applicability\n\nThis concerns third-party verification that requires seeing a CNAME answer.\n\n## DSE recommendation\n\nDSE recommends copying the exact requested owner name and target into the change record before editing. Check delegation first, then proxy and flattening settings. Do not remove an NS record casually to make one proof visible; inventory the child services and coordinate any authority change. Preserve existing mail authentication records and verify that a new proof does not collide with another record at the same name. Keep the third party’s requested CNAME value beside the authoritative answer, without substituting an address lookup for the alias check. If the child-zone owner differs, assign the request there before changing proxy settings in the parent. Record provider verification as a separate completion step.\n\n## Verification\n\nQuery the proof’s authoritative nameservers for the CNAME itself and compare the returned target with the provider’s instructions. Repeat from a representative recursive resolver after cache expiry, then run the provider’s verification. Record the visible alias and authority path rather than treating a saved dashboard row as successful validation.\n\n## Official reference\n\n[Cloudflare — Cannot verify a domain with CNAME](https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/cname-domain-verification/). Reviewed October 20, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/", "url": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Verify a Cloudflare CNAME proof at the authoritative provider, not only in the dashboard", "item": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/#article", "identifier": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/", "url": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/", "headline": "Verify a Cloudflare CNAME proof at the authoritative provider, not only in the dashboard", "description": "Proxying, flattening, or a child delegation can hide the exact alias a third party expects.", "abstract": "Proxying, flattening, or a child delegation can hide the exact alias a third party expects.", "articleBody": "Proxying, flattening, or a child delegation can hide the exact alias a third party expects.\nSource facts\nCloudflare lists several causes of failed CNAME domain verification: a proxied record, all-record or per-record flattening, and an NS delegation making another provider authoritative. Its remedy includes keeping the proof DNS-only with flattening off and ensuring the record exists at the nameservers that actually serve the subdomain.\nSource: Cloudflare — Cannot verify a domain with CNAME.\nApplicability\nThis concerns third-party verification that requires seeing a CNAME answer.\nDSE recommendation\nDSE recommends copying the exact requested owner name and target into the change record before editing. Check delegation first, then proxy and flattening settings. Do not remove an NS record casually to make one proof visible; inventory the child services and coordinate any authority change. Preserve existing mail authentication records and verify that a new proof does not collide with another record at the same name. Keep the third party’s requested CNAME value beside the authoritative answer, without substituting an address lookup for the alias check. If the child-zone owner differs, assign the request there before changing proxy settings in the parent. Record provider verification as a separate completion step.\nVerification\nQuery the proof’s authoritative nameservers for the CNAME itself and compare the returned target with the provider’s instructions. Repeat from a representative recursive resolver after cache expiry, then run the provider’s verification. Record the visible alias and authority path rather than treating a saved dashboard row as successful validation.\nOfficial reference\nCloudflare — Cannot verify a domain with CNAME. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:16:57+00:00", "dateModified": "2026-10-20T18:34:36+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Verify a Cloudflare CNAME proof at the authoritative provider, not only in the dashboard" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 256, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Cloudflare — Cannot verify a domain with CNAME", "url": "https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/cname-domain-verification/" } } ] } }