Buying a Domain and Setting Up Email for Your Indie App

You've named the app. You've built the first version. You have a Vercel preview URL with a random suffix that looks vaguely like a CAPTCHA, and now you need to put a real domain on it and send a "welcome" email that doesn't land in spam.

Buying a domain for an indie app and wiring up email feels like the boring part of launching, and it is. But it's also the bit where a Saturday afternoon can easily turn into a four-day debugging session if you miss one DNS record. This post walks through the whole thing in the order you'd actually do it, with the records that matter and the ones you can skip.

Pick a registrar (this is less important than you think)

A registrar is the company you buy a domain through. Namecheap, Porkbun, Cloudflare Registrar, GoDaddy, Google Domains (RIP), Hover. The job is the same everywhere: hold the registration, let you point the domain at servers.

Three real choices:

• Cloudflare Registrar. Sells at cost, no markup. Cheapest option for a long-term hold. Slightly clunkier UI. This is what most indie devs end up on once they figure it out.
• Porkbun. Friendly UI, fair pricing, no upsells. The current sweetheart of the indie dev crowd.
• Namecheap. Decent default. Marginally more expensive. Auto-renew defaults to on, which is what you want.

What to avoid: GoDaddy aggressively upsells everything, the prices climb after year one, and the privacy add-on costs extra when most registrars include it free. If you're already on GoDaddy, move when you have a free afternoon.

The actual choice between Cloudflare, Porkbun, and Namecheap matters less than people pretend. Pick one, buy the domain, move on.

What to buy: .com still wins, but it's expensive

The TLD (top-level domain, the bit after the dot) market has fragmented. .app, .dev, .io, .ai, .co are all credible for indie products. But for a consumer product, .com still converts better. Users type .com by default, autocomplete defaults to .com, and people forget the other extensions.

A rough decision rule:

