Email on Your Own Domain: Setup, Sending and Migration

In short: to run email on your own domain, pick a provider — Google Workspace, Zoho Mail, Yandex 360 or a self-hosted server — verify domain ownership, then publish four DNS records: MX, SPF, DKIM and DMARC. The whole setup takes thirty minutes to a couple of hours, free tiers exist, and an address like info@yourcompany.com stays yours no matter how many times you switch providers.

Why Email on Your Own Domain Is Worth It

An address like info@company.com is instantly more credible than company2020@gmail.com: the recipient sees who is writing, and spam filters give far more weight to a domain with properly configured authentication. For a business it is more than image — plenty of B2B partners, banks and payment providers simply refuse to work with addresses on public mail domains.

The bigger win is control. Mailboxes are created and revoked by an administrator, not by the employees themselves; a departing sales manager cannot walk away with client correspondence in a personal account. The domain belongs to you, so you can change providers whenever you like — the addresses survive, only the servers behind them change.

Ownership also unlocks security. Only the domain owner can publish SPF, DKIM and DMARC — the mechanisms that stop other people from forging your sender address and that directly decide whether your mail lands in the inbox or the spam folder.

Finally, you get address flexibility: create sales@, support@ and info@, route them to one shared mailbox or to different people, and move marketing campaigns to a dedicated subdomain so that newsletter reputation never drags down your day-to-day business correspondence.

Three Ways to Create Email on Your Own Domain

There are three routes: connect a cloud email service, use a business productivity platform, or run your own mail server. They differ in price, in how much work the setup and maintenance take, and in where your messages physically live.

Google Workspace

The default choice for most companies worldwide. You sign up, verify the domain with a TXT record, switch the MX records to Google — and your team gets Gmail, Calendar, Drive and Meet under your own domain. SPF and DKIM values are generated for you in the admin console; all you do is paste them into DNS. The exact records for every registrar are listed in the official Google Workspace documentation. There is no permanent free tier, only a trial, so budget a per-user monthly fee from day one.

Zoho Mail

The pragmatic alternative when you want a genuinely free start. Zoho Mail offers a free plan for small teams (with a modest mailbox quota and web-only access) and inexpensive paid tiers above it. The connection flow is identical: verify the domain, point MX to Zoho, publish the SPF and DKIM records the wizard gives you. If your team and data gravitate toward Russia and the CIS, Yandex 360 for Business plays the same role there — a mature cloud suite with a free tier and data centers in Russia.

A Self-Hosted Mail Server

Postfix plus Dovecot on a VPS gives you total control: your own quotas, your own retention rules, zero dependence on anyone else's pricing. The cost is that everything becomes your job — updates, backups, spam filtering, TLS certificates and, above all, the reputation of your IP address. If that IP ends up on a blacklist, you are the one negotiating delisting, not a provider's support team.

Criterion	Google Workspace	Zoho Mail	Self-hosted
Price	Per-user monthly fee, trial only — no free tier	Free plan for small teams; cheap paid tiers above it	Software is free, but the VPS and admin hours are not
Limits	Generous storage, limits depend on the plan	Modest quota and web-only access on the free plan	Limited only by your disk and bandwidth
Complexity	Low: setup wizard and ready-made DNS values	Low: step-by-step domain wizard	High: installation, anti-spam, monitoring and backups are all on you
Where data lives	Google data centers worldwide	Zoho data centers, region selectable	Your server, in any jurisdiction you choose

Tip: do not build a self-hosted server "to save money". Until you pass roughly fifty mailboxes, a cloud plan is almost always cheaper than the admin hours you will burn fighting blacklists and watching the Postfix queue.

Domain Verification: Proving the Domain Is Yours

Before accepting mail for your domain, a provider makes you prove the domain is actually under your control. Otherwise anyone could attach somebody else's domain to their own account. You pick the method; four are usually accepted.

