You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cloudflare is still serving version 2 of valiant.biz.email.json five weeks after version 3 was merged to master in #1320 (merged 2026-07-03). New Domain Connect configurations on Cloudflare-hosted domains therefore never receive the record added in v3.
Cloudflare's documentation states template updates are picked up by an automation that compares the version number against the authoritative source, "expected to take no longer than eight hours."
Reproduction
Cloudflare's stored template (checked again today, 2026-08-11):
syncPubKeyDomain TXT records at _dck1.valiant.biz resolve (both p=1 and p=2).
logoUrl resolves (HTTP 200 after a redirect).
Because the automation runs several times daily, a transient fetch failure should have self-corrected long before now.
Possible cause
Cloudflare's setup documentation asks providers for a default proxy status, applied per template, for "A, AAAA, and CNAME records that are part of your templates."
Version 2 of this template contained only TXT, SPFM, and MX records — no proxyable record types at all — so a default proxy status was likely never supplied when the template was onboarded. Version 3 introduces the template's first CNAME record, which may require a proxy-status value that does not currently exist for it.
If that is the cause, the fix presumably needs a Cloudflare-side configuration rather than any change to the template. For the record: this CNAME must be DNS-only (unproxied) — it points at an email provider's tracking host and has to resolve there directly, or certificate issuance and click tracking break.
Request
Could a Cloudflare maintainer confirm which authoritative source URL is registered for providerId: valiant.biz / serviceId: email, and whether automatic updates are enabled for it?
Could the template be re-synced to version 3, with default proxy status set to DNS-only?
We emailed domain-connect@cloudflare.com a week ago and again today; both received only the automated acknowledgement. Filing here as well since Cloudflare maintainers review this repository.
Happy to provide anything further — HAR capture, account ID for testing, or a version bump to force a re-comparison if that would help diagnose.
Summary
Cloudflare is still serving version 2 of
valiant.biz.email.jsonfive weeks after version 3 was merged tomasterin #1320 (merged 2026-07-03). New Domain Connect configurations on Cloudflare-hosted domains therefore never receive the record added in v3.Cloudflare's documentation states template updates are picked up by an automation that compares the version number against the authoritative source, "expected to take no longer than eight hours."
Reproduction
Cloudflare's stored template (checked again today, 2026-08-11):
Authoritative raw source:
What v3 changed
Version 2 → 3 bumped the version and added a single record for email open/click tracking:
{ "groupId": "tracking", "type": "CNAME", "host": "links", "pointsTo": "links1.resend-dns.com", "ttl": 3600 }Checks already performed
Everything on the source side appears healthy, so "source unavailable or technically invalid" does not seem to apply:
"version": 3.master; the repo's filename check, JSON schema validation, and linter all passed, with online editor test links included.syncPubKeyDomainTXT records at_dck1.valiant.bizresolve (bothp=1andp=2).logoUrlresolves (HTTP 200 after a redirect).Possible cause
Cloudflare's setup documentation asks providers for a default proxy status, applied per template, for "A, AAAA, and CNAME records that are part of your templates."
Version 2 of this template contained only TXT, SPFM, and MX records — no proxyable record types at all — so a default proxy status was likely never supplied when the template was onboarded. Version 3 introduces the template's first CNAME record, which may require a proxy-status value that does not currently exist for it.
If that is the cause, the fix presumably needs a Cloudflare-side configuration rather than any change to the template. For the record: this CNAME must be DNS-only (unproxied) — it points at an email provider's tracking host and has to resolve there directly, or certificate issuance and click tracking break.
Request
providerId: valiant.biz/serviceId: email, and whether automatic updates are enabled for it?We emailed
domain-connect@cloudflare.coma week ago and again today; both received only the automated acknowledgement. Filing here as well since Cloudflare maintainers review this repository.Happy to provide anything further — HAR capture, account ID for testing, or a version bump to force a re-comparison if that would help diagnose.