Email Alias Portability with a Custom Domain

Email alias portability is the property that lets you move from one alias provider to another without losing your aliases, breaking forwarding, or having to update every service that has your address on file. In 2026 it is the single most important purchase criterion for serious alias users — more than features, more than analytics, more than price. This guide walks through what email alias portability actually means, why a custom domain is the only mechanism that delivers it, and exactly how to migrate aliases between providers without dropping a single piece of inbound mail.

What is email alias portability?

Email alias portability is the ability to keep your aliases working after switching the underlying provider. Concretely: an alias like chase@yourname.com continues to receive mail and forward to your inbox even if you migrate from Provider A to Provider B, with no change visible to the sender. The alias is portable because the part senders see — yourname.com — is owned by you, not by the provider. The provider is only the relay; ownership of the address belongs to whoever controls the domain.

Compare that to aliases hosted on a provider’s domain. If your alias is chase@provider.com, the provider owns the address. If they shut down, get acquired, or change pricing in a way you don’t want to follow, your aliases die with the relationship. There is no migration path because the addresses themselves disappear. This is the structural difference at the heart of every comparison of email alias services: provider-domain aliases trade portability for convenience; custom-domain aliases trade a few minutes of DNS setup for permanent ownership. If the underlying concept of an alias is still hazy, our explainer on what an email alias actually is covers the basics before this guide builds on them.

If you have never set up a custom domain before, the mental model is simple: the domain is your street address; the provider is just the postal carrier. You can switch carriers any time without telling the people who write to you, because the address still points to the same house. This is also why portable aliases are categorically different from disposable or temporary email addresses — the latter are designed to die; portable aliases are designed to outlive any one carrier.

Why email alias portability matters in 2026

Three structural forces have made email alias portability a first-class concern in 2026, where five years ago it was a niche consideration for paranoid power users:

• Consolidation and shutdown risk. The alias-services market has been consolidating since 2023. Several once-popular services have been acquired, sunset, or quietly stopped accepting new sign-ups. Users who built their lives around provider-domain aliases woke up to dead addresses and lost the ability to receive password resets on the accounts they cared most about.
• Pricing volatility. Free tiers have been shrinking across the category. A provider that gave you 100 aliases free in 2022 may give you 5 in 2026. Migration is a healthy lever only if your aliases come with you when you go.
• Policy and jurisdiction shifts. Providers move incorporation, change their privacy policies, or get pulled into legal disputes that change what they store and for how long. Email alias portability is the only way to vote with your traffic without paying a lockout cost.

None of this is hypothetical. The same logic that drove the EU’s data portability rules into GDPR Article 20 applies to alias services: if you cannot leave, you cannot meaningfully choose. Email alias portability is the user-side defense against vendor lock-in, and a custom domain is the cheapest insurance policy you can buy. For background on why the underlying mechanism is so durable, the Wikipedia entry on MX records walks through how mail routing decisions are tied to the domain owner, not to any specific email host.

How email alias portability works with a custom domain

The whole architecture of email alias portability rests on one piece of plumbing: the MX record. An MX (Mail Exchanger) record is a DNS entry on your custom domain that tells the rest of the internet, “send mail addressed to anything @yourname.com to this server.” When you point your MX records at Provider A’s mail servers, all mail to chase@yourname.com lands there. When you re-point those records to Provider B, the same mail lands there instead — without changing anything visible to senders. The address didn’t change. The carrier did.

The technical contract is governed by RFC 5321 (SMTP), which has been stable for more than two decades. Every alias provider, mail host, and SMTP server speaks the same protocol, which is why migration between providers is structurally possible at all — and why it is robust against arbitrary provider-side changes. The provider doesn’t get to decide whether your aliases work; the DNS does, and the DNS belongs to whoever controls the domain.

The complete picture has four moving parts: the registrar (where you bought the domain), the DNS host (which serves your MX, SPF, and DKIM records), the alias provider (which receives and forwards mail), and your destination inbox (where you actually read it). Email alias portability lives entirely in the relationship between the DNS host and the alias provider. Everything else stays put during a migration.

The MX record is not the only DNS entry that matters. SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) records control deliverability for any mail you send from the domain — including replies routed through the alias provider’s outbound relay. Those records also need to be updated during migration; we’ll cover the specifics in the SPF/DKIM section below.

When alias migration works (and when it doesn’t)

Email alias portability works under three conditions. All three need to be true; missing any one of them turns a smooth migration into a partial one or breaks it entirely.

