How to Add a Custom Domain Email (Gmail, Outlook, or Any App)

A custom domain email is an address that ends in your own domain instead of a provider's — you@yourcompany.com rather than yourcompany@gmail.com or yourname@outlook.com. It is the single clearest signal that you are a real business or a serious professional, it stays with you even if you change email hosts, and it costs less than a coffee a month to run. And yet most people never set one up, because the moment you start reading about it you hit a wall of acronyms — MX, SPF, DKIM, DMARC, TXT, CNAME — and quietly close the tab.

That wall is the only hard part, and it is not actually hard. Underneath the acronyms, the whole process is four plain steps: buy a domain name, choose a company to host the mailboxes, paste a handful of records into your domain's DNS settings so the internet knows where your mail lives and that you are allowed to send it, and then create your addresses. Once that is done, your custom email behaves like any other inbox — you can read and send it in Gmail, Outlook, Apple Mail, or any app you like.

This guide walks the entire thing end to end, in order, in plain language. You will learn what a domain and a mail host actually are and how to pick each one, the five hosts most people choose between in 2026 (Google Workspace, Microsoft 365, Fastmail, Proton, and Zoho) and who each suits, exactly which DNS records to add and what every one of them does, how to create addresses and aliases, and how to confirm your mail actually sends and lands in the inbox rather than spam. There is a full DNS records table you can use as a checklist and worked examples you can map onto your own domain.

We will keep the jargon defined the first time it appears and skip the parts you do not need. The aim is that by the end you have a working professional address on a domain you own — and a clear picture of where every piece lives, so when something needs changing later you know exactly which knob to turn. Near the end we cover the practical reality of living with a custom domain alongside your other accounts, and how an AI-native email client lets you read and send from all of them in one place.

What is a custom domain email and why set one up?

A custom domain email has two parts that come from two different places, and separating them in your head makes the whole setup click. The part after the @ — yourcompany.com — is the domain, which you rent from a domain registrar. The mailbox behind the address — the actual storage and the servers that receive and send your mail — comes from a mail host. They are separate services, often from separate companies, glued together by a few DNS records. You can change either one later without losing the other, which is exactly the point: you own the address, and the host is just the current plumbing behind it.

The reasons to set one up are practical, not vanity. A custom address looks credible — an email from you@yourstudio.com reads as an established business in a way yourstudio@gmail.com never will, and that perception affects whether people reply, click, and trust you. It is portable: because you own the domain, you can move from one host to another, or hand the address to a new team member, without telling everyone you have a new email. It gives you control — unlimited addresses and aliases on the same domain (sales@, support@, hello@, billing@), so you can route, filter, and present yourself however you want. And it protects your brand, because once you own the domain, nobody else can send mail that genuinely comes from it.

There is a deliverability angle too, and it is the reason the SPF, DKIM, and DMARC records later in this guide matter so much. When you send from a custom domain, mail servers on the receiving end check whether your domain has vouched for the message. Set those records up correctly and your mail lands in the inbox and looks legitimate. Skip them and your perfectly real email can get filed as spam or rejected outright — not because of what you wrote, but because your domain never proved it was the sender. Getting the records right is what turns a custom address from a liability into an asset.

One myth worth clearing early: a custom domain email is not only for big companies. A freelancer, a two-person studio, a side project, a club, a family — anyone who owns a domain can have one, and the cheapest hosts run a few dollars a month for a single mailbox. The barrier was never cost; it was the DNS step, and that is what we are about to make routine.

How do you buy a domain for your email?

Before you can have email on a domain, you need to own the domain, and that is the easy part. A domain registrar is the company you rent a domain name from — names like Namecheap, Cloudflare Registrar, Porkbun, Google's former domains business (now folded into Squarespace), or the registrar built into your website host. You search for the name you want, pay an annual fee, and it is yours for the year, renewable indefinitely as long as you keep paying.

