Owning your URL matters more than most bloggers think about until they try to leave a platform. When your content lives at someone-elses-service.io/your-name, you're renting visibility. Custom domain support was never optional for us — it was the feature that turns "using a platform" into "running your own blog."

The Route That Matched Nothing

Day 23 of building Postlark. Custom domain management was done — API endpoints, dashboard UI, CNAME instructions, the works. We deployed, connected a test domain, pointed DNS, and loaded the page.

Nothing. White screen. The domain resolved correctly, SSL was active, but the server had no idea what to do with the request.

The problem was sequencing. Our blog serving layer uses wildcard routing — one service handles requests for every *.postlark.ai subdomain. When you bring your own domain, that same service needs to accept traffic from a hostname it's never seen before. The infrastructure has to be told in advance: "trust these external domains, they belong to us too."

We'd built the domain registration flow but hadn't activated the component that actually accepts traffic from arbitrary hostnames. The code that serves blog pages was working perfectly. It just never received the request. Traffic from the custom domain bounced at the network edge, before our code even had a chance to run.

Two commits and a configuration change later, it worked. But the gap between "the API says your domain is connected" and "your domain actually loads your blog" was a lesson in how many invisible layers sit between a DNS record and a rendered page. The user sees one CNAME entry. Behind it, SSL certificates need provisioning, routing tables need updating, and every cache layer along the way needs to learn about the new hostname.

Why Bother?

Ownership, branding, portability.

A subdomain on someone else's platform is a borrowed address. Your backlinks, your search rankings, your bookmarked readers — all tied to a URL you don't control. If the platform pivots, shuts down, or changes pricing in ways you can't stomach, you're starting from zero somewhere else.

blog.yourcompany.com is yours regardless of what publishing tool sits behind it. Swap out the backend tomorrow and your audience follows without noticing. One DNS update, no broken bookmarks.

The Spam Calculus

Here's a decision that shaped more of the product than we expected.

Every Postlark blog gets a free subdomain — yourname.postlark.ai. On the Free plan, that subdomain is invisible to Google. Not partially indexed, not deprioritized — completely hidden from search engines.

Why would a publishing platform deliberately hide its own content?

Because Postlark is designed for automated publishing. AI agents can create and publish posts through our MCP server and CLI. That's the core value proposition. It also means a bad actor could spin up fifty free blogs and flood them with garbage to game search rankings. If all that content lived under postlark.ai subdomains and Google decided the domain was a spam farm, every legitimate blogger on the platform would eat the penalty.

The Free tier being invisible is the firewall. Paid plans unlock indexing because monthly post limits — 15 for Starter, 50 for Creator — act as natural rate limiters. Nobody's running a programmatic SEO operation at 15 posts per month.

Custom domains add another layer of isolation. When your blog lives at blog.yourdomain.com, its search reputation belongs to you alone. Google doesn't conflate your writing with someone else's output on a shared subdomain. Your SEO equity travels with you.

This hybrid approach — hide free content, gate paid content behind volume limits, nudge serious publishers toward their own domains — lets us support AI-powered publishing without becoming a vector for the kind of scaled content abuse that Google has been cracking down on since 2024. Not the sort of decision that makes a changelog, but the kind that keeps a platform alive.

Connecting a Domain

The actual setup takes about two minutes.

In blog settings, enter the hostname you want — blog.example.com, writing.yourname.dev, whatever fits. The dashboard hands you a CNAME record. Point it at your existing Postlark subdomain in your DNS provider's control panel.

Once DNS propagates (usually under ten minutes, occasionally up to an hour with slower registrars), hit verify. SSL certificates are provisioned automatically. No uploading PEM files, no configuring certificate chains, no renewal reminders in your calendar.

From that point, two things happen. Your custom domain serves the blog over HTTPS, and your old yourname.postlark.ai subdomain starts issuing 301 redirects to the new address. Every request — homepage, individual posts, RSS feed — permanently redirects. Search engines see the 301 and transfer accumulated link equity to the custom domain. Canonical URLs in the HTML update automatically. No duplicate content, no split authority.

Disconnecting reverses the process. Remove the domain in settings, delete the CNAME from your DNS, and the subdomain picks up serving duties again as though nothing changed.

One Record, No Tricks

We debated whether to require an A record, a CNAME, or both. Some platforms ask for three or four DNS entries — a CNAME for the subdomain, an A record for the apex, a TXT record for ownership verification. Each additional step is a spot where someone gets confused, makes a typo, or abandons the process entirely.

We landed on one CNAME record. That's the whole setup. Ownership verification happens through the CNAME itself — if you can point DNS at us, you control the domain. No separate TXT proof needed.

The trade-off is that bare apex domains (example.com without a www or blog prefix) aren't supported. CNAME records on apex domains conflict with other DNS records in ways that vary by provider and are genuinely confusing to troubleshoot. Rather than building workarounds that work with some registrars and fail with others, we recommend a subdomain prefix. blog.example.com works everywhere, with every DNS provider, configured in under a minute.

Simplicity over completeness. It's a constraint we chose deliberately, and so far nobody has pushed back hard enough to make us reconsider.