1. You own a custom domain. This is the load-bearing requirement. Aliases hosted on the provider’s own domain (e.g., name@provider.com) are not portable in any meaningful sense — there is no way to move them. If you don’t own a domain yet, register one at any reputable registrar; the ICANN-accredited registrar list is the safest starting point.
2. Both providers (source and destination) support custom domains. Most do, but a few notable services (Apple Hide My Email, DuckDuckGo Email Protection) deliberately don’t. The provider matrix below covers which is which.
3. The destination provider supports the alias structure you use. “Explicit aliases” (one DB row per alias, e.g., chase@yourname.com exists, random@yourname.com doesn’t) port cleanly. “Catch-all” setups (anything@yourname.com is accepted) also port, but the destination provider must support catch-all mode too, otherwise unknown local-parts will bounce after cutover.

The cases where migration breaks down are equally predictable: you don’t own the domain, the destination doesn’t support custom domains, or the alias service’s reply-relay feature (the part that lets you reply from an alias) has a provider-specific reply-address format that won’t survive the move. We’ll revisit this last case in the “what you lose” section.

How to migrate email aliases between providers

A clean alias migration takes about 30 minutes of active work and 1 to 24 hours of DNS propagation time. The order matters — done in the wrong sequence, you can lose inbound mail during the gap. Done correctly, no sender sees a difference.

1. Open an account at the destination provider and add your custom domain in their dashboard. The provider will display a verification record (usually a TXT entry) for you to add to your DNS.
2. Add the verification TXT record at your DNS host without removing or changing your existing MX records. The new provider can verify domain ownership in parallel with your current provider continuing to receive mail.
3. Set your destination forwarding address at the new provider — the inbox you actually read.
4. Recreate or import your aliases at the destination provider. Some providers (including EmailAlias.io) accept a CSV import. Others require you to recreate aliases one at a time. Match the local-parts exactly: chase@yourname.com at the new provider must equal chase@yourname.com at the old, or routing will fail after cutover.
5. Configure SPF and DKIM at the destination. Add the new provider’s SPF include and DKIM CNAME records to your DNS, but keep the old provider’s records too for now. Mail can survive having both temporarily; it cannot survive having neither.
6. Send a test email to one of your aliases from a fresh address (your phone’s mail account works well) before cutover, and confirm it arrives via the old provider. This is your baseline.
7. Cut over the MX records. At your DNS host, replace the old provider’s MX records with the new provider’s. Set TTL to the minimum your DNS host allows (typically 5 minutes) at least 24 hours before the cutover, so propagation is fast.
8. Verify forwarding through the new provider. Send another test email and confirm it arrives via the new provider this time. Check the message headers if you need to confirm which relay handled it.
9. Wait 48 hours. Don’t disable the old provider yet. DNS propagation is uneven; some senders may still hit the old MX for up to 24-48 hours.
10. Remove the old provider’s SPF include and DKIM records after the 48-hour wait. Cancel the old subscription. Migration complete.

This pattern is the canonical safe migration. The two most common mistakes are cutting MX before recreating aliases (mail bounces with “no such user”) and disabling the old provider before propagation finishes (mail goes to nowhere for senders still hitting the old MX). The double-coverage window — both providers active for 48 hours — is the cheap insurance that prevents both.

SPF, DKIM, and DMARC during the cutover

Inbound forwarding is the easy half of email alias portability. Outbound sending — replying from an alias, or using the alias as the From: address on a new message — depends on SPF, DKIM, and DMARC records, and these are the parts most likely to bite you mid-migration. The NIST SP 800-177 guidance on trustworthy email covers the full theory; below is the practical migration checklist.

• SPF (TXT at the domain root). Tells receivers which servers are authorised to send “for” your domain. During migration, your SPF record should include both providers — for example, v=spf1 include:_spf.providera.com include:_spf.providerb.com ~all — so mail sent by either survives DMARC. After the 48-hour wait, remove Provider A’s include.
• DKIM (CNAME or TXT under a selector). Each provider publishes its own DKIM signing key under a selector subdomain (e.g., provider1._domainkey.yourname.com). The keys are unique per provider; adding the destination’s DKIM record doesn’t conflict with the source’s. Keep both during cutover; drop the old one after.
• DMARC (TXT at _dmarc.yourname.com). Tells receivers what to do when SPF or DKIM fail. If you don’t have a DMARC record, dmarc.org has a starter generator. During migration, keep DMARC at p=none (monitor-only) until you’ve confirmed the new provider’s mail passes both SPF and DKIM. Then ratchet to p=quarantine or p=reject once you’re confident.

If you only receive mail through aliases and never reply from them, SPF and DKIM still matter but with lower stakes: the records are about authenticating the bank’s mail to you (it is), not yours to the bank. If you do use the alias provider’s reply-relay feature, SPF/DKIM authentication of outbound is critical — mail without correct SPF/DKIM will land in spam at every receiver running modern filters.

Provider-by-provider portability notes