Pick the name first. For a business, the cleanest choice is your business name with a common ending: yourcompany.com if you can get it, since .com still carries the most trust and is what people type by default. If the .com is taken or expensive, modern endings like .co, .io, .studio, or a country code (.co.uk, .de, .ca) are perfectly legitimate and widely accepted — just be aware that some people instinctively type .com, so a memorable name on a clean extension beats a clever name on an obscure one. Keep it short, easy to spell out loud, and free of hyphens or numbers if you can, because you will be saying this address on phone calls for years.

Expect to pay roughly $10–$15 a year for a typical .com, sometimes less on a first-year promotion and more for premium or niche extensions. Two things to watch when you buy: first, turn on WHOIS privacy (also called domain privacy) — it is usually free and hides your personal name, address, and phone from the public registration record, which otherwise becomes a spam magnet. Second, plan to keep auto-renew on; a lapsed domain can be snapped up by someone else, and recovering it ranges from expensive to impossible. The domain is the one piece of this whole setup you genuinely cannot afford to lose, so treat the renewal like rent.

You do not have to buy your domain from the same company that hosts your email, and often you should not — registrars compete on price and DNS tooling, mail hosts compete on the mailbox experience, and the best of each are rarely the same company. The exception is convenience bundles: Google Workspace, Microsoft 365, and Zoho can all register a domain for you during signup and wire up the DNS automatically, which removes the manual record step entirely. That trade — slightly less control for a lot less fiddling — is a reasonable one if the acronyms still worry you. We will cover both paths.

Which email host should you use for a custom domain?

The host is the company that runs your actual mailboxes — receiving, storing, and sending your mail on your domain. This is the choice that shapes your day-to-day experience, your cost, and your privacy posture, so it is worth a moment of thought rather than grabbing the first option. In 2026 most people land on one of five: Google Workspace, Microsoft 365, Fastmail, Proton, or Zoho Mail. They split cleanly by what you care about most — ecosystem, price, simplicity, or privacy.

Google Workspace gives you Gmail and the Google apps (Drive, Docs, Meet, Calendar) on your own domain. If your team already lives in Gmail, this is the path of least resistance — the interface everyone knows, excellent search and spam filtering, and tight integration across the suite. Microsoft 365 is the mirror image for the Office world: Outlook plus Word, Excel, Teams, and OneDrive on your domain, the obvious pick for organizations standardized on Microsoft tooling. Both are full productivity suites priced per user per month, so you pay for the apps whether or not you use them all.

If you mainly want excellent email without the rest of an office suite, Fastmail is the long-standing favorite — fast, clean, privacy-respecting, with first-class support for custom domains and aliases and a famously simple setup. Proton Mail leads on privacy: end-to-end encryption, a Swiss jurisdiction, and a strong stance on not reading your mail, with custom-domain support on its paid plans (note that connecting Proton to a third-party app historically requires Proton Mail Bridge, which we touch on below). Zoho Mail is the value pick — genuinely capable business email at the lowest prices of the group, with a free tier for a single domain that makes it a common starting point for solo founders and small teams. Here is the comparison at a glance.

Prices above are indicative starting points for 2026 and shift with plans, promotions, and annual billing — always check the host's current pricing page before you commit. A few decision shortcuts: if your team already uses Gmail or Office daily, match the host to that habit and you will save yourself a migration. If you just want clean, reliable email and dislike clutter, Fastmail or Zoho will make you happier than a full suite you barely touch. If privacy is the priority above all, Proton is the clearest answer, with the one caveat that reading it in a third-party app is less plug-and-play than the others.

Whatever you choose, the mechanics from here are the same shape: the host gives you a set of DNS records to add to your domain, you add them at your registrar, you create your addresses, and you are live. The differences between hosts are real but they live in the dashboard and the app — the underlying email standards (MX, SPF, DKIM, DMARC, IMAP) are universal, which is also why your custom domain mailbox can be read in essentially any email app regardless of who hosts it.

What DNS records do you need for custom domain email?

This is the section everyone fears and the one that, once you have read it, you will never fear again. DNS — the Domain Name System — is the internet's address book. It is a set of records attached to your domain that tell the world where different services live. For email you add a small, specific set of records: one type that routes incoming mail to your host, and three that prove outgoing mail genuinely came from you. Your host hands you the exact values; your job is to paste them into the DNS settings at your registrar. That is the whole task.