• Consumer app, broad audience: get the .com if it's available, even if you have to change the name. A worse name with .com beats a better name with .app for word-of-mouth.
• Developer tool, technical audience: .dev or .io is fine. Your audience is fluent in TLDs.
• AI-native product: .ai carries a small "this is recent" tax (it's a country code, so it costs more), but it's a credible signal in 2026.

If the .com is taken by a domain squatter, decide whether you can afford the asking price. Most squatter prices are negotiable; start at 20% of their listed number. If they won't budge and you're not sitting on revenue yet, take the next best TLD and move on.

Pay for at least two years up front. One-year domains expire fast, and a missed renewal email can lose you the domain to a squatter who buys it the day it drops.

Point the domain at your app

You bought it. Now point it at the deployed app.

If you're hosting on Vercel, Netlify, Cloudflare Pages, or any modern host, the workflow is: go to the host's dashboard, add the domain to the project, and copy the records they give you. Paste those records into the registrar's DNS panel. Wait between five minutes and a few hours for DNS to propagate. Done.

The two records that matter:

• An A record for the root domain (the bare yourapp.com), pointing at an IP address the host provides.
• A CNAME record for www.yourapp.com, pointing at the host's domain (like cname.vercel-dns.com).

The host will tell you exactly what values to use. Don't guess. If the host says "use a CNAME for the apex," do that; if they say "use an A record," do that. Hosts disagree on the right pattern, and the wrong choice for your host won't work.

After you've added them, hit the host's "verify" button. If it doesn't go green within an hour, the registrar usually has a TTL (time-to-live) setting that's making the records slow to propagate. Cloudflare-as-registrar makes this fast; some others are slow.

Email is the part everyone gets wrong

You can point a domain at a website in ten minutes. Email takes longer because email has spent thirty years inventing anti-spam protocols you now need to implement.

Two separate problems to solve:

• Receiving email at you@yourapp.com so customers can write to you.
• Sending email from your app: signup verification, password reset, billing receipts, the actual lifeblood of any product.

Receiving is the easy half. Sending is where the work is.

Receiving: just use Google Workspace or Fastmail

Don't try to run your own mail server. Don't use the free email forwarding your registrar offers as a primary inbox. Use a real provider.

Two sensible options for an indie founder:

• Google Workspace. $7/user/month. Same Gmail interface you already know. Painless setup with MX records the panel walks you through.
• Fastmail. $5/user/month. Faster, fewer ads, no Google. Less integration with the Google ecosystem if you don't already live there.

Both will give you the MX records (the DNS records that say "email for this domain goes to these servers") to paste into your registrar's DNS panel. After about an hour, mail sent to you@yourapp.com lands in your inbox.

If you're really squeezing pennies, registrar-provided email forwarding to a personal Gmail works for the first month. Move to a real provider before you're depending on it.

Sending: pick a transactional email provider

Your app needs to send mail. Welcome emails, password resets, magic links, billing receipts. Routing that through Gmail is not allowed (Google specifically forbids it for app-generated mail), and even if it were, deliverability would be terrible.

Pick a transactional email provider. The names that come up in indie circles:

• Resend. Indie-friendly, clean API, generous free tier. The current default for most vibe-coded apps.
• Brevo (formerly Sendinblue). Reliable, EU-based (which matters for GDPR comfort), and Draftlytic uses it for its own transactional mail.
• Postmark. Premium feel, premium price, top-tier deliverability.

Set up an account, verify your domain (you'll add DKIM and SPF records, more on these below), and use their API or SDK from your code. More on what to actually send and the wiring in another post.

The DNS records that decide whether your email arrives

This is the part nobody enjoys but everyone needs. Four records, on your domain, in addition to the MX records.

SPF (Sender Policy Framework). A TXT record listing the servers allowed to send mail from your domain. Looks like v=spf1 include:_spf.google.com include:resend.com -all. If you receive on Google and send through Resend, both go in the SPF record. Only one SPF record per domain, ever.

DKIM (DomainKeys Identified Mail). A signature your sending provider attaches to outgoing mail. The provider gives you a CNAME or TXT record to add to your DNS. Paste it as-is.

DMARC (Domain-based Message Authentication, Reporting & Conformance). A TXT record telling receiving servers what to do if SPF or DKIM fail. Start with a permissive policy: v=DMARC1; p=none; rua=mailto:dmarc@yourapp.com. Once you're confident your mail is set up right, tighten to p=quarantine or p=reject.

MX. Already covered above; this is what makes incoming mail work.

Without SPF and DKIM, your "welcome" email lands in spam. Without DMARC, it lands in spam at Gmail specifically (Gmail tightened rules in 2024 and rejects bulk senders without it). Setting these up properly takes maybe 20 minutes once you've done it once, two hours the first time.

Most transactional providers have a "verify domain" flow that walks you through exactly which records to add. Follow it. Don't improvise.

Test before you trust

Once the records are in, test deliverability before you ship. The free tool mail-tester.com (opens in new tab) gives you a temporary address; send a test from your app to it, and they grade your setup. Aim for 9/10 or higher before launch. Anything lower means an SPF, DKIM, or DMARC record is off, and the report will tell you which.

Also test from a real Gmail inbox you own. Send yourself a fake "password reset" from production. If it lands in Promotions or Spam instead of Inbox, fix that before any user sees it. Once Gmail decides your domain is spam-shaped, it takes weeks to recover the reputation.

Capture all of this in the spec

The domain, email provider, and sender-from address are all decisions that affect how the AI tool wires up your auth and notification code. If they're not in the project spec, the AI will either skip email entirely or use placeholder defaults that work locally and break in production.

Pin them in writing before the build. "Send transactional email via Resend from noreply@yourapp.com. Welcome, password reset, magic link, and billing receipt are required." Three sentences. Drop them into the project's external services or notifications section, and Cursor, Lovable, or Bolt will wire it up correctly from prompt one. This is one of the things Draftlytic asks about during project creation, because the "AI quietly skipped email" failure mode is so common.

You won't enjoy the domain-and-DNS afternoon. But you'll enjoy not debugging deliverability the night before launch even less.