• A TXT record at the apex — the most common and most reliable option: the provider issues a string, you publish it in DNS.
• A CNAME record pointing at a provider hostname — works the same way, but occasionally collides with records that already exist on that name.
• An HTML file in the site root — convenient when a contractor holds DNS access and you hold the site. Do not delete the file after verification: providers re-check periodically.
• Delegating the domain to the provider's nameservers — the most drastic route: the whole zone moves, and every other record has to move with it.

Mistakes here are always the same four, and each costs an hour of confusion:

• The record landed on a subdomain. Many registrar panels append the domain automatically, so a typed example.com becomes example.com.example.com. For the apex, put @ in the name field or leave it empty.
• The value got truncated or wrapped in quotes. Copy the whole string and never add quotes by hand — the panel adds them itself.
• Verification was triggered before propagation. The record does not reach resolvers instantly, and a large zone TTL means a longer wait.
• A stale verification record from a previous service is still in the zone and confuses the check. Delete records belonging to services you no longer use.

# Confirm the verification record is actually visible from outside
dig example.com TXT +short
dig _verification.example.com TXT +short   # if the provider asks for a service name

# Check the zone's TTL — it decides how long you wait
dig example.com TXT | grep -A1 'ANSWER SECTION'

What the internet sees, rather than what your panel shows, is visible in the DNS records check; the spread between resolvers in the propagation check.

How to Set Up Email on Your Domain: DNS Records Step by Step

Whichever provider you pick, the setup boils down to four DNS records. You add them in your registrar's or DNS host's control panel, and they propagate anywhere from a few minutes to 24 hours. Before and after each change, check the current state of the domain with the DNS lookup tool — it shows exactly which records the internet already sees.

Step 1. MX — Where Mail Is Delivered

The MX record names the server that accepts mail for your domain; the lower the priority number, the earlier the server is tried. For Google Workspace a single record is enough:

example.com.    3600  IN  MX  1 smtp.google.com.

Delete the old MX records from your web host, otherwise part of your mail will keep flowing to the previous server. Common mistakes and priority pitfalls are covered in our guide to MX records and email setup.

Step 2. SPF — Who May Send

The SPF record lists the servers allowed to send mail on behalf of your domain. It is published as a TXT record at the domain root:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

; self-hosted variant:
example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 -all"

A domain must have exactly one SPF record: two or more is a validation error, and receiving servers will start rejecting your mail because of it.

Step 3. DKIM — a Cryptographic Signature

DKIM attaches a digital signature to every outgoing message; recipients verify it against the public key you publish in DNS. The key is generated by your provider, or by opendkim on a self-hosted box:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B...IDAQAB"

Step 4. DMARC — the Policy Against Forgery

DMARC tells the rest of the world what to do with messages that fail SPF and DKIM, and sends you aggregate reports about forgery attempts against your domain:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Tip: start with p=none and spend two or three weeks just reading the reports. Once you are sure every legitimate source of mail — your CRM, website forms, newsletter tool — is covered by SPF and DKIM, tighten the policy to quarantine and eventually to reject.

Mail Sent by the Website: Where It All Breaks

Staff mailboxes and the mail your website sends are two different jobs, and the second one is routinely forgotten. Contact forms, order notifications and password resets leave from application code rather than a mail client — and those are exactly the messages that go missing.

There are three routes and they are not equivalent:

1. The language's own send function (mail() in PHP). The message leaves from the hosting server as something like www-data@server123.hosting.example, unsigned and outside your domain's SPF. Filters reject this category most often. It is only acceptable for internal notifications you can afford to lose.
2. SMTP of your own mailbox. The site authenticates against the mail server as the very mailbox it writes from. The message then passes your domain's SPF and DKIM and looks to the recipient exactly like a human's message. For most sites this is the right choice.
3. A transactional service. A separate provider for machine-generated mail: dedicated queues, delivery statistics and bounce webhooks. Worth it when volume is high or delivery is business-critical; details in transactional email deliverability.