Here is what each record type does, in plain terms. MX (Mail Exchanger) records point your domain at your mail host's incoming servers — they are the literal forwarding address that says "mail for @yourdomain.com goes here." Without correct MX records, mail sent to your address simply has nowhere to land. SPF (Sender Policy Framework) is a TXT record that lists which servers are allowed to send mail on behalf of your domain, so receivers can reject forgeries. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send and publishes the matching public key in DNS, so receivers can verify the message was not tampered with and really came from your domain. DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record that ties SPF and DKIM together and tells receivers what to do if a message fails — nothing, quarantine it, or reject it — and where to send reports.

The mental shorthand: MX is the mailbox on the street that receives your post; SPF, DKIM, and DMARC are the seal, signature, and instructions that prove your outgoing letters are really from you. You need MX for mail to arrive at all, and you need the other three for your sent mail to be trusted and land in the inbox rather than spam. Below is the full set of records you will typically add, what each looks like, and its purpose. Your host's setup page will give you the exact hostnames and values to paste — these are the shapes to expect.

A few things to understand about these values so you can add them confidently. MX records carry a priority number (sometimes called preference) — lower numbers are tried first, so an MX at priority 1 is your primary server and one at priority 5 is the backup. List every MX value your host gives you, with the priorities exactly as shown. The SPF record must be a single TXT record per domain — if your host's documentation shows one SPF string, do not create a second SPF record, because two SPF records is itself an error that breaks authentication; instead merge them into one. The DKIM record uses a selector (a short label like google._domainkey or fm1._domainkey) so a domain can hold more than one signing key; copy the selector exactly as given.

DMARC deserves a word on its policy setting because it is where people either get it right or lock themselves out. The policy is the p= value: p=none means "monitor only, do nothing" — it changes no delivery behavior but starts sending you reports so you can see who is sending as your domain. p=quarantine means "send failures to spam," and p=reject means "refuse failures outright." Start at p=none for a couple of weeks, read the reports to confirm your legitimate mail (and any tools that send on your behalf, like a newsletter service) all pass, then tighten to quarantine and eventually reject. Jumping straight to p=reject before your real senders are aligned can bounce your own mail, which is a bad first day with a new domain.

Finally, DNS changes are not always instant. Records propagate across the internet over a window controlled by each record's TTL (time to live) — usually minutes to a few hours, occasionally up to 24–48 hours in the worst case. So if mail does not flow the second you save, do not panic and start changing things; give it time, then verify. Most hosts include a one-click "verify my DNS" button that checks every record for you, which is the fastest way to confirm you got it right.

How do you add the DNS records step by step?

With the concepts in hand, the actual procedure is mechanical. The order matters a little — you want MX in place so mail can arrive, then the authentication records so it is trusted — but every host gives you the same kind of copy-and-paste list. Here is the end-to-end sequence that works whether your registrar and host are the same company or different ones.

1. 1

   Sign up with your chosen mail host and add your domain

   In Google Workspace, Microsoft 365, Fastmail, Proton, or Zoho, start the setup and enter the domain you own (yourdomain.com). The host will ask you to prove you control the domain and will then generate the exact DNS records you need to add.

2. 2

   Verify domain ownership

   The host gives you a verification record — usually a TXT record with a unique string, sometimes a specific MX or a file to upload. Add it at your registrar's DNS settings and confirm. This proves the domain is yours before the host will route its mail.

3. 3

   Log in to your registrar's DNS settings

   Go to the registrar where you bought the domain (Namecheap, Cloudflare, Porkbun, etc.) and open the DNS or Advanced DNS panel for your domain. This is where every record below gets pasted. If your host registered the domain for you, this step may be automated.

4. 4

   Add the MX records

   Create one MX record for each server your host lists, copying the hostname and the priority number exactly. Remove any old or placeholder MX records (some registrars add a default one) so only your host's MX records remain — stray MX records misroute mail.

