Email Pipeline

Saga the Watchful — Seneschal

In one breath

Mail arrives at casaconomy.com through Cloudflare and lands in Proton; license keys go out through Resend — two separate flows sharing one DNS zone, no extra providers required.

By the end of this chapter you’ll understand:

• How inbound mail is accepted via Cloudflare Email Routing and forwarded to the regent’s inbox
• How the licensing Worker delivers license keys through Resend’s API
• Why the subdomain split keeps SPF records clean and how SPF, DKIM, and DMARC interlock

What it is

The inbound and outbound email infrastructure for casaconomy.com. Inbound mail arrives via Cloudflare Email Routing and forwards to the regent’s Proton mailbox. Outbound mail (license keys, notifications) is sent through Resend’s API from the licensing Worker.

How it fits

Email is the “bannerstone” — the first external-facing service the keep raised, and the foundation that licensing and future user communication rest on. It sits entirely on the Cloudflare + Resend axis, requiring no additional providers.

Components

Source	Responsibility
.agents/skills/casaconomy-cloudflare/references/zone.md	Canonical DNS + Email Routing state (source of truth)
.agents/skills/casaconomy-cloudflare/scripts/cf	Operator CLI for CF zone: MX records, routing rules, destinations
.agents/skills/casaconomy-resend/references/account.md	Canonical Resend state: domain, tokens, aliases
.agents/skills/casaconomy-resend/scripts/resend	Operator CLI for Resend: send, verify domains, check delivery
workers/licensing/src/lib/email.ts	Production send functions: sendWelcomeEmail(), sendRevocationEmail()
workers/licensing/src/handlers/access_request.ts	Trigger: license issuance calls sendWelcomeEmail()

Data flow

Inbound path

1. External sender delivers to hello@, support@, or licenses@casaconomy.com
2. CF MX records (route{1,2,3}.mx.cloudflare.net, priority 43/48/51) accept delivery
3. CF Email Routing evaluates rules — all addresses plus catch-all forward to casaconomy@proton.me
4. Proton receives and stores. Regent reads on phone or desktop.

Outbound path (license delivery)

DNS authentication records

The domain split isolates inbound and outbound SPF without collision.

Type	Name	Purpose
MX (3 records)	casaconomy.com	CF Email Routing acceptance
TXT (SPF)	casaconomy.com	include:_spf.mx.cloudflare.net ~all — inbound only
TXT (DKIM)	cf2024-1._domainkey.casaconomy.com	CF Email Routing DKIM for forwarded mail
MX	send.casaconomy.com	SES bounce feedback path
TXT (SPF)	send.casaconomy.com	include:amazonses.com ~all — outbound envelope-from
TXT (DKIM)	resend._domainkey.casaconomy.com	Resend DKIM for From-header domain
TXT (DMARC)	_dmarc.casaconomy.com	v=DMARC1; p=none; rua=mailto:hello@casaconomy.com; aspf=s; adkim=s

Why the subdomain split works: SPF checks the envelope-from (send.casaconomy.com), while DKIM and DMARC check the From-header domain (casaconomy.com). Each authentication mechanism validates against the right scope without interference.

DMARC ratchet plan: p=none (monitor) → p=quarantine after 1 clean week of aggregate reports → p=reject after 2 more clean weeks. Aggregate reports arrive at hello@casaconomy.com.

Secrets and tokens

All secrets are machine-local, never committed.

Secret	Scope	Storage
CLOUDFLARE_API_TOKEN	Zone:DNS:Edit, Zone:Email Routing Rules:Edit	~/.paperclip/secrets/cloudflare.env
RESEND_API_TOKEN	Send-only (production code + Worker)	~/.paperclip/secrets/resend.env + wrangler secret
RESEND_ADMIN_TOKEN	Full access (operator tasks, revoked between sessions)	~/.paperclip/secrets/resend.env

Failure modes + recovery

Failure	What happens	Recovery
CF Email Routing destination unverified	Inbound mail silently dropped	Re-verify via cf email destinations; check regent’s Proton spam
Resend API token expired/revoked	Outbound sends fail with 401; Worker returns 500 to caller	Rotate token in Resend dashboard, update wrangler secret put RESEND_API_TOKEN
DKIM key rotation	Old key still valid during overlap; no gap	Resend handles rotation; verify via resend domains records
DMARC reject on legitimate mail	Mail quarantined or rejected by recipient	Check rua aggregate reports; if false positive, relax DMARC back to p=quarantine
SES bounce rate too high	Resend / SES may throttle or suspend sending	Monitor Resend dashboard; clean recipient list

What’s planned to change

• DMARC ratchet — move from p=none to p=reject once aggregate reports show clean alignment (tracked manually, no CAS yet).
• CAS-1093 (sync) — sync notifications may add a second outbound email trigger from sync.casaconomy.com Worker.
• CAS-1100 (licensing tiers) — paid tier emails (receipts, renewal reminders) will add templates to workers/licensing/src/lib/email.ts.

---

See it as

Two post offices sharing one address plate. One office handles arrivals — the postman (Cloudflare) accepts every parcel for casaconomy.com and ferries it to the regent’s private mailbox (Proton). The other handles departures — the keeper (the licensing Worker) hands outgoing letters to a specialist courier (Resend) who signs them and delivers them worldwide. Neither office knows about the other’s parcels. The shared address plate is the domain; the subdomain split is what keeps the two post offices from interfering with each other’s stamps.

Worked example

The outbound sequence diagram above — user submits an access request, Worker generates a license key, Resend delivers it through SES — is the canonical worked example for this chapter. Each authentication record in the DNS table plays a specific role in that delivery: SPF validates the sending server, DKIM signs the message, DMARC tells receiving servers what to do when checks fail.

Recap

• Inbound mail is accepted at Cloudflare’s MX records and forwarded to casaconomy@proton.me — the relay never touches our own servers.
• Outbound license keys travel from the licensing Worker through Resend’s API, signed with DKIM, delivered via SES.
• The subdomain split (casaconomy.com for inbound, send.casaconomy.com for outbound) keeps the two SPF records from colliding, which is what makes DMARC alignment possible.

What changed {#what-changed}

This chapter was introduced in CAS-3637 Phase 3 (The Casaconomy Book) as the canonical reference for the email infrastructure.

See: CHANGELOG → 2026-05-18