How to Set Up a Custom Domain With an Encrypted Mail Provider

A custom domain is the single most portable thing you can do for your email. [email protected] belongs to you in a way that [email protected] never will — switch providers in five years and the address moves with you. This guide walks through connecting a domain to an encrypted provider end to end, including the DNS records people skip and then wonder why their mail lands in spam.

The steps are the same in shape for Proton Mail and Tuta; the exact record values come from your provider’s dashboard. We’ll use Proton Mail’s flow as the reference because its values are well documented, and note where Tuta differs.

Before You Start

You need two things:

1. A domain you control, registered at a registrar (Namecheap, Porkbun, Cloudflare, etc.) where you can edit DNS records.
2. A paid plan at the encrypted provider. Custom domains require a paid tier on both Proton Mail and Tuta — the free plans use the provider’s own domain only.

Keep two browser tabs open throughout: your provider’s domain settings, and your registrar’s DNS console. Every step is “copy a value from the provider, paste it into the registrar.”

Step 1: Add and Verify the Domain

In Proton Mail, go to Settings → Domain names → Add domain and enter your domain. The provider gives you a verification TXT record — a string like protonmail-verification=....

In your registrar’s DNS console, add a TXT record with the host set to @ (your root domain) and the value set to the string the provider gave you. Save it.

Verification can take from a few minutes to a few hours depending on your domain’s existing TTL settings. The provider checks automatically and shows a green check when it sees the record. This step only proves you own the domain — no mail flows yet.

Step 2: Create Your Addresses First

This is the step people do out of order and regret. Create your email addresses at the provider before you change MX records.

Add [email protected] (and any others you want) in the provider’s dashboard now. The reason: once MX records point mail to the provider, any message sent to an address that doesn’t exist there won’t be delivered. Creating the addresses first means there’s a mailbox waiting when the mail starts arriving.

Step 3: Point MX Records to the Provider

MX (Mail Exchanger) records tell the internet which servers receive your domain’s mail. The provider gives you one or more MX records with priority values.

In your registrar:

1. Delete any existing MX records for the domain (or ensure the provider’s records have the lowest — i.e., highest-priority — number). Leftover MX records from a previous host will misroute mail.
2. Add each MX record the provider specifies, with the exact hostname and priority value shown.

Once these propagate, incoming mail to your domain routes to the encrypted provider. This is the moment your custom-domain mailbox goes live.

Step 4: Add SPF, DKIM, and DMARC (Don’t Skip This)

These three records are what keep your outgoing mail from being rejected or dumped in spam by Gmail, Outlook, and every other major receiver. They are not optional in 2026 — large providers increasingly reject unauthenticated mail outright.

SPF (Sender Policy Framework) authorizes the provider’s servers to send mail as your domain. Add the single TXT record the provider gives you. Critical rule: you may have only one SPF record per domain. If one already exists, merge the provider’s include: into it rather than adding a second.

DKIM (DomainKeys Identified Mail) lets the provider cryptographically sign your outgoing mail so receivers can verify it wasn’t forged. Proton Mail uses three CNAME records for DKIM — add all three, each with the hostname in the Name field and the provider’s value in the Target field.

DMARC ties SPF and DKIM together and tells receivers what to do with mail that fails. Add the TXT record at the _dmarc host. A reasonable starting policy is p=quarantine (suspicious mail goes to spam rather than the inbox); many guides suggest beginning at p=none to monitor before tightening. You can move to p=reject later once you’ve confirmed legitimate mail passes.

Step 5: Wait for the Green Checks

Back in the provider’s domain settings, each record (verification, MX, SPF, DKIM, DMARC) gets a status indicator. The provider re-checks periodically. If a record isn’t authenticated immediately, give DNS propagation up to 24 hours before troubleshooting — most “it’s not working” reports are just propagation delay.

When every record shows verified, you’re done. Send a test message to a Gmail address and reply from it to confirm both directions work.

Tuta Differences Worth Knowing

Tuta’s flow follows the same five steps — add domain, verify, set MX, add SPF/DKIM/DMARC — but the exact record values come from Tuta’s dashboard, and Tuta additionally encrypts the subject line of mail stored on its servers, which Proton Mail does not. If subject-line confidentiality matters to you, that’s a point in Tuta’s favor; the DNS setup itself is equivalent.

Common Mistakes

A handful of errors account for most failed setups:

• Two SPF records. Only one is allowed. A second silently breaks authentication. Merge, don’t add.
• Old MX records left in place. They misroute incoming mail. Delete them.
• Skipping DKIM/DMARC. Mail “works” at first, then starts landing in spam as receivers tighten enforcement.
• Changing MX before creating addresses. Mail to not-yet-created addresses bounces.
• Impatience. Most “broken” records just need propagation time. Wait the 24 hours before re-doing anything.

The Payoff

Once it’s done, your encrypted mailbox lives behind an address you own outright. The encryption protects your message bodies; the custom domain protects your portability. If you ever outgrow the provider, you re-run these five steps at a new one and your correspondents never notice — the address stays the same.

---

Related: deciding whether a custom domain is right for you in the first place? See custom domain vs provider address. Moving from Gmail at the same time? Our migration guide covers the order of operations.