You bought the domain. Now you need the inbox.
To create email with your domain is the single most consequential infrastructure decision you'll make as an operator. It's the difference between appearing as someone@gmail.com and operating as name@yourcompany.com. One reads like a temporary side project. The other reads like a real business.
But this isn't just about appearances. It's about control. When you use a free provider for business, you're a tenant. When you own the domain and control the MX records, you're the landlord. You own the data, you set the costs, and you decide who has access to what.
Whether you're a founder provisioning your first mailbox or an MSP migrating fifty clients off a legacy cPanel host, the mechanics are identical: you need a domain, a host, and a precise set of DNS records. This guide walks through all of it — no filler.
Before You Start: What You Actually Need
Attempting to configure email without these three components is a recipe for split-brain DNS and lost messages. Don't start until you have all three ready.
1. The Domain
You must own the domain (e.g., yourcompany.com). If you haven't bought one yet, registrars like Namecheap, Cloudflare Registrar, or Porkbun are solid options. One rule: don't buy your domain from your web host. Keeping your registrar and hosting separate is a basic operational safety principle — if your host goes down or locks your account, you still control your DNS.
2. DNS Access
You need write access to your DNS zone. This is usually labeled "DNS Management," "Zone Editor," or "Advanced DNS" in your registrar's dashboard. You'll be editing TXT, MX, and CNAME records. If you don't have this access, stop here and get it before anything else.
3. An Email Host
The registrar points traffic. The host stores data. You can't just "turn on" email at GoDaddy without a hosting plan. Your two main choices:
- The default choice: Google Workspace or Microsoft 365. Powerful, but $72–$144 per user per year, and every functional address (info@, billing@) often counts as a paid seat.
- The operator choice: TrekMail. Flat-rate plans, pooled storage, and no per-seat tax. Built for teams that need professional email without the enterprise overhead.
The 10-Minute Checklist
If you've done this before, here's the fast path. Skip a step and you'll hit a delivery error you'll spend an hour debugging.
| Step | Action | The Gotcha |
|---|---|---|
| 1. Verify Domain | Add a TXT record to prove ownership | Do this before touching MX records. It prevents domain hijacking. |
| 2. Create Mailboxes | Provision users (info@, jane@) in the host panel | If you switch MX before creating users, incoming mail bounces immediately with a 550 error. |
| 3. Set MX Records | Point your domain's mail traffic to the host | Delete all old MX records first. Mixing old and new causes random delivery failures. |
| 4. Authenticate | Add SPF, DKIM, and DMARC records | In 2026, Gmail and Yahoo will route your mail to spam without these. No exceptions. |
| 5. Test | Send to an external Gmail, then reply back | Verify the full loop: outbound delivery AND inbound reception before declaring victory. |
Step 1 — Create Mailboxes First (Yes, First)
This is the most common beginner mistake, and it costs people real leads.
When you flip your MX records, the internet immediately starts trying to deliver mail to the new server. If that server doesn't have contact@yourdomain.com in its system, it rejects the message with a 550 User Not Found error. The sender gets a bounce notification. You never know it happened.
Create every mailbox you need before you touch a single DNS record.
The procedure in TrekMail:
- Log into your TrekMail dashboard.
- Navigate to the Mailboxes tab for your domain.
- Create every address you currently use.
For SMBs: At minimum, create your personal address (yourname@) and a functional address (hello@ or info@).
For agencies migrating a client: You must replicate their exact address list. If they had billing@ on the old host, you need billing@ on the new host before the MX switch. Pull their full address list before you schedule the cutover. One missing address means one bounced email — and one angry client call.
TrekMail lets you either create mailboxes manually or send a mailbox setup invite — a one-time link that lets the user set their own password without you ever handling credentials. For client work, that's the cleaner path. See the mailbox setup invites doc for the full flow.
Step 2 — Set MX Records: The Cutover
MX (Mail Exchange) records are the traffic controllers of email. They tell every mail server on the internet: "Send messages for this domain to this host." Without them, your email doesn't exist — regardless of what else you've configured.
How to set MX records:
- Go to your registrar's DNS management page.
- Purge existing MX records. You might see entries for "GoDaddy Secure Mail," "Google Workspace," or an old cPanel host. Delete them all. You want a clean slate, not a half-migrated mess.
- Add the records from your new host. For TrekMail, it looks like this:
| Type | Host/Name | Value | Priority |
|---|---|---|---|
| MX | @ (or blank) | mx1.trekmail.net | 10 |
| MX | @ (or blank) | mx2.trekmail.net | 20 |
On TTL: If your registrar lets you edit the TTL (Time To Live), set it to 300 seconds before the change. That tells other servers to check for updates every 5 minutes instead of every 24 hours, which makes propagation much faster. Change it back to something normal (3600) after you've confirmed everything works.
For registrar-specific screenshots and field names, see our DNS setup guide for popular providers.
Step 3 — First Login and Send/Receive Test
DNS propagation usually completes in 15–30 minutes for most registrars. It can take up to 24 hours in edge cases. Don't assume it worked just because you finished step 2.
Log in via webmail first. Don't configure Outlook or your iPhone yet — we need to verify the server connection works before adding any client layer on top.
The outbound test: Compose an email from your new address to your personal Gmail.
- Did it arrive?
- Did it land in spam? (If yes, your SPF or DKIM is missing — see step 4 below.)
The inbound test: Reply from Gmail to your new business address.
- Did it arrive in the webmail inbox?
- If yes, your MX records are valid. You're live.
Once both tests pass, you can set up your email client. For IMAP connection settings, see TrekMail's IMAP & SMTP settings doc. If you're connecting to Gmail as a client, there's a separate Gmail connection guide.
Step 4 — The Deliverability Trinity: SPF, DKIM, DMARC
Setting up MX records gets your email working. Setting up SPF, DKIM, and DMARC keeps it out of spam. In 2025–2026, Google and Yahoo have made these three records effectively mandatory. Skip them and you're handing your messages a one-way ticket to the junk folder.
SPF — Who's Allowed to Send
SPF (Sender Policy Framework) is a DNS record that lists every server authorized to send email on your behalf. When a receiving server gets a message from yourcompany.com, it checks whether the sending IP is on your approved list. If it's not, the message fails.
For TrekMail, your SPF record looks like this:
v=spf1 include:_spf.trekmail.net -all
Translation: "Only TrekMail's servers are allowed to send mail for this domain. Reject everyone else."
The -all at the end is intentional. It's the strictest setting. If you're not using any other sending service (transactional email tools, CRMs), use -all. If you are, you'll need to include them too — but watch your SPF lookup limit. Go over 10 DNS lookups and SPF breaks entirely.
DKIM — The Tamper-Evident Seal
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outbound message. The receiving server uses your public key (published in DNS) to verify the signature. If the email was altered in transit, the signature fails and the message gets flagged.
You generate the key pair in your TrekMail dashboard, then publish the public key as a TXT record in your DNS. TrekMail's setup wizard handles the heavy lifting — you're essentially copying a string and pasting it into your registrar. For the full procedure, see the required DNS records doc.
DMARC — The Policy Engine
DMARC ties SPF and DKIM together and tells the receiving server what to do when one of them fails. It also sends you reports so you can see who's sending email pretending to be you.
Start with a monitoring-only policy:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
This means: "If authentication fails, don't block the mail — just send me a report." Once you've confirmed your own sending passes cleanly, tighten it to p=quarantine and eventually p=reject.
For a deeper walkthrough on each record, see our articles on SPF record setup, DKIM setup, and how to set up DMARC. Or if you want the full picture in one place, the email authentication setup order guide covers all three in sequence.
Why Not Just Use Gmail?
"Can't I just use mycompany@gmail.com?" Yes. You can also conduct surgery with kitchen knives. Technically possible. Operationally insane.
Here's what actually goes wrong when you use personal addresses for business:
Data Ownership
Google has automated systems that flag accounts. If yours gets flagged — for any reason — you lose access instantly. No support line to call. No human review. Your client history, invoices, and contacts are gone. When you create email with domain ownership and host it yourself, you own the data. If you hate the host, you export your mail and leave.
The Bus Factor
Your sales rep uses john.sales@gmail.com. He quits. He takes the inbox with him — and every lead he was working. If he used john@yourcompany.com, you reset his password, redirect his mail to the new hire, and continue without interruption.
SaaS Account Lock-Out
If you signed up for your accounting software, your CRM, and your ad platform using a personal email — and that person leaves — you often can't recover those accounts. Always use controlled addresses like billing@yourcompany.com for infrastructure. That address stays under your control regardless of personnel changes.
Custom Domain Email Explained
A custom domain email address is an email identity where the domain after the @ matches your website. Simple definition. But the infrastructure behind it represents a real shift in how your email lives and dies.
| Type | Example | Risk |
|---|---|---|
| ISP Mail | user@comcast.net | Tied to your internet provider. Move houses, lose email. |
| Web Host Mail (cPanel) | you@yoursite.com via cPanel | Email lives on the same server as your website. Site gets hacked or DDoS'd — email goes down too. Single point of failure. |
| Dedicated Email Hosting | you@yourcompany.com via TrekMail | Email is fully decoupled from your website. Website crashes? You can still email support to fix it. |
The third option is the only one worth running a business on. Your website and your email should not share infrastructure. When one breaks, you need the other to still work.
Simplest Setup for 1–5 Mailboxes
For most small businesses, the standard advice to buy Microsoft 365 or Google Workspace is overkill. You're paying for a platform designed for 500-person enterprises when you need email for three people and a few functional addresses.
The Old Way (The Per-Seat Trap)
You sign up for Google Workspace Starter at $6/user/month. You have three employees, but you also need info@, sales@, and billing@. Google wants you to pay for those as separate users. You're now at 6 seats — $36/month, $432/year — just for basic email routing.
Storage gets worse. The Starter plan gives you 30GB per user. When one person fills theirs, their email stops. You can't borrow space from other users. You either delete old mail or upgrade everyone to the $12/user/month tier.
The New Way (TrekMail Pooled Model)
TrekMail's Starter plan is $3.50/month (or $42/year) — flat. That covers 50 domains, 100 mailboxes per domain, and 15GB of pooled storage. You can create info@, billing@, and support@ as aliases that forward to real mailboxes without paying extra per address.
Your storage isn't carved up per-mailbox like it's 2005. It's pooled across your account, so that one executive with 12GB of attachments doesn't force you to upgrade everyone else. If you need more, you upgrade the plan — not every seat.
There's no admin console with 500 settings. There's a dashboard: add a domain, add users, check mail. That's it.
See the full TrekMail pricing page or compare plans at Plans Overview. If you want a side-by-side comparison of the broader market, see our breakdown of business email options for small businesses.
MX Records Explained (No Jargon)
DNS is abstract, so here's a concrete analogy.
Think of your domain as a commercial building.
- The A Record is the front door — it's how customers reach your website.
- The MX Record is the loading dock — it's where mail deliveries arrive.
When someone sends you an email, their server looks up your domain in the global DNS directory. It specifically queries for the MX record.
- No MX record? The server drives around the block, eventually gives up, and returns the message as undeliverable.
- MX record pointing to your old host? The delivery goes to an empty warehouse where nobody signs for it.
- Correct MX record? The mail arrives at the right server, gets delivered to the right inbox.
You can have a perfectly functional website (A record) and completely broken email (MX record) at the same time. They are independent systems that have nothing to do with each other.
5 DNS Mistakes That Kill Deliverability
These same errors show up constantly. When something isn't working after a domain email setup, check these first.
1. Leaving the "Backup MX" in Place
Old guides tell you to keep your old MX records as a "backup" with a higher priority number. Don't. Spammers specifically target low-priority MX records because they often have weaker spam filtering. If you leave old records in place, you've opened a back door. Delete everything from the old host.
2. CNAME Conflicts on the Root Domain
You generally can't put a CNAME record on your root domain (@). If you try to CNAME your root domain to a website builder like Wix or Squarespace, it often silently breaks your MX records. Use an A Record or an Alias/ANAME record for the root domain instead.
3. Changing Records Again Before Propagation Finishes
DNS is distributed across thousands of servers globally. Just because it looks correct in your browser doesn't mean it's propagated everywhere. Changes can take up to 24 hours. If you change the record again after 10 minutes because "it's not working," you reset the propagation clock. Make the change once, then wait.
4. Missing SPF Record
No SPF record means your outbound mail looks like it could be coming from anyone. Gmail will put it in spam. Full stop. Even a basic SPF record is better than none. See our SPF record setup guide if you haven't done this yet.
5. Wrong Hostname in MX Record
When adding MX records, the "Host" or "Name" field should almost always be @ — which represents the root domain. If you type mail or www there, you're setting up email routing for user@mail.yourcompany.com, not user@yourcompany.com. Double-check this field on every record you add.
Which Addresses to Create First
Before you start adding mailboxes at random, think about the operational lifecycle of each address. Who controls it? What happens when someone leaves?
1. The Break-Glass Admin (ops@ or admin@)
Never make your personal email the Super Admin. If you get locked out, if you hire someone to manage it, or if you sell the company someday, untangling a personal account from admin rights is miserable. Create a dedicated admin address. Store the credentials somewhere secure. Use it only for configuration changes.
2. Functional Aliases (info@, support@, hello@)
You don't want to check five separate inboxes. In TrekMail, create info@ as an alias that forwards to your main mailbox. Zero extra cost. You can still "Send As" info@ from your primary account so replies look right. See the forwarding setup doc for how this works.
3. Role Accounts for Infrastructure (billing@, marketing@)
Use dedicated role addresses — not personal ones — for every SaaS subscription, ad platform, and financial service. Your marketing manager quits. If the Facebook Ads account was tied to sarah@yourcompany.com, you change the password and redirect her mail. If it was tied to her personal Gmail, you're calling Facebook support for three weeks.
Naming Conventions and Format Decisions
Decide on a naming format now, before you have 20 employees. Changing email formats later breaks address books and confuses clients who've been corresponding with you for years.
| Format | Example | Pros | Cons |
|---|---|---|---|
| First name only | john@ | Friendly, easy to remember | Fails immediately when you hire a second John |
| First initial + last name | jdoe@ | Corporate standard, highly unique | Awkward to say out loud over the phone |
| First name + last initial | johnd@ | Good middle ground | Still risks collision (John Davis vs. John Doe) |
| Full name | john.doe@ | Professional, zero ambiguity | Long to type, higher typo risk |
Practical recommendation: Start with firstname@ if you're small and everyone knows each other. Plan for first.last@ as you grow past 5–10 people. TrekMail lets you keep the old address as an alias, so john@ still works even after you migrate to john.doe@. Nobody misses mail during the transition.
Troubleshooting: When It Breaks
You followed the steps and something still isn't working. Here are the most common failure patterns and what to actually check.
"I can send, but I can't receive."
Cause: MX records are wrong or haven't propagated yet.
Fix: Use whatsmydns.net to check your MX records from multiple global locations. If they still show your old host, wait — it's still propagating. If they show nothing, go back to your registrar and verify the records were saved correctly.
"I can receive, but my emails go to spam."
Cause: Missing or broken SPF, DKIM, or DMARC.
Fix: Send a test to mail-tester.com. It scores your message and tells you exactly which authentication record is missing or misconfigured. Also check Google Postmaster Tools if you've been sending for a while — it shows your domain reputation score. For a full diagnostic workflow, see our guide on stopping emails from going to spam.
"Outlook keeps asking for my password."
Cause: Wrong port, wrong protocol, or a Legacy Auth vs. Modern Auth mismatch.
Fix: Confirm you're using the correct settings:
- IMAP (Incoming): Port 993, SSL/TLS
- SMTP (Outgoing): Port 465 (SSL/TLS) or 587 (STARTTLS)
- Username: Your full email address, including the @domain — not just the part before it
For the full client setup, see connecting to Outlook or the full IMAP & SMTP settings reference.
"I'm getting a 550 bounce back."
Cause: The destination server can't find the recipient mailbox — either the address doesn't exist on your end, or the recipient's server is rejecting you based on reputation.
Fix: Check that the mailbox actually exists in your dashboard. If the address is correct, the rejection may be reputation-based. See our breakdown of why email domain reputation tanks and what to do about it.
Final Thoughts
To create email with your domain is to take operational responsibility for your digital presence. It moves you off the lease and onto the deed.
The goal is a system you configure once and never think about again. Clean DNS from day one — no leftover MX records, no missing SPF, no ignored DMARC reports. The Deliverability Trinity isn't optional anymore; it's the baseline. Get it right the first time and your email just works.
If per-user pricing is eating your budget and you don't actually need Google Calendar or SharePoint, TrekMail is the direct alternative. Flat rate. Pooled storage. Runs on standard IMAP and SMTP, so your team uses whatever client they prefer. Start on the free plan and upgrade when you need more capacity — not when you hire someone new.
Own your domain. Own your records. Own your data.