# Typical settings for connecting a site to a mail server
SMTP host: smtp.<provider>
SMTP port: 587 (STARTTLS)  or  465 (SSL/TLS)
Encryption: mandatory — never plaintext
Username:   robot@example.com     # a real, existing mailbox
Password:   app password          # not the account's main password
From:       robot@example.com     # sender address must match that mailbox

Three rules close most website-mail problems:

• The sender address must exist on your domain. Not noreply@localhost and not the hosting address. Many providers reject a message with a "sender not verified" style error when the From mailbox is not theirs.
• Use an app password, not the main one. With two-factor authentication the regular password will not work over SMTP, and a dedicated one can be revoked without changing an employee's password.
• Do not send over port 25. Most hosts block outbound 25, and that is an anti-spam measure rather than a fault; which port does what is covered in email ports 25, 465 and 587.

Test website mail separately from staff mail. "People's email works but form submissions never arrive" is the single most common report: the domain is configured correctly while the site still sends around it. Submit a real form and read the headers of the message you receive.

Can You Get Email on Your Own Domain for Free?

Yes, a fully free setup is realistic, not a marketing trap. Zoho Mail's free plan covers a small team with basic mailboxes; Yandex 360 for Business likewise starts with a free tier. Google Workspace no longer offers a free edition, so if zero cost is the requirement, it is out. Exact user counts and quotas change over time — verify them on the provider's site right before you sign up.

A "free" self-hosted server is an illusion, though: Postfix and Dovecot cost nothing, but the VPS, backups and administrator hours very much do. Always calculate the total cost of ownership, not the license price.

What to expect from free tiers: a small mailbox quota, minimal support, sometimes ads in the web interface, and occasionally no IMAP access. That is enough to start, and upgrading to a paid plan later requires no DNS changes at all.

Migrating From Another Provider Without Losing Mail

Switching the MX record takes a minute; the hard part is not losing messages that arrive during the switch and not leaving staff without their archive.

1. Lower the MX TTL in advance — a day before the move. Other resolvers then pick up the new value in minutes rather than a day; why this matters is in the DNS TTL guide.
2. Create every mailbox at the new provider with the same names. A mailbox that does not exist is a delivery rejection the moment you switch.
3. Move the archive over IMAP with the new provider's migration tool. It copies folders over the protocol and does not require stopping the old mail.
4. Switch the MX and publish the new SPF and DKIM at the same time. A forgotten new DKIM is the classic reason mail starts landing in spam right after a migration.
5. Keep the old mailboxes for a few days. Some senders will still deliver using a cached MX record; run the migration tool once more afterwards to catch stragglers.
6. Remove the old records — previous MX, previous SPF include, previous DKIM selector — only once the flow has fully moved.

Changing the domain's nameservers takes mail with it. This is separate from changing mail providers and it hits unexpectedly: you move DNS to a site builder or a new host, and nobody recreates MX, SPF, DKIM and DMARC in the new zone. Outbound mail keeps working, so the problem surfaces a day or two later. The procedure is in changing your DNS server and connecting a domain to a website builder.

Testing That Everything Works

The setup is not finished until mail demonstrably flows in both directions. Do not skip this stage: a silently broken mailbox is always discovered at the worst possible moment — when a client has written to you and never got a reply.

Outbound first: send a message to an external Gmail account, open "Show original" and confirm the headers say spf=pass, dkim=pass and dmarc=pass. Then inbound: reply to that message and make sure the reply arrives. It also helps to write from the new address to your old personal one — you will see your own email exactly as recipients do, including how the sender name renders.

To confirm a specific mailbox exists and accepts mail, check it with the email checker: it talks to the receiving mail server and asks whether it would accept a message for that address. If messages do not arrive at all, walk through the "email not arriving" checklist; if they arrive but land in spam, see the breakdown of why emails go to spam and how to fix it.

