Setting up your domain
The DNS records that make mail arrive and leave authenticated, what each one does, and how to read a failed check.
Before you start
- A domain you control, with access to the DNS provider its nameservers point to.
- Records created at your registrar or an old host are ignored if the nameservers point elsewhere. This is the single most common reason a setup never verifies.
- Mail already running on the domain? Read "Migrating an active domain" below before changing the MX.
The records
The panel shows the exact values for your domain, grouped by whether they are required. Three of them decide whether mail works at all.
| Record | What it does | Required |
|---|---|---|
| MX | Sends mail addressed to your domain to our servers. Without it, nothing arrives. | Yes |
| SPF (TXT) | Authorises our servers to send on your behalf. Without it, your replies land in spam. | Yes |
| DKIM (CNAME) | Signs your outgoing mail. The key lives on our side and rotates without asking you. | Yes |
| DMARC (TXT) | Tells receivers what to do when a message fails the checks, and sends you reports. | Recommended |
| TLS-RPT (TXT) | Reports failed TLS deliveries to your domain. | Recommended |
| SRV | Lets some mail apps configure themselves from the domain alone. | Optional |
The DKIM record is a CNAME pointing into our zone, not the key itself. That is deliberate: we rotate the signing key on our side and your DNS never has to change. If you remove and re-add the domain, the target changes, and the panel shows the current one.
Verifying
Publish the records, then press "Check now". DNS propagation takes minutes, sometimes a few hours. The panel checks each record against your domain authoritative nameservers, so it sees the current truth rather than a cached copy.
- MX passes. Mail addressed to your domain now reaches us.
- SPF and DKIM pass. Mail sent from your mailboxes is authenticated, and receivers can tell it is really you.
- The domain turns Receiving. You can create mailboxes on it. Until then, the mailbox form is not offered.
Common mistakes
- Two SPF records. Publishing a second one does not add to the first: it invalidates both. Edit the existing record and add our include to it.
- Two DMARC records. Same rule: with more than one, receivers treat your domain as having no policy at all.
- Mixed MX. Leaving an old provider MX next to ours splits your mail unpredictably, because the sender picks either. Delete the old ones.
- Proxy enabled on the DKIM CNAME. At Cloudflare, keep it grey (DNS only). Proxied, it stops resolving as a CNAME and the signature breaks.
- SRV pasted as one string. Most panels have separate fields for priority, weight, port and target; pasting all four into the value creates an invalid record.
Migrating an active domain
Changing the MX redirects new mail immediately, so the switch comes after the mailboxes exist, and before the history import, not after it. The full walkthrough, including the import and its follow-up syncs, is on the "Migrating from another provider" page.
- Publish SPF and DKIM first. They do not affect delivery to your current provider, and they are ready when you need them.
- Create the mailboxes here. Every address that receives mail today. After the switch, mail to an address that does not exist here is returned to the sender.
- Then change the MX. New mail starts arriving here. The window where a message can land on the old side is the DNS propagation: minutes to hours, not the days a mailbox copy takes.
- Import the old mail after the switch. Folders and read state come over IMAP in the background, and follow-up syncs run for a week to catch what the old provider received late.