ccnames.dev

cnames.dev / for / newsletter and blog platforms

Custom domains for newsletter & blog platforms

Give writers their own domain with automatic SSL — apex + www handled, redirects included, email DNS untouched.

The problem

Writers building an audience want their publication on their own domain — it's their brand and their SEO. A newsletter or blog platform then has to manage certificates and routing for every writer's domain, handle the apex-vs-www question, and set up redirects, all without touching the writer's email configuration.

How it plugs in

One API call per writer domain, mapped to your rendering origin. Apex and www are both supported, and www↔root redirects are configured per domain.

await fetch("https://api.cnames.dev/v1/domains", {
  method: "POST",
  headers: { Authorization: "Bearer sk_live_...", "Content-Type": "application/json" },
  body: JSON.stringify({ domain: "writer.com", origin_id: "org_publish" }),
});

Web and email stay separate

cnames.dev only manages the web routing records, so a writer's existing MX/email DNS is unaffected. If you also help writers with email deliverability, our free DMARC, SPF, and DKIM checkers cover that side.

Why it fits

Add it this afternoon. Register your first customer domain with one API call — free for 25 domains. Start free · Docs · More use cases

Frequently asked questions

Do writers need a subdomain or a root domain?

Both are common — blog.writer.com (subdomain, a simple CNAME) or writer.com at the apex (A records or ALIAS flattening, plus a www↔root redirect). cnames.dev handles either and shows the writer the exact records.

Can I keep my email-sending setup separate?

Yes. cnames.dev manages the web routing records for the domain; your writers keep their MX and email DNS untouched. See our DMARC, SPF and DKIM tools for the email side.

What about redirects from the old subdomain?

Configure per-domain redirects (e.g. old writer.yourapp.com → writer.com) as data, no redeploy.