Typical Failures and What They Mean

Symptom	Cause	What to do
The domain will not verify	The record landed on a subdomain or has not propagated	Check with dig … TXT +short; use @ in the name field
No inbound mail at all	MX missing, pointing at the old server, or pointing at a CNAME	MX must point at a hostname with an A record, never at an alias
Some mail still reaches the old server	An old MX record is left in place or still cached	Delete the extra MX and wait out the TTL
Staff mail arrives, website mail does not	The site sends via the language function from the hosting address	Move the site onto SMTP of a domain mailbox
"Sender not verified" (code 550)	The From field holds an address that does not exist on your domain	Use a real, existing mailbox
Everything configured, mail still in spam	Two SPF records, a mismatched DKIM selector, or a domain with no sending history	Keep one SPF, verify the selector, ramp volume gradually
Mail vanished after a domain move	Nameservers changed, mail records never recreated in the new zone	Move MX, SPF, DKIM and DMARC into the new zone

To confirm the domain publishes what you intended, use the MX lookup and the domain email check: they show MX, SPF, DKIM and DMARC in one place and catch the most common mismatches.

FAQ

How much does email on your own domain cost?

Anywhere from zero on the free tiers of Zoho Mail or Yandex 360 to a few dollars per user per month on paid cloud plans. Self-hosting starts at the price of a VPS plus recurring maintenance time. The domain itself typically costs about ten to twenty dollars a year.

Can I switch providers without losing my mail?

Yes. Messages are migrated over IMAP with the built-in migration tools that Google Workspace, Zoho and Yandex 360 all provide; after the copy finishes you simply repoint the MX record to the new provider. The addresses never change — that is the whole point of owning the domain.

Why does my mail go to spam even though SPF and DKIM pass?

Usually reputation: filters treat a brand-new domain with no sending history with suspicion. Ramp up volume gradually, begin with ordinary one-to-one correspondence, and do not launch bulk campaigns from the main domain during the first month.

How do I verify that a recipient address exists?

You can test an address without sending anything, by querying the recipient's mail server directly. How that works — and where the method has blind spots such as catch-all domains — is explained in our article on verifying that an email address exists.

Can mail live with one provider and the website with another?

Yes, and it is the normal arrangement. MX handles mail, A and CNAME handle the website: they are independent. The site can run on a builder or a host while mail sits in a cloud service, or the other way round.

What is an app password and why does the site need one?

It is a separate password for programs that cannot complete two-factor authentication. Give the site that one: if the code is ever compromised the password is revoked in a second, while the employee keeps using their normal password.

Why did mail stop arriving after a hosting change?

Almost always because the nameservers moved with the hosting and only the site's A record was recreated in the new zone. MX, SPF, DKIM and DMARC stayed in the old zone that nobody queries any more. Export the records before the move and carry them across in full.

How many mailboxes do I need, and what about addresses like info@?

Personal mailboxes per employee, while shared addresses (info@, sales@, support@) are better as aliases or groups: several people receive the mail and nothing needs reconfiguring when someone leaves.

Final Checklist

• Domain ownership verified with the provider (TXT record or meta tag).
• MX points only to the current provider; stale records deleted.
• Exactly one SPF record, ending with a strict qualifier.
• DKIM signing enabled and the public key published in DNS.
• DMARC policy published, reports delivered to a monitored mailbox.
• Test messages show spf=pass, dkim=pass and dmarc=pass.
• Mail from external services reaches the inbox, not the spam folder.
• The domain verification record has not been deleted after the check.
• The website sends through SMTP of a domain mailbox, not the language's send function.
• The sender address on website mail is a real, existing mailbox.
• The site uses a dedicated app password that can be revoked on its own.
• For a migration: TTL lowered in advance, mailboxes created, archive moved over IMAP, old records removed only after the flow shifted.
• After any nameserver change, MX, SPF, DKIM and DMARC were verified to still be in place.