Which kind of company email do you actually need?
For most small companies, mailboxes that come with web hosting are enough: you get real addresses, webmail and your phone's mail app, with the website and the mail in one place. The other two routes solve different problems, so rule them out first.
| Route | It suits you when | What you take on |
|---|---|---|
| Mailboxes with web hosting | You want addresses, webmail and mail apps next to your site | Creating addresses and keeping passwords in order |
| An office suite that includes mail | Your team lives in shared calendars and shared documents | Another set of accounts for every person, kept apart from your site |
| Your own mail server | You need full control and have someone to look after it | Updates, security, spam filtering and sending reputation, all yours |
The rest of this page follows the first route, using Primcast web hosting. Most of it also holds wherever your mail lives, because the DNS rules are the same for everybody.
What a hosting plan gives you for mail
Every Primcast hosting plan includes email on your domain, run from the Web Hosting tab of the dashboard you already sign in to. There is no second panel to sign in to.
- Mailboxes and forwarders, created one at a time or many at once from a CSV file
- Webmail in the browser, plus IMAP, POP3 and SMTP for any mail app
- Out-of-office replies, filters, your own spam score, and senders to always allow or block
- SPF, DKIM and DMARC records created for you
- A backup of the account each night, mail included, and you can bring back a mailbox yourself
Once your payment is confirmed, the platform builds the account and emails you the control panel link, the nameservers and your mail settings. Simple Hosting is the plan described as one website with its own email; the plan table on the hosting page shows how many email accounts each plan allows and how far back its backups go. You can order before you own a name and add it later, or find one on our domains page.
Plan your addresses before you create them
Decide who reads what first, because renaming an address after it is printed on invoices is far more work than a list now. A mailbox stores mail and has its own login. A forwarder stores nothing and passes mail on.
A catch-all takes mail sent to any address you never created, so it also collects spam and mistyped addresses. The hosting page doesn't list one, so plan on named addresses and forwarders.
| Address | Make it a | Why |
|---|---|---|
| Each person, such as anna@ | Mailbox | Their own login, so nobody shares a password |
| sales@, support@, info@ | Forwarder to the people who answer, or one mailbox if you need a shared history | RFC 2142 lists these as the usual business names, so people guess them |
| postmaster@ | Forwarder to someone who reads it | RFC 5321 requires mail systems to accept this name, and other mail admins write to it when something is wrong |
| abuse@ | Forwarder to someone who reads it | RFC 2142 names it as the place to report bad behaviour from your domain |
| dmarc-reports@ | Its own mailbox | Reports arrive in a machine format and would only clutter a person's inbox |
Forward to mailboxes on your own domain where you can. Sending company mail on to a personal Gmail or Outlook address adds a hop, and Microsoft warns that forwarding can break DMARC alignment. Staff who want everything on one phone can simply add the company mailbox to their mail app.
The four records that decide whether mail arrives
One record brings mail in and three prove the mail you send is genuine. Our platform creates the last three, but knowing what each does is how you catch the mistake that sends invoices to a junk folder.
| Record | Where it sits | What it does | The usual mistake |
|---|---|---|---|
| MX | Your domain | Tells other servers where to deliver your mail; lower numbers are tried first | An old host left in the list, still catching some of your mail |
| SPF | TXT on your domain, starting v=spf1 | Lists the servers allowed to send for you | Two SPF records, or more than 10 lookups: RFC 7208 makes either a permanent error |
| DKIM | TXT at selector._domainkey.yourdomain | Publishes the key that checks the signature on each message | A service that sends for you but never signs with your domain |
| DMARC | TXT at _dmarc.yourdomain | Says how to treat mail that does not pass, and where to send reports | Tightening the policy before every sender passes |
; The shape of each record. Use the values your dashboard shows, not these.
example.com. MX 10 mail.example.net.
example.com. TXT "v=spf1 mx -all"
sel1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
You have two ways to put them in place. Point the domain at our nameservers and we host its DNS, or keep your DNS where it is and add the records the dashboard shows you. If a tool like your shop or invoicing system also sends as your domain, add it to the one SPF record you already have. A second record does not add to the first, it breaks both.
DMARC passes when SPF or DKIM passes for a domain aligned with the one in the From line, which is the address people see. SPF alone checks the hidden envelope sender, so DMARC is what ties the result to your visible name.
What Gmail and Outlook expect from you
Everyday company mail has a short list to meet, and it grows only at bulk volumes. Google asks every sender to Gmail accounts for SPF or DKIM, valid forward and reverse DNS, a TLS connection, properly formatted messages and a spam rate in Postmaster Tools below 0.3%. It also recommends all three authentication records for everyone.
Above 5,000 messages a day to Gmail accounts, Google requires SPF, DKIM and DMARC together, alignment with the From domain, and one-click unsubscribe on marketing mail. Outlook.com sets the same line for domains sending more than 5,000 a day: SPF and DKIM must pass, and DMARC must be at least p=none and aligned. Mail that falls short can go to Junk or be rejected.
Reverse DNS isn't something you set in your own zone. As we read it, it belongs to whoever holds the sending IP address, so on hosted mail that is the host's side and not your domain's records.
Moving your mail without losing any
The safe order is to build everything at the new host first and change where mail goes last. If you are starting fresh with a new domain and have no mail to keep, skip to step 2 and leave out the copying. Coming from a free address, there are no DNS records to move: create the new mailbox, give the new address to your contacts, keep checking the old account for a while, and copy the folders you want to keep as in step 7.
- List everything that sends as your domain. The website contact form, the shop, invoicing, newsletters, even an office scanner. RFC 9989 warns how easy it is to overlook one, and any you miss can fail SPF and DKIM once the new records are live.
- Create the same addresses at the new host, spelled exactly as they are today. Use the CSV import if there are many.
- Copy your DNS zone before you change nameservers, every record except the old MX, and put the MX value your dashboard shows in its place. A nameserver change replaces every record at once, so a subdomain or verification record you forget simply disappears.
- Shorten the TTL on your MX record, ahead of time. TTL is how long the world may cache a record. Lower it at least one old TTL before the move so the change spreads quickly. If you change nameservers instead, the delegation is cached separately and you cannot shorten that from your zone, so expect some mail at the old host for a while (step 6 covers this).
- Make the switch, by changing the nameservers or the MX record. Either way, confirm the MX now shows the value from your dashboard, setting it in the DNS editor if it does not, then send yourself a test from an outside address.
- Keep the old mailboxes open. Cached records can still steer mail to the old host, and under RFC 5321 a sender may keep retrying a delayed message for 4 to 5 days. A week is our own suggested margin; stretch it if mail still turns up.
- Copy the old messages. Our suggestion is to add both accounts to a desktop mail app over IMAP and drag the folders across. Compare folder counts, then do a last pass once the old inbox has gone quiet.
- Only then close the old service.
Getting phones and mail apps connected
Choose IMAP for almost everyone, because it keeps the mail on the server and each device shows the same folders. POP3 was designed for mail to be downloaded and then deleted, per RFC 1939. In our view that suits one computer at most, and we'd add a risk people miss: a message an app has removed from the server is not there for later backups to save.
Take your mail settings from the email you get after ordering. If your app offers a choice, RFC 8314 points you at encrypted connections: 993 for IMAP, 995 for POP3 and 465 for sending. Your settings email has the last word over these general defaults.
Checks for your first week
Run these right after the switch, because a silent delivery fault tends to surface as a customer who never got a quote. Start by reading what the public DNS really says.
# macOS or Linux. Swap in your domain, and sel1 for your DKIM selector.
dig +short MX example.com
dig +short TXT example.com
dig +short TXT sel1._domainkey.example.com
dig +short TXT _dmarc.example.com
# Windows
nslookup -type=mx example.com
nslookup -type=txt example.com
nslookup -type=txt sel1._domainkey.example.com
nslookup -type=txt _dmarc.example.com
- Confirm the MX answer shows only the new host, and that exactly one TXT value starts with
v=spf1. - Send a message to a Gmail address and a personal Outlook.com address you control. In Gmail, open it, choose More, then Show original, and find
spf=pass,dkim=passanddmarc=passin the Authentication-Results line. Thes=value in the DKIM-Signature line is your selector. - Reply from those accounts and confirm the replies reach you.
- Submit your website contact form, and send a test from each tool on your list.
- Write to postmaster@ and abuse@ and check a real person sees it.
Then look at DMARC. If your record says p=none, it only watches, which is where RFC 9989 says owners usually start. Move to quarantine once the reports show all your own mail passing; the RFC warns that this can take many months. Be careful with reject: RFC 9989 says domains used for general-purpose email should not deploy it, especially where users might post to mailing lists, and that it can cause problems for forwarded mail and role addresses too. Older guides suggest stepping up with a pct= percentage, but RFC 9989 removed that tag in May 2026. Reports only arrive if the record carries a rua= address, so if yours has none, add your dmarc-reports@ mailbox in the DNS editor.
When this is the wrong fit
- Bulk newsletters. The hosting page describes mailboxes and says nothing about mass sending, so don't plan a subscriber list around them.
- Shared calendars and contacts. The hosting page lists mail, not calendars or contact sync. If those are part of the job, check before you order.
- Rules on where data sits. The hosting page gives New York as its location. If a contract says your mail must stay in another country, sort that out first.
- Mail for your clients. To give customers their own mailboxes under your brand, look at Nexo, our hosting panel for your own server.
Questions people ask
- Can I buy email on its own, without a website?
- Mailboxes come as part of a web hosting plan; the hosting page lists no email-only plan. You do not need a finished site to start, since a starter page takes one click and you can build the real one later.
- Can my website stay with another company?
- In DNS, yes: mail follows the MX record and the website follows its own records, so the two can point to different places. You can also keep your DNS where it is and add the records the dashboard shows you. Our hosting page does not describe a mail-only setup, so check your case with us on chat before ordering.
- Do I have to register my domain with Primcast?
- No. A name registered anywhere works: point it at our nameservers, or keep your DNS and add the records yourself. If you have no name yet, you can search and register one on our domains page.
- What happens to our addresses if we change host later?
- They stay yours for as long as you keep the domain. You create the same addresses at the new host, change the MX record and copy the mail over, as in the steps above. Keep the domain renewed, because when a domain lapses the addresses on it stop working.
- Will my messages stay out of spam folders?
- Nobody can promise that, because the receiving provider makes the decision. Our platform creates the authentication records. What you control is how you send: mail people who expect it, keep complaints low, and run the checks above. Google's line is a spam rate below 0.3% in Postmaster Tools.
- Someone deleted important mail. Can we get it back?
- Usually, if it was on the server when a nightly backup ran. You restore a mailbox yourself from the dashboard, and how many days and weeks you can go back depends on your plan. Mail that was never on the server at backup time cannot come back this way.