MX, SPF, DKIM, DMARC, MTA-STS and the discovery records nobody sets up by hand. What each one does, the two families we deliberately leave out of what we recommend, and why our checker merges your existing SPF record instead of telling you to replace it.
Setting up email on your own domain means publishing DNS records, and DNS is where most migrations quietly go wrong. Not because the records are hard, but because there are more of them than anyone expects, several are long strings of cryptographic material, and getting one subtly wrong means mail keeps working right up until the day it doesn't.
So we took the position that you should never have to research this. When you add a domain to email.eu, we generate the exact record set your domain needs, show you what is published today, and tell you which ones still need fixing. This post is what those records are, what we deliberately leave out, and how the checking works.
The short answer: about twenty records, in six families. Here is what each is for, in plain terms.
| Record | What it does |
|---|---|
| MX | Points the internet at the servers that accept mail for your domain. Without it, nothing arrives. |
| SPF | Lists who is allowed to send as you. Receivers use it to reject forgeries. |
| DKIM | Publishes the public half of a signing key, so receivers can verify your mail was not altered in transit. |
| DMARC | Tells receivers what to do when SPF and DKIM disagree, and where to send you reports about it. |
| MTA-STS and TLS-RPT | Say that mail to your domain must be delivered over TLS, and where to report it when it cannot be. |
| SRV and CNAME | Let mail clients discover your server settings automatically instead of asking your users to type them. |
That last family is the one almost nobody sets up by hand, and it is the difference between a colleague typing an address and being done, or a colleague typing an address and then hunting for port numbers.
The mail server itself knows what it needs. Stalwart, the mail server behind email.eu, can emit a complete zone for a domain the moment that domain exists, including the DKIM key it just generated for you. We take that zone, parse it, and turn it into two things: a readable table in your dashboard, and a copy-paste zone file that most DNS providers will import in one go.
What we do not do is reach into your DNS and write records ourselves. That would mean holding API credentials to your registrar, which is a large amount of access to ask for so that we can save you one paste. Your domain stays yours. We tell you exactly what to publish, and then we check that you did.
The raw zone the mail server generates has roughly fifty-eight records in it. We show you about twenty-two. The difference is two families we deliberately drop, and both decisions are worth explaining, because "our system generated it" is not a reason to hand you something that will hurt later.
DANE records (TLSA). DANE pins your mail server's exact certificate in DNS. It is genuinely good security, and it is a trap for hand-published DNS, because the pin has to be republished every time the certificate renews. With certificates that renew roughly every sixty days, a DANE record you pasted once and forgot is a record that will silently start rejecting your mail. We are not going to hand you a time bomb with a two-month fuse, so those records are left out.
CAA records. A CAA record says which certificate authority is allowed to issue certificates for your domain, and it governs your entire domain, not just its mail. The version a mail server generates points at that mail server's own certificate account. Publish it and you have quietly told the world that only our mail server's account may issue certificates for your company, which includes the certificate on your website that has nothing to do with us. Certificate policy for your domain is your decision to make deliberately, not a side effect of setting up email. So we leave CAA alone.
That is the general rule we apply: the record set we recommend is the set that works, keeps working without maintenance, and only concerns mail.
Once you publish, we check. Every record gets one of a few honest verdicts: published correctly, missing, or present but different from what we expect. Missing and different are separate answers on purpose, because they need different reactions from you.
SPF is where a checker earns its keep. A domain can only have one SPF record, so if you already send invoices through your accounting system and newsletters through a mailing tool, your SPF record already exists and already lists them. A naive checker sees that our suggested record is not there, tells you it is missing, and now you are being advised to break your invoices.
Ours does the correct thing instead. It reads what you have published, checks whether it already authorises us, and if not, it builds the merged record you should actually publish: your existing senders, plus us, with your own policy at the end. If you chose softfail rather than hard fail, we keep your choice. That is your call about your domain, not ours.
Before any of that, there is one small record that does something different: a verification token at _email-eu-verify on your domain. It exists so that nobody can add your domain to their workspace and start receiving your mail. Publish it, we look it up, and the domain is yours in our system.
From there the whole sequence looks like this.
We keep those steps honest at the last one in particular. Clicking "go live" does not make your dashboard claim you are live. It says you are live once a DNS check has actually seen the world's MX record pointing at us. Intent and reality are two different things, and a status page that confuses them is worse than no status page.
One more detail that matters over the long run: your record set is re-derived from the mail server every time you open the domain page, not frozen at the moment you signed up. When the mail cluster grows a second MX host, or a client discovery record moves, the page you copy from is already showing the new truth. Nobody has to email you a correction.
None of this is glamorous. It is the part of leaving your old provider where people give up, or worse, half-finish and spend a year with mail that mostly delivers. Making it a table, a paste, and a checker turns a research project into an afternoon.
If you want to see the actual record set for your own domain before committing to anything, that lives behind the first step of signing up, and the weekend migration guide walks the whole cutover end to end.