Why this lives outside the panel

Mila hosts your mail, but your domain's DNS is controlled wherever you registered or point that domain -- a registrar, a separate DNS host, or your own name servers. The panel can generate the exact record values a domain needs and verify them once they're published, but publishing them happens on your DNS provider's side. This guide explains what each record does so the panel's DNS page isn't a wall of unfamiliar acronyms.

MX: where mail gets delivered

The MX record is what tells the rest of the internet's mail servers where to send messages addressed to your domain. Without a correct MX record, mail sent to your addresses has nowhere to go and bounces back to the sender -- this is the one record that has to be right before anything else works. Copy the exact host and priority the panel's Domain > DNS page shows for your domain; it's generated per domain rather than being a fixed value.

SPF: who's allowed to send as your domain

SPF is a TXT record listing which mail servers are authorized to send mail claiming to be from your domain. Receiving servers check the sending server's IP against it and treat unlisted senders with more suspicion -- this is one of the main defenses against someone forging your domain in the From header. If you send from other services in addition to Mila (a marketing tool, an invoicing system), all of them need to be included in the same SPF record; a domain can only have one.

DKIM: signing outgoing mail

DKIM attaches a cryptographic signature to every message your domain sends, generated from a private key Mila holds and verified against a public key published in your DNS. A receiving server that can verify the signature knows the message wasn't altered in transit and really did originate from infrastructure authorized to sign for your domain. The panel generates the DKIM keys per domain and shows you the exact records to publish under Domain > DNS > DKIM -- there's nothing to configure beyond publishing them.

Mila signs every outgoing message twice, with two different key types: a modern ed25519 key (the key1/key2/key3 records) and a classic RSA-2048 key (the rsa1/rsa2/rsa3 records). Some large providers -- Microsoft 365/Outlook most notably -- still don't verify ed25519 signatures; the RSA signature is the one they check. Publish BOTH sets: every receiver then verifies at least one signature, which is what keeps your mail out of spam folders at strict recipients. (Three records per key type exist so Mila can rotate keys server-side later without you ever touching DNS again.) If your DNS provider limits TXT values to 255 characters per string, split the longer RSA value into two quoted strings -- most providers, including Cloudflare, do this automatically when you paste the full value.

DMARC: what to do when a check fails

DMARC is a TXT record at _dmarc.yourdomain.com that tells receiving servers what policy to apply to mail that fails SPF or DKIM (quarantine, reject, or do nothing) and, optionally, where to send aggregate reports about mail claiming to be from your domain. It only has teeth once SPF and DKIM are both in place -- set those up first.

Optional: SRV records for client auto-discovery

A domain can also publish SRV records that point at Mila's mail infrastructure by service name rather than requiring every mail client to be configured by hand: an autodiscover record, plus records for IMAP, POP3, and SMTP submission. Clients that support this (see Email client settings) can pick up the right host and port on their own. These are optional -- skip them and enter settings manually if you'd rather not add extra records.

Verifying

The panel's Domain > DNS page re-checks every record for a domain live and flags anything missing or misconfigured by name, so you can fix one record at a time and re-run the check rather than guessing which one is wrong.

When a domain is already registered here

A domain name can only be held by one account on Mila at a time, so adding a domain someone else already added is refused. That is usually not a mistake -- domains change hands. A company is acquired, an agency hands a client their own domain back, a supplier relationship ends.

The way out is a claim, from Domains > Add domain > "Claim it with a DNS record". You are given the ordinary TXT verification record to publish at your domain's root -- the same record any new domain needs. Once it's published, Mila reads it back through several independent public resolvers and, if enough of them agree, moves the name to your account.

No permission from the previous account is asked for or required. A deliberate, consensual transfer also exists (Domain > Transfer, using the receiving account's transfer code) for when both sides are cooperating -- but a domain can never be held hostage by an account that simply refuses to release it.

The reason a DNS record is enough is that controlling a domain's DNS is controlling the domain -- there is nothing a previous holder could show that would outrank it. It is also the previous holder's protection: while they still control the zone, nobody else can publish that record, so no claim can succeed.

What you receive is an empty domain in "pending" state: you still publish MX, SPF and DKIM and activate it yourself, and nothing is inherited. The one thing you do not repeat is the verification record -- the domain adopts the token you already published, so it arrives verified. The previous holder's mailboxes and stored messages do not move to you -- they cannot exist alongside your own mail for the same addresses, so their messages are removed and their configuration record is kept for 30 days. They are notified by email when it happens.

What happens if DNS stops verifying

Mila re-checks every domain's DNS on a schedule. If a domain's verification TXT and its MX both disappear -- meaning the name no longer points at Mila in any way -- that domain starts a clock.

Nothing happens quickly, and nothing happens silently. After two weeks the account's owners and admins get an email naming the exact records that are missing and the date the domain would be scheduled for deletion. Two weeks after that, a second and final notice. Only after six weeks of continuous failure is the domain scheduled for deletion, and scheduling is still not the deletion itself: a further grace period follows, during which cancelling restores everything.

Publishing the records again at any point stops the process and resets the clock. A domain that was never activated runs on a shorter version of the same ladder, since there is no mail to interrupt.

If a check fails because Mila could not reach DNS at all, that does not count against a domain -- only a definitive "these records are not there" does.