[NOTICE] New account registration is currently closed. Existing members are unaffected.
itpromail
home / blog / guides

Own Your Email Identity: Why a Domain Makes Your Address Portable

An address on a domain you control keeps working when you change mailbox providers. An address on someone else's domain does not.

June 26, 2026 · Guides · ITProMail team

An email address is usually treated as a login name, but it is also an identity that other people and services use to reach you. If that address lives on a domain you own, you can change the mailbox provider behind it without changing the address. If it lives on someone else's domain, your identity is tied to that service, and leaving means asking every contact and every account to update their records.

What "portable" means in practice

An address like name@example.com has two parts. The local part (name) is chosen within a domain. The domain part (example.com) is resolved through DNS. Mail for the domain is routed by the MX records in DNS, so the mail host is a setting you control, not a fixed property of the address.

With a provider-owned address, the provider controls the domain, and the provider decides whether that address keeps working. With your own domain, you control the DNS zone. Moving to another provider means publishing new MX, SPF, DKIM and related records and confirming that the new host accepts mail for the domain. The address stays the same.

What you actually need to control

  • The domain registration. Keep it in a registrar account protected by two-factor authentication, and enable a registrar lock where the registrar offers one.
  • DNS control. Either the registrar's DNS or a DNS host you choose. The recovery path for that account is as important as the mailbox's recovery path.
  • Renewal. An expired domain is one of the most common ways to lose an address permanently. Turn on auto-renewal and make sure more than one trusted person can reach the billing contact.

Records that move with you

A portable setup keeps its records documented, so a migration becomes a checklist rather than a rediscovery exercise:

  • MX records, which decide where inbound mail is delivered.
  • The SPF TXT record, which lists the hosts allowed to send for the domain.
  • DKIM public key records, usually a CNAME or TXT record at a selector name.
  • The DMARC TXT record at _dmarc, which sets policy and reporting addresses.
  • MTA-STS and TLS-RPT records, if your provider supports them.

The SPF, DKIM and DMARC article explains what each record does. Keep a copy of the zone contents or a written list somewhere outside the DNS provider.

Keep the mail history with the address

The address is only part of the identity. Old messages, folders and contacts live in the mailbox. Before changing providers, export the mailbox from the old service and keep a copy. Any IMAP tool can copy folders between hosts, and imapsync is a common choice for moving an IMAP mailbox from one server to another. Also list the services that use the address, because password resets and account notices must still reach you during the move.

A migration in outline

  1. Create the mailboxes on the new host and confirm they accept mail for the domain before changing DNS.
  2. Lower the TTL on the existing MX records well in advance, so the change propagates quickly.
  3. Copy existing mail with imapsync while the old host still accepts delivery.
  4. Switch the MX and sending records to the new host.
  5. Keep the old mailbox receiving for a while, and forward or copy anything that still arrives there.

Trade-offs

A custom domain means you own the identity, which also means you own renewal, DNS security and record maintenance. A weak DNS account is a larger risk than a free provider address with strong two-factor authentication. For most people the trade still favors a domain, because the setup is a one-time task and the portability lasts for as long as the domain is kept.

On ITProMail, custom domains are available on the Operator and Shadow plans. The custom domain guide covers adding a domain and the records to publish. For a broader view of how addresses and headers reveal information about you, read metadata is the leak.

Related reading