DEV Community

kavela
kavela

Posted on • Originally published at newmail.click

How we repurposed a Cloudflare Email Worker domain into a SaaS without taking it down

#webdev #saas #cloudflare #architecture

Last week we did something we'd been putting off for months: we took a domain that was working — newmail.click, a throwaway-inbox utility wired to a Cloudflare Email Worker — and repurposed it into a paid SaaS without unplugging anything.

The result is a domain doing two completely unrelated jobs:

  • Apex (newmail.click) — a Next.js email signature builder with click + open tracking, $19/mo.
  • inbox.newmail.click — the original throwaway-inbox worker, untouched, still serving the PBN bot that depends on it.

Both share one zone, one MX record set, one set of nameservers. Neither knows the other exists. Here is how we got there, and why we'd do it again instead of registering a fresh domain.

The problem

The original newmail.click was a 50-line Cloudflare Worker: catch-all *@newmail.click MX → KV store with a 7-day TTL → a single GET /?to=&token= read endpoint that another bot polled. Total operational surface: one Worker, one KV namespace, one auth token.

It worked. It also did exactly nothing for SEO. The apex was a 404. Google had no reason to index anything. The domain was burning $12/year as glorified plumbing.

Meanwhile we had a half-finished signature builder sitting on a different domain that wasn't going to rank for anything because the name was forgettable. newmail.click is short, memorable, and topically adjacent (email → email signatures). The smart move was to merge them.

The dumb move was the obvious one: kill the inbox worker, point everything at the SaaS. We weren't doing that. The PBN bot uses the inbox worker daily. Migrating it would be a week of work to save fifteen minutes of DNS surgery.

The architecture

The trick is recognizing that email routing and HTTP routing are independent layers on the same domain.

newmail.click           A → hetzner (Next.js SaaS)
www.newmail.click       A → hetzner (Next.js SaaS)
inbox.newmail.click     CNAME → Cloudflare Worker
*@newmail.click         MX → Cloudflare Email Routing → Worker → KV
Enter fullscreen mode Exit fullscreen mode

Cloudflare Email Routing operates on MX records. The Next.js app operates on A records. As long as you don't try to route HTTP for inbox.* to the SaaS, or MX for the apex to anywhere weird, the two stacks are invisible to each other.

The handoff plan in our notes is exactly three DNS changes:

  1. Apex + www A records → hetzner 77.42.127.243
  2. inbox subdomain unchanged
  3. MX records unchanged

That's the entire migration. No worker rewrite, no KV export, no downtime on the inbox side.

The SaaS

The signature builder itself is boring on purpose. Next.js 16, better-sqlite3, NextAuth (Google), Stripe checkout, PM2 process on port 3120. We resisted every urge to put it on a "real" database or a serverless platform. SQLite holds the entire signature catalog, the tracking events, and the user records in one file. When it stops holding them, we'll move it. Probably never.

The tracking layer is the only mildly interesting part. Every link in a generated signature is wrapped with /r/{hash} for click redirects, and we attach a /p/{hash}.png pixel for opens. Hash is a deterministic short ID per (user, link, signature_version) tuple so signatures stay stable across email clients that aggressively cache images.

The pSEO surface is 30 EN profession-specific pages (/freelance-designer-email-signature, /real-estate-agent-email-signature, etc.), each 2,800–3,600 words with sector stats, cold-outreach tactics, 10–12 FAQ blocks and FAQPage JSON-LD. Content fill ran through DeepSeek because Gemini's keys were dead at the time. We'd recommend the same — DeepSeek long-form output handled the 90k-word generation pass for under a dollar.

Why share a domain at all

The temptation when launching anything new is to register a clean domain and avoid the cognitive overhead of multi-purpose DNS. We've done this enough times to recognize the trap:

  • A new domain has zero crawl history. Apex newmail.click had three years of MX-record stability — that's not authority, but it's not nothing either, and Google's spam classifier notices.
  • One zone means one set of DNSSEC keys, one set of CAA records, one Cloudflare account to keep paid. We have eighteen active domains. Every reduction matters.
  • The brand association — "newmail" as an email-adjacent product name — works better with both products coexisting. The throwaway-inbox usage signal feeds the apex's topical relevance.

The cost is a slightly more elaborate runbook ("don't touch the MX records when you migrate the A records"). We can live with that.

What we'd do differently

One thing in retrospect: we should have set up the apex landing on the target server (hetzner) from the start, not on the static-hosting box (contabo) where the placeholder currently sits. The plan calls for a DNS swap at cutover, which means a TLS cert reissue on the new server. If the apex had always been on hetzner, the SaaS could go live by replacing the nginx vhost config — zero DNS propagation wait.

The other thing: we removed the Turkish locale before launch because we wanted the EN signal to be unambiguous for Google. In hindsight this was probably premature; the 30 EN profession pages were going to dominate the keyword distribution regardless. We'll add /tr/* back if the TR market shows demand.

Takeaway

Domains aren't products. They're addresses. A single domain can run a Worker on one MX layer, a Next.js app on its apex, and a pSEO surface on its subpaths simultaneously, and no part of that requires you to delete the others.

If you have a domain that's underperforming as a single-purpose utility, look at what else it could host before you go shopping for a new one. Most of the time the answer is "more than you think."

The signature builder is at newmail.click — free tier is unlimited, Pro adds tracking for $19/mo or $149/yr.

Top comments (0)