5. 5

   Add the SPF (TXT) record

   Create a single TXT record on the root domain (@) with the SPF value your host provides, e.g. v=spf1 include:yourhost.com ~all. If you already have an SPF record for another sender, merge the includes into one record rather than creating a second.

6. 6

   Add the DKIM record

   Add the DKIM record your host generates — a TXT or CNAME at a selector hostname like selector._domainkey. Copy the long key value or CNAME target exactly; a single altered character breaks the signature. Some hosts make you enable DKIM in their dashboard after the record is live.

7. 7

   Add the DMARC (TXT) record

   Create a TXT record at _dmarc with a starting policy of monitor only: v=DMARC1; p=none; rua=mailto:you@yourdomain.com. This begins collecting reports without affecting delivery. You will tighten the policy to quarantine, then reject, once you confirm your real mail passes.

8. 8

   Save, wait for propagation, and verify

   Save all records and give DNS time to propagate — often minutes, occasionally up to 24–48 hours. Then use your host's "verify" or "check DNS" button to confirm every record resolves correctly. Green checks across MX, SPF, and DKIM mean you are wired up.

9. 9

   Create your mailboxes and send a test

   In the host dashboard, create your primary address (you@yourdomain.com) and any others. Send an email from it to a different account you control and reply back, confirming mail both sends and arrives — and that it lands in the inbox, not spam.

That is the whole job. If your registrar and host are the same company (or your host offered to register the domain), several of these steps collapse into a guided wizard that adds the records for you — you click through and it is done. The manual path above is what you follow when registrar and host are different, which is the more common and more flexible setup. Either way, the verify button is your friend: do not trust that it worked, confirm it did.

