Skip to content

Cloudflare still serving v2 of valiant.biz.email five weeks after v3 merged (#1320) #1570

Description

@dennis-autosend

Summary

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):

$ curl -s https://api.cloudflare.com/client/v4/dns/domainconnect/v2/domainTemplates/providers/valiant.biz/services/email
{"version":2}

Authoritative raw source:

$ curl -s https://raw.githubusercontent.com/Domain-Connect/Templates/master/valiant.biz.email.json | grep version
  "version": 3,

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:

  • Raw source returns HTTP 200, is valid JSON, and reports "version": 3.
  • Update valiant.biz.email (v3): add open/click tracking CNAME #1320 merged to master; the repo's filename check, JSON schema validation, and linter all passed, with online editor test links included.
  • 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

  1. 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?
  2. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions