Email Routing addresses: ["*@subdomain"] fails with code 2062 despite subdomain being enabled

[catwithlover]

What versions & operating system are you using?

Paths containing my local username have been redacted.

System:
  OS: Linux 6.6 Ubuntu 24.04.2 LTS 24.04.2 LTS (Noble Numbat)
  CPU: (24) x64 AMD Ryzen AI 9 HX 370 w/ Radeon 890M
  Memory: 10.49 GB / 15.18 GB
  Container: Yes
  Shell: 5.2.21 - /bin/bash

Binaries:
  Node: 24.19.0 - /home/<user>/.nvm/versions/node/v24.19.0/bin/node
  npm: 11.17.0 - /home/<user>/.nvm/versions/node/v24.19.0/bin/npm
  pnpm: 11.21.0 - /home/<user>/.local/share/pnpm/bin/pnpm

npmPackages:
  wrangler: ^4.129.0 => 4.129.0

Please provide a link to a minimal reproduction

N/A — this requires an Email Routing-enabled subdomain on a Cloudflare account, so I don't have a self-contained public repository that can reproduce it without account-side setup. The minimal wrangler.jsonc configuration and exact reproduction steps are included in the bug description below.

Describe the Bug

I have an Email Routing subdomain that has already been successfully enabled in the Cloudflare dashboard.

I use agent.asyncat.app below as a redacted stand-in for the actual enabled subdomain.

A literal email address on that subdomain works correctly with Wrangler's addresses configuration:

{
  "addresses": [
    "ai@agent.asyncat.app"
  ]
}

wrangler deploy succeeds with this configuration.

However, changing the same enabled Email Routing subdomain to a catch-all:

{
  "addresses": [
    "*@agent.asyncat.app"
  ]
}

causes wrangler deploy to fail with error code 2062:

✘ [ERROR] A request to the Cloudflare API (/accounts/<account-id>/email/routing/rules/plan) failed.

  Unknown Email Routing domain: No Email Routing domain found for *@agent.asyncat.app [code: 2062]
  Unknown Email Routing domain: No Email Routing domain found for *@agent.asyncat.app

Minimal reproduction

Given an already-enabled Email Routing subdomain such as:

agent.asyncat.app

use a wrangler.jsonc containing:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "<worker-name>",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-03",

  "addresses": [
    "*@agent.asyncat.app"
  ]
}

Then run:

wrangler deploy

Actual behavior

The Worker itself uploads and deploys, but configuring the Email Routing rules subsequently fails:

⛅️ wrangler 4.129.0
────────────────────

Uploaded <worker-name>
Deployed <worker-name> triggers

✘ [ERROR] A request to the Cloudflare API
(/accounts/<account_id>/email/routing/rules/plan) failed.

Unknown Email Routing domain:
No Email Routing domain found for *@agent.asyncat.app [code: 2062]

Unknown Email Routing domain:
No Email Routing domain found for *@agent.asyncat.app

If I replace the catch-all with a literal address on exactly the same enabled Email Routing subdomain:

{
  "addresses": [
    "ai@agent.asyncat.app"
  ]
}

the deployment succeeds.

This appears to confirm that the Email Routing subdomain itself is correctly enabled and recognized. The failure seems specific to catch-all routing.

Dashboard behavior

The Workers dashboard appears to expose the same distinction.

When creating an Email trigger for a specific address, the enabled Email Routing subdomain is available, and I can successfully configure an address such as:

ai@agent.asyncat.app

However, after selecting:

Match every address on the domain

the domain selector only shows apex/zone domains. The enabled Email Routing subdomain is no longer available.

The dashboard also displays:

A domain can have one catch-all rule. It handles mail sent to any address no other rule matches.

This makes me wonder whether Email Routing catch-all rules are intentionally limited to apex/zone domains, while literal routing rules are supported on enabled subdomains.

Expected behavior / clarification requested

The current Wrangler configuration schema describes addresses entries as either literal recipient addresses or *@domain catch-all addresses, with examples such as:

support@asyncat.app
*@asyncat.app

As far as I can tell, the schema does not indicate that the domain in *@domain must specifically be an apex/zone domain, or that an enabled Email Routing subdomain cannot have its own catch-all rule.

Cloudflare's Email Routing documentation also describes enabling Email Routing on subdomains and creating routing rules on those subdomains, so this catch-all-specific distinction is not obvious from the current documentation or Wrangler schema.

Could you clarify which behavior is intended?

If catch-all routing should work on enabled Email Routing subdomains

Then:

{
  "addresses": [
    "*@agent.asyncat.app"
  ]
}

appears to expose a bug in the Email Routing planning/deployment flow.

If catch-all routing is intentionally limited to apex/zone domains

It would be helpful if the Wrangler config schema and Email Routing documentation explicitly documented this restriction.

It may also be useful for Wrangler to validate this case locally and return a clearer error, rather than accepting the configuration and failing later during the /email/routing/rules/plan API call.

Why this was confusing

These two configurations appear equally valid from the current Wrangler schema:

"addresses": ["ai@agent.asyncat.app"]

and:

"addresses": ["*@agent.asyncat.app"]

but only the literal address works.

Since the first configuration succeeds on the same enabled Email Routing subdomain, the failure does not appear to be caused by subdomain onboarding itself.

It appears specific to catch-all routing.

Happy to provide additional logs or test other configurations if useful.

Please provide any relevant error logs

No response

[workers-devprod]

Automated triage

Issue assessment

• Actionability: ✅ Actionable.
• Type: Bug (high confidence).
• Reproduction: Automatic attempt requested.
• Labels:
  • product:email (high)
  • package:wrangler (high)
  • error-messaging (medium)
  • question (medium)

Actionability and missing information

Wrangler 4.129.0 accepts a wildcard catch-all addresses entry on an enabled Email Routing subdomain, but deploy fails at the email/routing/rules/plan API with code 2062, while a literal address on the same subdomain succeeds; whether catch-all on subdomains is intended needs clarification.

Reproduction reason: The report gives exact config and deploy steps showing the catch-all failing with API error 2062 while a literal address succeeds, so the failure is retryable, though it requires an account with an already-enabled Email Routing subdomain.

Missing information:

• minimal reproduction
• expected behavior

Reproduction

• Result: ⚠️ Blocked.
• Summary: Blocked: error 2062 comes from the Cloudflare API (/email/routing/rules/plan) and needs credentials plus account state (Email Routing on a subdomain) absent here. wrangler 4.129.0 accepted the catch-all config locally (dry-run exit 0); deploy aborted at the auth gate before any API call.

Evidence and attempted steps

Steps attempted:

1. Created minimal fixture (wrangler.jsonc with the wildcard catch-all addresses entry for agent.asyncat.app, plus src/index.ts) and installed wrangler 4.129.0 exactly as reported
   • Command: pnpm install && pnpm exec wrangler --version
2. Local validation pass (no API calls): catch-all addresses config accepted with no local error; wrangler builds the worker
   • Command: pnpm exec wrangler deploy --dry-run
3. Ran the reproduction command without credentials; aborted at the authentication gate before any API request, so the /email/routing/rules/plan call was never made
   • Command: CI=true pnpm exec wrangler deploy

Blocker: No Cloudflare account credentials (CLOUDFLARE_API_TOKEN / CLOUDFLARE_ACCOUNT_ID) exist in the sandbox, and credentials may not be requested. The reported error 2062 is returned by the Cloudflare API in the response body of POST /accounts/{account_id}/email/routing/rules/plan, which further requires account-side state — Email Routing enabled on a subdomain — that cannot be created here. wrangler deploy aborts at the authentication gate before any API request, so the plan endpoint could not be exercised.

Artifact: Download reproduction archive (Cloudflare Access required).

Treat archive contents as untrusted. Inspect them before running anything.

---

This summary was generated by an LLM and may contain errors. Please verify its findings.