One practical note on existing mail. If you are moving an address that already exists (say you had email on this domain through a web host's basic mail and are upgrading to a real host), changing the MX records reroutes new incoming mail to the new host immediately once propagated — but it does not move your old messages. Migrating existing mail is a separate task (covered in our guides on switching and migrating providers, linked below), and it is usually safest to set up and verify the new host first, then migrate the old mail into it, then switch the MX records last so nothing arrives during the move.

How do you create addresses and aliases on your domain?

Once the domain is verified and the records are live, creating addresses is the fun part and the reason you did all this. There are two different things people mean by "another address," and keeping them straight saves money and confusion: a mailbox is a full account with its own login, storage, and password, which most hosts charge for per user; an alias is an additional address that delivers into an existing mailbox, which is usually free and unlimited. You pay for people, not for addresses.

Create a mailbox for each real person who needs to log in and send mail independently — you@, jordan@, priya@. Each is a separate billable seat on most paid hosts. Then layer aliases on top for the roles and functions a single person or small team handles: sales@, support@, hello@, billing@, jobs@, no-reply@. An alias like support@yourdomain.com can route into your main mailbox today and be reassigned to a dedicated support person later, all without anyone outside ever knowing the address changed. This is the quiet power of owning the domain — you present as a structured organization while one or two people actually handle everything.

A useful pattern many hosts support is the catch-all address, which delivers any mail sent to a non-existent address on your domain (typo@, oldname@, anything@) into one inbox. It is convenient — you never miss mail from someone who guessed wrong — but it is a double-edged sword, because spammers blast random addresses at domains and a catch-all collects every one. Most setups are better served by defining the specific aliases you actually use and letting unknown addresses bounce. If you do enable catch-all, expect more spam and filter accordingly. Below is a sensible starting structure for a small business.

How do you make sure your custom domain email lands in the inbox?

Setting up records is half the work; confirming your mail is actually trusted is the other half, and it is the step people skip and regret. A brand-new domain has no sending reputation, and receiving servers are cautious with unknown senders. The good news is that the SPF, DKIM, and DMARC records you already added are exactly what builds that trust — you just need to verify they pass and warm the domain up gently rather than blasting it on day one.

Start with a real test. Send a message from your new address to an account on a major provider you control (a Gmail or Outlook address is ideal because their filters are strict), then open the received message and check the headers. In Gmail you click the three dots and "Show original"; you want to see SPF: PASS, DKIM: PASS, and DMARC: PASS. If all three pass, your authentication is correct and your mail is presenting as legitimate. If one fails, that record is wrong or not yet propagated — go back to it specifically rather than redoing everything. Free online tools (commonly called mail testers) will also score a sample message and flag exactly which record is off.

Then warm the domain. Reputation is earned through normal sending patterns over time, so for the first couple of weeks send ordinary one-to-one mail to real people who reply — that two-way engagement is the strongest positive signal to filters. Avoid sending a large blast (a newsletter to hundreds of cold addresses) from a fresh domain, which looks exactly like spam to a system that has never seen you before. If you do plan bulk sending, use a dedicated sending service that handles warm-up and keep your transactional and marketing mail on subdomains so a marketing reputation problem never touches your main inbox.

Keep an eye on the DMARC reports that the rua= address collects. Early on they tell you whether every legitimate source — your host, plus any third party that sends as you, like an invoicing tool or a scheduling app — is passing authentication. Once the reports are clean for a couple of weeks, tighten your DMARC policy from p=none to p=quarantine, and later to p=reject, so that anyone forging your domain gets blocked. That progression is the difference between a domain that merely sends mail and one that is actively protected against spoofing.

Can you use a custom domain with Gmail, Outlook, or any app?

Yes — and this is where the work pays off, because once a mailbox exists on your domain, reading and sending it is provider-agnostic. There are two distinct ways the word "Gmail" or "Outlook" comes up here, and confusing them is common. One is hosting your domain on Google Workspace or Microsoft 365, where the mailbox itself lives on Google or Microsoft and you get the full Gmail or Outlook experience on your own domain — that is the host choice we covered above. The other is connecting a custom-domain mailbox hosted somewhere else (Fastmail, Zoho, your web host) into a Gmail or Outlook account you already use, so you read it in an interface you like without paying that company to host it.

That second path works through the universal email standards. Almost every mail host supports IMAP (to read your mail in any app) and SMTP (to send through the host), and the free Gmail and Outlook.com webmail let you add an external account using those settings — "Check mail from other accounts" and "Send mail as" in Gmail, or "Connected accounts" in Outlook. You enter the host's IMAP and SMTP server names, your full custom address as the username, and your password (or an app-specific password, which several hosts and all 2FA-protected accounts require instead of your main password). Once connected, you read your you@yourdomain.com mail inside Gmail and can send replies that come from your custom address, not your Gmail one.

Two host-specific caveats are worth flagging. Proton Mail does not expose standard IMAP/SMTP directly for privacy reasons; to use it in a third-party app you run Proton Mail Bridge, a small local program that translates Proton's encrypted mail into IMAP/SMTP for your app — so Proton in another client is possible but takes the extra Bridge step. And iCloud, Fastmail, and most modern hosts require an app-specific password rather than your normal login when you connect them to an outside app, especially with two-factor authentication on. Our companion guide on adding iCloud, Fastmail, and Proton to one app, linked below, walks those specifics; our IMAP vs POP3 explainer covers why IMAP is the right protocol when you read mail on more than one device.

The takeaway is simple: your custom domain mailbox is not locked to whoever hosts it. Whatever app you prefer — Gmail's web interface, Outlook, Apple Mail, a mobile client, or an AI-native client — can read and send it, because it is built on open standards every app speaks. The host is the engine; the app is the steering wheel, and you can change the wheel whenever you like.

What does it cost and what can go wrong?

The honest budget for a working custom domain email is small. The domain itself runs roughly $10–$15 a year. The mailbox runs from free (Zoho's single-domain tier) to around $5–$7 per user per month for the popular hosts, billed monthly or discounted annually. A solo professional can run a credible custom address for well under $100 a year all in; a small team scales linearly with the number of people who need their own login, not the number of addresses, because aliases are free. There is no per-message cost for normal sending.

As for what goes wrong, the failure modes are predictable and all live in the DNS step. The classic ones: leaving an old or default MX record in place so mail misroutes; creating two SPF records when there must be exactly one; pasting a DKIM key with a missing character so the signature fails; setting DMARC straight to p=reject before your real senders are aligned and bouncing your own mail; and impatience — assuming the setup is broken when DNS simply has not propagated yet. Every one of these is caught by sending a test to a strict provider and reading the SPF/DKIM/DMARC result in the headers, which is why that single verification step is non-negotiable.

A subtler issue is reputation rather than configuration: a perfectly configured new domain can still land in spam for the first stretch simply because it is new, and the fix is patience and normal sending behavior, not more records. The other recurring trap is the domain lapsing — if auto-renew is off and a card expires, the domain can drop and someone else can register it, taking your email and website with it. Treat the domain renewal as critical infrastructure. Below is the failure-mode table as a quick diagnostic when something is not working.

How does AI Emaily fit into a custom domain setup?

Here is the practical reality once your custom domain is live: it is rarely your only account. You have the new you@yourcompany.com, probably a personal Gmail, maybe an old Outlook address, perhaps a shared support@ inbox, and the role aliases you created. Each one is a place to check, a place to send from, a place to keep tone and follow-ups straight. The custom domain solved how you look; it did not solve the daily reality of mail scattered across several places.

AI Emaily is an AI-native email client built for exactly that picture. Once your custom-domain mailbox exists on any host — Google Workspace, Microsoft 365, Fastmail, Proton, Zoho, or a plain IMAP host — you connect it to AI Emaily alongside your other accounts, and they all land in one inbox. You read everything in one place, and you send as the right identity from the same window: a reply on a thread that came to you@yourcompany.com goes out from that address, a personal note goes from your personal one, and a message to a customer can go from support@ — the send-as identity follows the conversation instead of forcing you to switch accounts.

Because it is AI-native, the value is not just consolidation. AI Emaily reads across your connected accounts so you triage one prioritized inbox instead of five, and it drafts replies in your voice with the right tone for each recipient and account — a measured note from your business domain, a lighter one to a teammate — so a custom address backed by careful writing reinforces the professional impression you set one up for in the first place. It connects through the same open IMAP/SMTP standards your host already speaks, so there is no special integration to wait for; if your mailbox works in an app, it works here.

You stay in control throughout. In its default Copilot mode, AI Emaily drafts replies and waits — nothing sends until you approve it, so you review the wording and the from-address before anything leaves. And it is private by design: your mail is used to draft for you, not to train models for anyone else. You can start free at app.aiemaily.com/signup — the Free plan is $0 and connects your accounts with AI drafting, and Pro is $17.99/month billed annually when you want it across everything. The point is that once you have done the work to own a professional address, reading and sending from it — and your other accounts — happens in one place, without the daily account-switching.

The bottom line on adding a custom domain email

A custom domain email looks intimidating only because of the acronyms, and the acronyms are the smallest part of it. The whole task is four steps: buy a domain from a registrar, pick a host for the mailboxes, paste a short set of DNS records so the internet knows where your mail lives (MX) and that you are the real sender (SPF, DKIM, DMARC), and create your addresses and aliases. Verify with a test message that shows all three authentication checks passing, warm the domain gently, and you have a professional address you own outright for a few dollars a month.

Choose the host that matches how you already work — Google Workspace or Microsoft 365 if your team lives in those suites, Fastmail or Zoho for clean affordable email, Proton if privacy leads. Keep exactly one SPF record, copy the DKIM key character-for-character, start DMARC at p=none and tighten it over time, and never let the domain lapse. Pay for mailboxes per person and use free aliases for every role. Those few habits are the difference between a custom domain that quietly works for years and one that lands in spam or disappears.

And once it is live, remember that the address is yours, not the host's — you can read and send it in any app, and move hosts without changing it. If you would rather not juggle the new domain alongside your other accounts, that is exactly what AI Emaily handles: one inbox for everything, send-as your domain on the right threads, drafts in your voice, and your approval before anything sends. Either way, the principle holds — own the domain, get the four records right, and your professional email is set.