How to Set Up Email for a Custom Domain (Step by Step)

Using an email address like you@yourcompany.com instead of you@gmail.com provides:

• Professional credibility: Customers trust emails from a business domain more than free email addresses.
• Brand consistency: Every email reinforces your brand name.
• Control: You own the address and can create addresses for employees, departments (support@, sales@), and functions.
• Security: Business email providers offer admin controls, data retention policies, and compliance features.
• Portability: If you switch email providers, you keep your addresses — you just update DNS records.

Setting up custom domain email requires three things: a registered domain name, a DNS provider where you can modify records, and an email hosting service.

Google Workspace (Gmail): Starts at $7.20/user/month. Full Gmail interface with your custom domain, plus Google Drive, Docs, Calendar, and Meet. The most popular choice for businesses. Excellent spam filtering and 99.9% uptime SLA.

Microsoft 365 (Outlook): Starts at $6/user/month. Outlook with your custom domain, plus OneDrive, Word, Excel, PowerPoint, and Teams. Best if your team already uses Microsoft tools.

Zoho Mail: Free tier for up to 5 users (5GB each). Paid plans start at $1/user/month. A solid budget option with a clean interface and good privacy practices.

Fastmail: Starts at $5/user/month. Privacy-focused, no ads, no data mining. Great for privacy-conscious users and small teams.

Self-hosted (Mailcow, Mail-in-a-Box): Free software, but requires a server and ongoing maintenance. Only recommended if you have sysadmin expertise and specific compliance requirements that prevent using third-party hosting.

Step 1: Sign up for Google Workspace at workspace.google.com. Enter your domain name during signup.

Step 2: Verify domain ownership. Google provides a TXT record to add to your DNS. Log into your domain's DNS provider and add the verification TXT record. Google will check for it within a few minutes.

Step 3: Configure MX records. Remove any existing MX records and add Google's MX records:

Use LookMyIP's MX Checker to verify the records are correct after saving.

Step 4: Set up SPF. Add a TXT record: v=spf1 include:_spf.google.com ~all

Step 5: Set up DKIM. In the Google Workspace admin console, go to Apps > Google Workspace > Gmail > Authenticate email. Generate the DKIM key and add the provided TXT record to your DNS.

Step 6: Set up DMARC. Add a TXT record for _dmarc.yourdomain.com: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Step 7: Create user accounts in the Google Workspace admin console and start sending email.

After completing the setup, verify everything works:

1. Check MX records: Use LookMyIP's MX Checker (lookmyip.com/mx) to confirm your MX records point to the correct mail servers.
2. Check DNS records: Use LookMyIP's DNS Lookup (lookmyip.com/dns) to verify your SPF, DKIM, and DMARC TXT records.
3. Check DNS propagation: Use LookMyIP's DNS Propagation Checker (lookmyip.com/propagation) to confirm the MX records have propagated globally.
4. Send a test email: Send an email from your new address to a personal Gmail account. In Gmail, click "Show original" to check that SPF, DKIM, and DMARC all show PASS.
5. Receive a test email: Send an email to your new address from an external account to confirm incoming mail works.

DNS changes can take up to 48 hours to propagate, but most changes are visible within 1–2 hours.

Emails not arriving: MX records haven't propagated yet, or they're pointing to the wrong server. Check with LookMyIP's DNS Propagation tool.

Emails going to spam: Missing SPF, DKIM, or DMARC records. Use DNS Lookup to verify all authentication records are in place.

Cannot send email: Check that your email client is configured with the correct SMTP server, port (587 for TLS), and authentication credentials.

Old MX records still active: If you previously used a different email provider, make sure to remove their MX records. Having duplicate MX records from different providers can cause emails to be delivered unpredictably.

SPF "too many lookups" error: If you have multiple services (email provider + marketing tool + transactional email), you may exceed SPF's 10 DNS lookup limit. Use SPF flattening tools or consolidate sending services.

Moving an existing mailbox to a new provider is where most custom-domain setups go wrong. A cutover done in the wrong order loses mail permanently, and nothing recovers it.

Two weeks before. Inventory everything that sends mail as your domain — the website contact form, the invoicing system, the CRM, the monitoring alerts. Each will need reconfiguring, and each is easy to forget until it silently stops working.

One week before. Create every mailbox and alias on the new provider and verify each one can send and receive using the provider's own test domain. Do not touch your MX records yet.

Three days before. Lower the TTL on your MX records to 300 seconds. Change nothing else, and wait out the original TTL so the reduction takes effect everywhere.

Two days before. Migrate historical mail with IMAP sync while the old server is still receiving. Most providers include a migration tool; imapsync is the reliable general-purpose option:

imapsync --host1 imap.old-provider.example --user1 you@example.com \
         --host2 imap.new-provider.example --user2 you@example.com

Run it once now to move the bulk, and again after cutover to catch anything that arrived in between. It is idempotent, so re-running is safe.

Cutover. Change the MX records. Because the TTL is 300 seconds, senders converge within minutes.