Not every alias service supports email alias portability equally. The table below summarises the state of play in mid-2026 across the eight providers most often shortlisted for new alias setups, ordered by portability strength. The criteria are: whether they support custom domains at all, the plan tier required, whether they can export your alias list, and how clean the MX hand-off is in practice.

The top six rows are mutually inter-migrable: you can move from any one to any other with the procedure above. The bottom two are deliberately closed — Apple and DuckDuckGo both run only on their own domains, which is fine if you’re committed to the platform but offers zero email alias portability if you ever want to leave. That’s the trade you’re making at sign-up, whether you know it or not.

If you’re starting fresh and portability is the priority, pick any of the top six and pair it with a custom domain on day one. If you’re starting from an Apple or DuckDuckGo alias today, the migration path isn’t to “port” the addresses — it’s to set up a custom domain on a portable provider, then phase out the old aliases as you update each account.

What you keep — and what you lose — in a migration

Email alias portability covers the address itself — the part senders interact with — but it doesn’t cover everything around the address. The clear-eyed version of the trade is worth knowing before you start.

What you keep:

• The alias address itself (e.g., chase@yourname.com works identically before and after).
• All historical mail you’ve already received and stored in your destination inbox.
• Your relationships with every service that has your alias on file — none of them need to be updated.
• The label and per-institution segmentation pattern you built up over time.

What you lose (and how to handle it):

• Provider-locked metadata. Which sites you first used each alias on, exposure history, blocked-sender lists, custom rules. Most of this you can either rebuild quickly or live without. A CSV export from the old provider preserves the label and creation date if those matter to you.
• The reply-relay address structure. If you’ve been using the old provider’s reply feature, the “reply-to” address that recipients have saved (e.g., chase.aBc123@reply.providera.com) won’t work after migration. The forwarded mail still arrives; only the reply-from-alias path needs to be reconfigured at the new provider with new reply addresses going forward.
• Exposure / leak detection history. Most providers don’t expose this as exportable data. If you have important leak attribution from past breaches, export the relevant entries before cutover (screenshots, CSV — whatever the provider gives you).
• API tokens and integrations. Any automation that talks to the old provider’s API (alias creation scripts, browser extensions tied to a provider) will need to be re-pointed.

For most users none of these are blockers. The address, the historical mail, and the per-service relationships are what actually matter — and email alias portability protects all three. For more on the day-to-day mechanics of aliases versus the metadata around them, our explainer on how email aliases actually work covers the moving parts in more detail.

Common use cases for portable aliases

Email alias portability shifts which use cases are worth the investment. If aliases die when the provider does, you’d avoid using them for anything long-lived. With a portable setup, the opposite is true — they’re best for exactly the relationships you expect to outlive any single provider.

• Banking and financial accounts. Aliases routed through a portable custom domain are the right call for every bank, brokerage, and credit card account you own. The address stays valid for the lifetime of the account, no matter who’s relaying mail behind the scenes.
• Tax and government services. Multi-year mail with a real cost-of-failure makes portability essential. You don’t want the IRS or HMRC trying to reach you at a dead alias because your provider got acquired.
• Healthcare providers. Patient portals, lab results, appointment systems — long-lived relationships where losing the email of record is genuinely disruptive.
• Subscriptions and SaaS. Anything with annual renewal cycles or long-running entitlements benefits from a portable alias. The “I signed up with a provider-domain alias and it died” pattern is the most common preventable cause of forgotten-subscription lockouts.
• Professional contacts. If you publish a contact alias (on a portfolio site, conference badge, paper), that address may circulate for years. Portability is what keeps it reachable.

The pattern: anything you expect to use for more than 18 months is a candidate for a portable alias. Short-lived sign-ups (one-time newsletter, single-conference RSVP) can run on provider-domain aliases without much risk — they’ll be dead long before the provider becomes a problem.

Final thoughts

Email alias portability isn’t a feature you use day to day. It’s a property of your setup that determines whether you have leverage when the underlying market changes — and over a long enough horizon, it always changes. Providers get acquired, free tiers shrink, jurisdictions shift, and the alias setups that didn’t plan for any of it become liabilities at exactly the moment you most need them to work.

The fix is structural and cheap: pick a provider that supports custom domains, register a domain you’ll own forever, and route every long-lived alias through it. Once that’s in place, switching providers becomes a one-evening DNS change instead of a multi-month account-by-account migration. The cost is roughly the price of a coffee per month; the protection is unbounded.

If you want to try the portable pattern without committing, the EmailAlias.io Premium plan includes 5 custom domains and full CSV + API export — set up a single domain on a low-stakes account, walk through one end-to-end migration on a personal alias, and decide from there whether the model is worth scaling to every account you care about. The plumbing is the same whether you have 5 aliases or 500; once you’ve learned it once, the rest is repetition.

Frequently asked questions