Email

An address on your own domain - hello@yourbrand.com - reads as more credible than a free mailbox and keeps the brand in front of every person you write to.

Domain mail depends on three DNS records: MX decides where mail is delivered, SPF and DKIM decide whether your mail is trusted, and DMARC tells the receiving side what to do with mail that fails.

Addresses on your brand The address ends in your own domain

Three record types MX, SPF and DKIM must all be right

Any device Phone, desktop and webmail

Documented setup Step-by-step for the common clients

What it is

Domain mail needs two things working together: the mailbox service itself, and the DNS records that tell the world where to deliver and whether to trust what you send.
MX records say which server accepts mail for the domain. Point them at your mail provider and messages arrive.
SPF and DKIM demonstrate that the mail really was sent by someone authorised to use the domain, which is what keeps it out of spam folders. DMARC tells receivers what to do when neither checks out.
Mail clients connect over IMAP to read and SMTP to send. The server names, ports and encryption settings are in the setup guide.

How it works

01

Confirm the mail service

Establish which service you are using and the exact record values it requires.

02

Publish the records

Add MX, SPF and DKIM, and a DMARC record if you want reporting.

03

Configure the client

Enter the IMAP and SMTP settings on the phone or desktop.

04

Test both directions

Send from an outside mailbox to yours, then reply, and check both arrive.

Addresses that match the brand

Recipients see your domain, not a free mailbox.

Records in one place

MX, SPF, DKIM and DMARC edited in the domain DNS.

Written setup steps

The common clients, step by step.

Kept with the domain

No second control panel to remember.

Troubleshooting path

Not receiving, not sending and landing in spam each have an order to work in.

Survives a transfer

DNS stays put when a domain moves registrar.

What each of the four records does

One wrong record and mail misbehaves

Record	Purpose	Symptom when wrong
MX	Names the server that accepts mail	Nothing arrives at all
SPF (TXT)	Lists the servers allowed to send as your domain	Your own mail lands in spam
DKIM (TXT)	Publishes the key that signs your outgoing mail	Mail is treated as suspicious
DMARC (TXT)	Says what to do with mail failing the checks, and where to report	No reports, and no way to tighten policy safely

A domain normally has one set of MX records pointing at one mail service. When changing providers, remove the old records rather than adding the new ones alongside them.

Troubleshooting, in order

Work from the outside in

Nothing arrives: check the MX record, then send a test from a mailbox outside your domain.
Receiving but not sending: usually the SMTP host, port or password, and sometimes SPF not including the sending server.
Your mail lands in spam: check SPF and DKIM against the server you actually send through, then tighten DMARC gradually.
One device works and another does not: the server name or encryption setting on that device is usually wrong.
Mail is missing after switching providers: on IMAP the previous provider does not copy mail across; it has to be exported and imported.

Domain mail compared with forwarding

Two approaches with different trade-offs

Forwarding simply sends mail addressed to your domain on to a real mailbox somewhere else. It is quick to set up and needs no extra mailbox, but every reply you send goes from the forwarded address and exposes the real one behind it.

Domain mail is a mailbox of its own: the storage, the folders and the signature are yours. For anything customer-facing, that is the version worth having.

Mail security worth doing

If the mailbox falls, the domain is at risk

Give the mailbox its own strong password, not the one used for the domain account.
Turn on two-factor authentication for the mailbox.
Review forwarding rules periodically - attackers use them to keep reading mail long after a password is changed.
The registrant mailbox matters most: it decides whether a domain transfer can be confirmed.

What every order includes

DNS record management

MX, SPF, DKIM and DMARC in the domain DNS.

Client setup guide

iOS, Android, Outlook and the rest.

Server and port reference

IMAP and SMTP hosts, ports and encryption settings.

Troubleshooting order

A sequence to follow rather than guessing.

Mail and domain together

One place for renewals and DNS.

Unaffected by transfers

Nameservers stay put when the domain moves.

Common questions

Does domain mail cost extra?

The cost depends on the mail service and plan you choose. Our part is the domain, the DNS records and the configuration guidance; whether an extra charge applies is shown at checkout.

How long after setup does mail start arriving?

MX changes propagate in minutes to hours depending on DNS caching. Wait a little, then send a test from a mailbox outside your domain.

Can I just forward to a free mailbox instead?

Yes, forwarding covers receiving and costs less. But replies go out from the forwarded address, which is less convincing for brand use. A real domain mailbox is the better choice for anything customer-facing.

Why is my mail going to spam?

Usually SPF does not list the server you send through, or DKIM is missing or the signature does not match. Work through the setup guide and confirm the sending server appears in the records.

Will transferring the domain break mail?

Not if the nameservers and MX records stay as they are. A transfer changes the registrar, not the DNS.

Please note

Editing MX records affects delivery immediately. Do it at a quiet time, with the new values ready before you start, so there is no window where mail cannot be delivered.
The registrant mailbox decides whether a domain transfer can be confirmed. Use an address you control long term and protect it with its own second factor.