Domain plans
Domain setup guide
Your domain’s DNS is the switchboard that tells the rest of the world where your mail lives. To put your domain on MailToYou you add a handful of records at whoever runs your DNS. This page walks through every one of them, what it does, and the mistakes that cost people a day of bounced mail.
You need about fifteen minutes, and the sign-in details for wherever your domain’s DNS is managed — usually the registrar you bought it from.
Step one of understanding it
What you’re doing, and why
Prove the domain is yours
Anybody can type a domain name into a signup form. Before we will accept mail for your domain, you have to show you control it — and the only thing only the owner can do is publish a DNS record on it.
That is the verification record: a TXT record holding a token unique to your account. Our mail platform looks it up, sees its own token, and flips your domain to active. Until that record resolves, your domain sits waiting and the domain administrator sign-in will not work.
Route your mail to us
Two directions, two sets of records.
Incoming mail is directed by your MX records. They tell every sending server on the internet “deliver mail for this domain here”. Change them and mail for your domain starts arriving at our filtering servers instead of your old provider.
Outgoing mail needs records that prove we are allowed to send as you — SPF, DKIM and DMARC. Without them, mail you send is liable to land in spam or be rejected outright, because the receiving server has no way to tell you apart from somebody forging your address.
Those three are not optional extras. Our servers sign your outbound mail whether or not DNS knows about it, so a missing DKIM record does not mean “no DKIM” — it means failed DKIM, which is worse.
You may have nothing to do at all
If your domain’s DNS is on the same Cloudflare account we manage, we publish every one of these records for you automatically when your plan is set up, and your activation email says so. Read this page anyway if you want to understand what changed — but you can skip the typing.
The records
The records, one at a time
Your activation email contains this same set with your values filled in. Where a value is unique to your domain it is marked like this below, with a note on where to find the real one.
MX — where your incoming mail goes
Four records, all on the same name, each with a priority. Senders try the lowest priority number first and fall back to the higher ones if those are busy or unreachable. Two at 10 and two at 20 gives you a primary pair and a backup pair.
| Type | Name | Value | Priority |
|---|---|---|---|
| MX | @ | mx1.mxfilter.net | 10 |
| MX | @ | mx2.mxfilter.net | 10 |
| MX | @ | mx3.mxfilter.net | 20 |
| MX | @ | mx4.mxfilter.net | 20 |
All four are spam-filtering relays: mail is scanned there and then passed to your mailboxes. Add all four — running on fewer works until the day one of them is down for maintenance.
Delete your old provider’s MX records once these are in. Leaving them is the single most common reason people say “some of my mail is missing” after switching: it is not missing, it is sitting in the old mailbox.
SPF — who is allowed to send as you
One TXT record on your domain’s root, listing the servers permitted to send mail with your address in the From line. Receiving servers check it on every message.
| Type | Name | Value |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.workspace.org ~all |
Reading it left to right: v=spf1 says which version of SPF this is, include:_spf.workspace.org pulls in the list of our sending servers, and ~all means “anything else is a soft fail” — treat it as suspicious rather than reject it outright. That softer ending is deliberate while you are settling in.
If your domain already has an SPF record, do not add a second one. The next section is about exactly this, and it is the one thing on this page that will break your mail if you get it wrong.
The verification record — proving the domain is yours
A TXT record on the subdomain workspace-verification, holding the token for your account.
| Type | Name | Value |
|---|---|---|
| TXT | workspace-verification | your verification token |
Where your real token is: in your activation email, in the DNS record list, on the workspace-verification row. It looks like a long string of letters, numbers and hyphens. If you cannot find the email, ask us and we will resend it — do not guess and do not copy one from anywhere else, because a token identifies an account, and the wrong one points your domain at somebody else’s.
Two details that catch people out. First, the record goes on the subdomain workspace-verification, not on your root domain — so the full name ends up as workspace-verification.yourdomain.com. Second, paste the token on its own, with no quotation marks; some control panels add quotes for you and a doubly-quoted value does not match.
DKIM — the cryptographic signature on your mail
Our servers add a signature to every message you send. This TXT record publishes the public half of the key so receiving servers can verify that signature and know the message really came from you and was not altered in transit.
| Type | Name | Value |
|---|---|---|
| TXT | your-selector._domainkey | v=DKIM1; k=rsa; h=sha256; p=your public key |
Where your real values are: both the selector and the key are in your activation email. You can also read them at any time in webmail as your domain’s administrator, under Settings → Domain Settings → Email Signing.
Every domain has its own selector and its own key. They are not shared and they are not guessable — copying another domain’s makes every signature fail verification. The key itself is a long unbroken block of base64; paste it whole, with no line breaks or spaces introduced, and keep the v=DKIM1; k=rsa; h=sha256; p= prefix in front of it.
DMARC — what receivers should do when a check fails
SPF and DKIM produce a pass or a fail. DMARC is where you say what should happen to a failing message, and where reports about it get sent.
| Type | Name | Value |
|---|---|---|
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com |
p=none means monitor only: nothing gets blocked, but you start receiving reports. That is deliberately where you begin. Once you have watched for a week or two and confirmed that your real mail is passing SPF and DKIM — including anything else that sends as your domain, like a newsletter tool or a website contact form — you can tighten to p=quarantine (failures go to spam) and eventually p=reject (failures are refused).
Do not start at p=reject. With one record still propagating, or a forgotten third-party sender, you will be rejecting your own mail and the only clue will be an angry customer.
The rua= address is simply where the daily XML reports land; point it at a mailbox you can actually read, or a folder you will not mind filling up.
All five together
The complete set, for reference while you work. Substitute your own values for the marked fields.
| Type | Name | Value |
|---|---|---|
| MX | @ | mx1.mxfilter.net · priority 10 |
| MX | @ | mx2.mxfilter.net · priority 10 |
| MX | @ | mx3.mxfilter.net · priority 20 |
| MX | @ | mx4.mxfilter.net · priority 20 |
| TXT | @ | v=spf1 include:_spf.workspace.org ~all |
| TXT | workspace-verification | your verification token |
| TXT | your-selector._domainkey | v=DKIM1; k=rsa; h=sha256; p=your public key |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com |
Leave the TTL at whatever your DNS host defaults to. A short TTL (300 seconds or so) is handy while you are making changes, because a mistake corrects itself faster.
Read this one
🔴 Exactly one SPF record. Never two.
Two v=spf1 records is not “two chances to pass” — it is a hard error
A domain is allowed exactly one SPF record. When a receiving server finds two, it does not pick one or merge them. It returns permerror — a permanent failure — and your domain has effectively no working SPF at all. Paired with a strict DMARC policy, that means legitimate mail you send gets rejected.
This is not theoretical. We have found live domains carrying four and even five SPF records, including ones with stale includes from providers they left years ago, quietly failing authentication the whole time. It is the single most common self-inflicted mail outage there is.
So if you already have an SPF record, merge — don’t add
Say your domain currently has this, because a marketing tool sends for you:
v=spf1 include:example-sender.com ~allThe wrong move is to add our record next to it. The right move is to edit that one record and put our include: inside it:
The rules for merging are short:
One record, one v=spf1 at the front. It appears once, at the very start, and nowhere else.
Keep every include: you still need — and take this as your cue to drop the ones you don’t. Each include costs a DNS lookup, and SPF allows a maximum of ten before it fails. Stale includes from old providers eat that budget for nothing.
One ending, at the end. Exactly one ~all or -all, as the last thing in the record. Anything after it is ignored, which is a silent way to lose half your record.
If you are unsure what your current record means or whether something still needs to be in it, send us the domain and we will read it for you. It takes two minutes and it is much cheaper than finding out from a bounce.
The same rule, in miniature, for DMARC and DKIM
DMARC: also exactly one record, on _dmarc. Two is the same kind of error.
DKIM: different — DKIM records live on their own per-selector names, so several can coexist happily. If you sign with two services, each has its own selector and its own record, and neither interferes with the other.
Where you actually type it
Notes for your registrar
Every control panel asks for the same information and every one of them labels it differently. The trap they share is the Name field.
The @ versus blank versus full-domain trap
When we write @ in the Name column, that means “your domain itself” — not a subdomain. Panels disagree about how to express that: some want a literal @, some want the field left empty, and some want the whole domain typed out.
And the mirror-image problem for subdomain records: most panels append your domain automatically. So to create workspace-verification.yourdomain.com you type only workspace-verification. Type the full name into a panel that appends, and you get the silent, maddening workspace-verification.yourdomain.com.yourdomain.com — which resolves to nothing, so verification simply never passes.
How to be sure, in ten seconds: save the record, then look at how the panel displays it in the list afterwards. Good panels show you the fully-qualified name they built. If it reads your domain twice, that is your answer.
Cloudflare
Where: your domain → DNS → Records → Add record.
Name field: type @ for the root — Cloudflare accepts it and displays the domain name. For subdomains type just the label (workspace-verification, _dmarc, your-selector._domainkey); it appends the domain.
MX: the priority box appears once you pick type MX. Add the four records one at a time.
Proxy status: MX and TXT records have no proxy toggle, so there is nothing to get wrong. If your root A/CNAME record is proxied (orange cloud), that is about your website and does not affect mail.
TXT quoting: paste the bare value. Cloudflare handles the quoting; typing your own quotes stores them as part of the value.
GoDaddy
Where: My Products → your domain → DNS / Manage DNS → Add New Record.
Name field: GoDaddy requires a literal @ for the root — leaving it blank is rejected. Subdomain records take the label only; GoDaddy appends the domain.
MX: the target goes in Value and the number in Priority. GoDaddy accounts often arrive with its own MX records already present — delete those, or mail keeps going to a mailbox nobody reads.
Watch for: a pre-existing SPF record, especially on domains that ever had Microsoft 365 or Workspace attached. Edit it, do not add beside it.
Namecheap
Where: Domain List → Manage → Advanced DNS → Add New Record.
Host field (their name for Name): @ for the root. Subdomains take the label only.
Before anything else: check the Mail Settings dropdown on that page. If it is set to Email Forwarding or Private Email, Namecheap manages the MX records itself and will overwrite or ignore yours. Set it to Custom MX first, then add the four MX records.
MX: the priority column is labelled Priority or sometimes MX Pref. Same numbers either way.
Google Domains / Squarespace Domains
Google Domains registrations moved to Squarespace, so the panel you get depends on when you last looked. Both work the same way.
Where: your domain → DNS → DNS Records / Custom records.
Host field: leave it blank for the root, or type @ — both are accepted, and the list will show the root record with just the domain. Subdomains take the label only.
MX: older Google-style panels let you put all four targets in one multi-line MX entry, each line as 10 mx1.mxfilter.net. Newer Squarespace panels want four separate records with a Priority box. Either shape is fine as long as all four targets and both priority values end up published.
Watch for: a leftover v=spf1 include:_spf.google.com ~all from Gmail. Merge or remove it — do not leave it as a second record.
Porkbun
Where: Domain Management → your domain → DNS Records.
Host field: leave it blank for the root. Porkbun shows the domain greyed out beside the box to make this clear, and appends it to whatever you type — so subdomains are the label alone.
MX: the priority field appears when you choose MX from the type dropdown.
Watch for: Porkbun’s default records on a fresh domain, including its own parking and email-forwarding entries. Clear the MX ones out before adding yours.
Somewhere else, or you’re not sure where your DNS is
The records are the same wherever you are; only the labels change. Look for DNS, Advanced DNS, Zone editor or Name server records.
If you don’t know who runs your DNS: it is whoever your nameservers point at, which is not always the registrar you bought the domain from. A common case is a domain bought at one registrar but pointed at a web host’s nameservers — in which case the records must go in at the web host, and anything you add at the registrar is ignored entirely.
Tell us the domain and we will tell you where its DNS actually lives.
Confidence
How to check it worked, and how long it takes
How long propagation takes — honestly
Usually minutes. Sometimes a few hours. Occasionally longer. We would rather tell you that than promise you five minutes.
The reason for the range is caching. Your new record is published instantly at your DNS host, but every resolver that already looked up your domain holds its previous answer until that answer’s TTL expires — and until then it keeps serving the old one. If your TTL was a day, some of the internet takes a day to notice. Records on names that never existed before, like workspace-verification, tend to appear fastest, because there is no stale answer to expire.
What to do with that: if a record is not visible after a few hours, do not assume it needs changing. Check the record first — a typo looks exactly like slow propagation, and re-typing a correct record resets nothing but your own confidence.
Check it yourself
The easiest check needs nothing installed: look your domain up with any public DNS lookup tool in a browser and compare what comes back against the table above.
If you have a terminal to hand, these four answer the whole question. Replace yourdomain.com with your domain.
What you want to see:
MX: four lines, mx1 through mx4, priorities 10, 10, 20, 20 — and no sign of your old provider.
TXT on the root: exactly one line beginning v=spf1. If two come back, stop and fix that before anything else. This one-liner counts them for you, and the answer must be 1:
Verification: your token, on the workspace-verification subdomain. An empty answer here is the usual reason a domain stays unverified. Remember an apex-only lookup will wrongly report “none” — the record is on the subdomain.
DMARC: one record starting v=DMARC1.
DKIM lives on your-selector._domainkey.yourdomain.com; the same dig +short ... TXT works once you substitute your selector.
The test that actually matters
DNS looking right and mail working are two different claims. Once the records resolve, prove it end to end:
Send yourself a message from an outside account — any free webmail will do — to an address on your domain, and confirm it arrives.
Then reply to it from your new mailbox, and check that the reply arrives too. Open the received copy’s original headers and look for spf=pass and dkim=pass. That is authentication working, not merely configured.
Or skip all of it and ask us to check. We read the live records, tell you exactly what is wrong, and it takes us two minutes.
Then what
What happens after verification passes
Your domain goes active, and you get the keys
Once the verification record resolves, your domain flips to active on our platform and your domain administrator sign-in starts working. Nothing to click — it happens on its own.
From there you have two places to work, and they do different jobs:
The customer portal is where you add and remove mailboxes, create aliases and forwarders, and set storage limits across every domain on your account.
Webmail is for reading and sending, and also holds the domain administrator settings — including Settings → Domain Settings → Email Signing, where your DKIM selector and key live if you need to look them up again.
Mailboxes and domain aliases are unlimited on every domain plan. Only your primary-domain count and total pooled storage are capped.
Bring your old mail with you
In webmail, Settings → Mailbox Migration copies everything from your old provider over IMAP, folders and all, free on every plan. If you are still receiving at the old address while DNS settles, Fetch Mail pulls new messages in on a schedule.
The tidy order is: get the new mailboxes working, migrate the old mail, confirm nothing new is arriving at the old provider, then close the old account. Do it the other way round and there is a gap where mail bounces.
Two more things, once you are settled
Tighten DMARC. After a week or two of clean reports at p=none, move to p=quarantine, and later p=reject. This is the step everyone means to do and nobody does; it is what actually stops people forging your domain.
Know where the spam quarantine is. Filtered mail is held at portal.mxfilter.net, where you can review and release anything caught by mistake. Sign in with your full email address.
Full day-to-day guide: managing your account.
Learn from ours
Common mistakes
Every one of these has happened on a real domain. None of them announce themselves — they just quietly break mail.
- Adding a second SPF record instead of merging. The big one. Two
v=spf1records means permerror, which means no working SPF, which under a strict policy means your own mail gets rejected. Merge the includes into one record. - Pasting the token or key with quotation marks around it. Some panels quote TXT values for you. Add your own on top and the stored value contains literal
"characters, so nothing matches. Paste the bare value and check how the panel displays it afterwards. - Typing the full name into a panel that appends the domain. Produces
workspace-verification.yourdomain.com.yourdomain.com, which resolves to nothing at all, so verification never passes and there is no error message anywhere. Enter the label alone. - Using the wrong record type. SPF, DKIM, DMARC and verification are all TXT records — not CNAME, and not the deprecated “SPF” record type some older panels still offer. Mail routing is MX, pointing at a hostname; never an IP address.
- Forgetting to remove the old provider’s MX records. Mail keeps flowing to the old mailbox, sometimes for months, and it looks like random message loss rather than a misconfiguration. Delete them once yours are in.
- Missing out the DKIM record because “it’s optional”. It is not. Our servers sign every outbound message whether DNS knows the key or not, so a missing record means receivers see a signature they cannot verify — a DKIM failure, which is worse than no DKIM at all.
- Copying another domain’s DKIM selector or verification token. Both are per-account values. A borrowed selector fails every signature check; a borrowed token points your domain at somebody else’s account.
- Jumping straight to
p=rejecton DMARC. With one record still propagating or a forgotten third-party sender, you are rejecting your own mail. Start atp=noneand tighten once the reports are clean. - Only adding two of the four MX records. It works right up until one of those two is unreachable, and then mail queues or bounces for a reason that has nothing to do with the change you made weeks earlier.
- Editing DNS at the registrar when the nameservers point elsewhere. The records save cleanly and are never served. Find out who answers for your domain before you type anything.
Still stuck?
Send us the domain name before or after you switch and we will read the live records and tell you what is wrong. It takes us two minutes and it saves a great deal of bounced mail.
Ask us to check your records Managing your account
Questions go to support@mailtoyou.org — real people who run the mail servers, usually replying within one working day.