All posts
4 min read

How to Get a Custom Email Address for Your Domain

[email protected] looks far more trustworthy than [email protected]. The options — Google Workspace, Microsoft 365, Zoho, Proton, Fastmail, and forwarding — how MX, SPF, DKIM, and DMARC records set it up, and how mailboxes differ from sending email from your app.

getting starteddomainsno-codebeginner

You've got yourapp.com. Now you want [email protected] for support, sign-ups, and talking to customers. Setting it up is a one-afternoon job, and it involves the same DNS settings page you used to connect your website. (DNS Records Explained.)

First: two different kinds of "email"

People mix these up, and they're separate systems:

  1. Mailboxes — where people send and receive email: [email protected] in Gmail, Outlook, or another app. That's this article.
  2. App email — emails your app sends automatically: sign-up confirmations, password resets, receipts. That uses a sending service like Resend, Postmark, or Amazon SES. (How to Send Email From Your App Without Landing in Spam.)

You'll often want both, on the same domain. They can coexist — you just have to configure DNS for both carefully.

Your options

A full mailbox provider

You get real mailboxes on your domain, with webmail and apps.

  • Google Workspace — Gmail with your domain. Familiar; includes Google Drive, Calendar, and Meet.
  • Microsoft 365 — Outlook with your domain; includes Office apps.
  • Zoho Mail — often cheaper; has had a free tier for small teams.
  • Proton Mail — privacy-focused, end-to-end encrypted between Proton users.
  • Fastmail — fast, independent, well regarded.

Prices typically run from a few dollars to around $10 per user per month. Check current pricing.

Email forwarding

Many registrars and some services (such as Cloudflare Email Routing and ImprovMX) forward mail sent to [email protected] into your existing inbox, often for free. Great for getting started.

The catch: replying from [email protected] is awkward or needs extra setup, and replies sent through your personal account can land in spam. Fine for receiving; less good for a business you're running.

Aliases

With a full mailbox, you usually get aliases for free: support@, hello@, and billing@ can all deliver to one mailbox. You don't need to pay for a user per address.

Setting it up

Your provider walks you through it, but the steps are the same everywhere:

1. Verify you own the domain

Usually by adding a TXT record the provider gives you:

Type  Name  Value
TXT   @     "provider-verification=abc123…"

2. Add MX records

MX records tell the world where to deliver mail for your domain. Your provider gives you the exact values.

Type  Name  Value                    Priority
MX    @     mx1.provider.example     10
MX    @     mx2.provider.example     20

Remove any old MX records that aren't from your new provider — leftovers from your registrar's default setup can cause mail to go missing.

3. Add SPF

SPF is a TXT record listing which services may send email as your domain. You can only have one SPF record, so if your app also sends email through another service, combine them into one:

TXT  @  "v=spf1 include:_spf.mailboxprovider.example include:sendingservice.example ~all"

Two separate SPF records is a common mistake, and it breaks both.

4. Add DKIM

DKIM adds a cryptographic signature to your emails, proving they weren't forged. Your provider generates a record — usually a TXT or CNAME with a name like google._domainkey. Each sending service has its own DKIM record, and they coexist happily.

5. Add DMARC

DMARC tells receiving servers what to do with mail that fails SPF and DKIM checks, and where to send reports. Start gently:

TXT  _dmarc  "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none just monitors. Once you're confident all your legitimate email passes, tighten it to p=quarantine, then p=reject, to stop others spoofing your domain. Major providers like Gmail and Yahoo now require SPF, DKIM, and DMARC for bulk senders, and a proper setup helps deliverability for everyone.

Test it

  • Send an email to your new address from a different account.
  • Send one from it to a Gmail address, open it, and choose Show original — you want SPF: PASS, DKIM: PASS, and DMARC: PASS.
  • Online tools like mail-tester.com score your setup and flag problems.

DNS changes can take a little while to be visible everywhere. (DNS Records Explained explains TTL and "propagation.")

Common mistakes

  • Deleting MX records while changing web hosting. Website records (A, CNAME) and email records (MX, TXT) are independent. Only change what your web host asked for.
  • Two SPF records. Merge them into one.
  • Forgetting the app's sending service in SPF, DKIM, and DMARC — so password reset emails land in spam.
  • Changing nameservers without copying the email records to the new DNS provider.

EasySpawn only asks you to add the website records it needs when you connect your own domain — your MX, SPF, DKIM, and DMARC records stay exactly as your email provider set them. See how it works or join the waitlist.

Related: How to Send Email From Your App · DNS Records Explained · What Is a Domain Name?

Keep reading