For 72 hours afterwards, leave the old mailbox running and forwarding. Some senders cache DNS beyond the TTL, and this is the window where mail is silently lost if the old server is decommissioned early. Check the old mailbox daily.

One week later. Run imapsync a final time, verify nothing new has arrived at the old provider, then cancel. Raise the MX TTL back to 3600.

The single most common failure is deleting the old mailbox on cutover day. Keeping it for a week costs one month's subscription and prevents an unrecoverable loss.

A properly configured mail domain needs more than MX records. Here is the full set, with what each one does.

; Mail routing
example.com.        IN  MX    1 smtp.google.com.

; SPF — who may send as this domain
example.com.        IN  TXT   "v=spf1 include:_spf.google.com ~all"

; DKIM — public key for signature verification
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

; DMARC — what to do when SPF and DKIM fail
_dmarc.example.com. IN  TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

; MTA-STS — require TLS for inbound mail
_mta-sts.example.com. IN TXT  "v=STSv1; id=20260802000000"
mta-sts.example.com.  IN CNAME mta-sts.provider.example.

; TLS reporting — get told when TLS negotiation fails
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

; Autodiscover — client auto-configuration
_autodiscover._tcp.example.com. IN SRV 0 0 443 autodiscover.provider.example.

Three of these are commonly skipped and worth adding.

MTA-STS (RFC 8461) tells sending servers that mail to your domain must use TLS with a valid certificate, closing the downgrade attack that plain opportunistic TLS permits. It requires both the TXT record above and an HTTPS-hosted policy file at https://mta-sts.example.com/.well-known/mta-sts.txt. Most managed providers host it for you.

TLS-RPT gives you daily reports when a sender could not negotiate TLS with your servers — the only way you find out about a certificate problem on your inbound mail path before users do.

Null MX on domains you never use. If you own a domain purely defensively, publish 0 . as its MX and v=spf1 -all as its SPF, with p=reject DMARC. Parked domains are heavily targeted for spoofing precisely because nobody bothers.

Verify the whole set with the email authentication checker and the MX checker once the records have propagated.

Small decisions about addressing have consequences that show up years later.

Do not enable a catch-all. Accepting mail for every possible address at your domain sounds convenient and is a spam magnet: spammers send to dictionary-generated addresses, all of which you now accept, and your mailbox fills with mail addressed to names that have never existed. It also removes the useful signal of a bounce telling a sender they got the address wrong. Use explicit aliases instead.

Use plus addressing for tracking. Most providers support you+shopping@example.com, delivering to you@example.com while preserving the tag. Signing up to each service with a distinct tag means that when spam arrives at you+somecompany@example.com, you know exactly who leaked or sold the address. Note that some sign-up forms reject the plus character, and a determined spammer can strip the tag.

Publish role addresses. abuse@ and postmaster@ are expected by RFC 2142 and are where other operators will contact you about a problem originating from your domain. security@ is where researchers will report vulnerabilities. All three should reach a human. An organisation with no working abuse address gets its problems escalated to its hosting provider instead.

Think about the naming scheme before creating the first account. firstname@ is friendly but collides the moment you hire a second person with the same first name, and renaming an address in use is disruptive. firstname.lastname@ scales but is verbose. Whatever you choose, apply it consistently and add aliases rather than changing primary addresses later.

Keep a personal alias separate from a role alias. ajay@example.com and support@example.com reaching the same mailbox is fine, but sending as the role address for support work means the conversation survives that person leaving.

Set up a shared mailbox rather than forwarding, for anything a team handles. Forwarding breaks SPF for the forwarded message and gives no shared view of what has been answered.

Can I use custom domain email for free?

Options exist but they are constrained. Zoho Mail has a free tier for a single domain with limited users and no IMAP on the free plan. Some registrars bundle basic forwarding, which lets you *receive* at your domain while sending from elsewhere — though sending from a different provider than your SPF record permits will fail authentication. Google Workspace and Microsoft 365 no longer have free tiers. For a business address, the $6–7 per user per month is generally worth it over the time cost of working around free-tier limits.

Do I need to keep my old email address?

Keep it for at least a year, forwarding to the new one. Account recovery, two-factor fallbacks and dormant subscriptions will surface addresses you had forgotten about. Update the important ones deliberately — bank, domain registrar, hosting provider first.

Why do my emails from the website contact form go to spam?

Almost always because the form sends with the visitor's address in the From header, from your web server's IP, which is not authorised in your SPF record. Send from an address at your own domain and put the visitor's address in Reply-To. Better still, relay through your mail provider's SMTP rather than the web server's local mailer.

Can I send mail from my own server on a home connection?

Effectively no. Residential IP ranges are on the Spamhaus PBL by design, ISPs commonly block outbound port 25, and residential addresses lack the reverse DNS that receivers require. Run the mailbox wherever you like, but relay outbound mail through a provider.

How many aliases can I have?

Provider-dependent; Google Workspace allows 30 per user, Microsoft 365 around 400. Aliases are almost always free, unlike mailboxes, so use them rather than creating accounts for addresses that just need to reach an existing person.