{"id":119,"date":"2026-06-03T15:26:13","date_gmt":"2026-06-03T09:56:13","guid":{"rendered":"https:\/\/emailalias.io\/blog\/?p=119"},"modified":"2026-06-03T15:40:27","modified_gmt":"2026-06-03T10:10:27","slug":"what-happens-if-my-alias-provider-shuts-down","status":"publish","type":"post","link":"https:\/\/emailalias.io\/blog\/what-happens-if-my-alias-provider-shuts-down\/","title":{"rendered":"Alias Provider Shutdown: How to Keep Your Mail"},"content":{"rendered":"\n<p>An <strong>alias provider shutdown<\/strong> is the single most damning objection to building any privacy infrastructure on top of an alias service. The fear is straightforward: you spend two years setting up per-service aliases for every account that matters, the provider shuts down, and you wake up to a hundred dead addresses, dozens of accounts you can&#8217;t reach, and no obvious recovery path. The fear is also legitimate \u2014 provider shutdowns do happen, the alias-services market has consolidated heavily since 2022, and dismissing the risk is exactly the wrong response. The honest answer is bounded, structural, and almost entirely under your control: with a custom domain, an alias provider shutdown is a one-evening DNS change; without one, it&#8217;s a multi-week migration. This guide walks through what actually breaks, what survives, and the recovery plan that turns the worst-case scenario into a manageable inconvenience.<\/p>\n\n\n\n<nav class=\"post-toc\" aria-label=\"Table of contents\">\n  <h2 class=\"post-toc__title\">Table of contents<\/h2>\n  <ol class=\"post-toc__list\">\n    <li><a href=\"#what-an-alias-provider-shutdown-actually-means\">What an alias provider shutdown actually means<\/a><\/li>\n    <li><a href=\"#why-provider-shutdowns-happen-and-how-often\">Why provider shutdowns happen (and how often)<\/a><\/li>\n    <li><a href=\"#what-breaks-when-your-alias-provider-shuts-down\">What breaks when your alias provider shuts down<\/a><\/li>\n    <li><a href=\"#what-survives-even-if-the-provider-disappears-tomorrow\">What survives \u2014 even if the provider disappears tomorrow<\/a><\/li>\n    <li><a href=\"#how-custom-domains-change-the-math-entirely\">How custom domains change the math entirely<\/a><\/li>\n    <li><a href=\"#your-alias-provider-shutdown-recovery-plan-step-by-step\">Your alias provider shutdown recovery plan, step by step<\/a><\/li>\n    <li><a href=\"#how-to-pick-an-alias-provider-with-low-shutdown-risk\">How to pick an alias provider with low shutdown risk<\/a><\/li>\n    <li><a href=\"#how-to-back-up-your-aliases-before-you-need-to\">How to back up your aliases before you need to<\/a><\/li>\n    <li><a href=\"#common-mistakes-that-turn-a-shutdown-into-a-disaster\">Common mistakes that turn a shutdown into a disaster<\/a><\/li>\n    <li><a href=\"#final-thoughts\">Final thoughts<\/a><\/li>\n    <li><a href=\"#frequently-asked-questions\">Frequently asked questions<\/a><\/li>\n  <\/ol>\n<\/nav>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"what-an-alias-provider-shutdown-actually-means\">What an alias provider shutdown actually means<\/h2>\n\n\n\n<p>An alias provider shutdown is any event that stops a provider from forwarding inbound mail to your real inbox. It covers three distinct scenarios that often get collapsed into one: a full company shutdown (the provider closes, all servers offline), an acquisition with policy changes (the new owner deprecates the service, raises prices, or changes terms in ways you won&#8217;t accept), and a free-tier termination (the provider survives but the plan you were using disappears). All three feel the same on the day they hit your inbox \u2014 mail to your aliases stops arriving \u2014 but the recovery path differs depending on which one you&#8217;re in.<\/p>\n\n\n\n<p>The technical mechanism in every case is the same: the provider&#8217;s mail servers stop accepting inbound SMTP for your alias domains. If your aliases live on the provider&#8217;s domain (something like <code>name@provider.com<\/code>), the addresses are gone \u2014 there is no DNS change you can make to keep them working, because the domain isn&#8217;t yours. If your aliases live on a custom domain you own (<code>name@yourcustom.com<\/code>), the addresses themselves are intact; only the routing has broken, and the routing is a DNS edit away from working again. This single distinction \u2014 provider-domain versus custom-domain \u2014 is what separates a category-ending event from a one-evening inconvenience. For the foundational mental model of what an alias actually <em>is<\/em>, our explainer on <a href=\"https:\/\/emailalias.io\/blog\/what-is-an-email-alias\/\">what an email alias is<\/a> covers the moving parts; for the mechanics of forwarding under the hood, see <a href=\"https:\/\/emailalias.io\/blog\/how-email-aliases-work\/\">how email aliases work<\/a>.<\/p>\n\n\n\n<p>That&#8217;s the whole structural answer to the alias provider shutdown question. The rest of this guide is about translating it into a concrete recovery plan, and about avoiding the cluster of preventable mistakes that turn a manageable shutdown into a real loss of mail.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"why-provider-shutdowns-happen-and-how-often\">Why provider shutdowns happen (and how often)<\/h2>\n\n\n\n<p>Alias provider shutdowns happen often enough that planning for one is reasonable, but rarely enough that hand-wringing about it isn&#8217;t. The category has seen four categories of shutdown-adjacent events in the last five years:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Acquisitions with continuity.<\/strong> SimpleLogin was acquired by Proton in 2022; AnonAddy rebranded as addy.io after a leadership change. In both cases the underlying service kept running, but the trust assumptions changed \u2014 users who chose the original product for jurisdictional reasons had to re-evaluate after the acquisition.<\/li>\n\n\n\n<li><strong>Free-tier termination.<\/strong> Several providers have shrunk their free tiers materially since 2023 \u2014 caps dropped from 100 aliases to 5, paid-only features got pushed up the tier ladder. For users who never upgraded, this is functionally a shutdown of the plan they were on.<\/li>\n\n\n\n<li><strong>Quiet feature deprecation.<\/strong> A provider survives but stops accepting new alias creations, drops custom-domain support, or removes the API. Less dramatic than a full close, but equally disruptive for users who built workflows around the discontinued feature.<\/li>\n\n\n\n<li><strong>Full shutdown.<\/strong> Rare but not unheard of in the broader email-tools category \u2014 small operators close, ad-supported services lose ad revenue and pull the plug, regulatory issues force closure. Most of the worst-case planning in this guide is for this scenario.<\/li>\n<\/ul>\n\n\n\n<p>The base rate for &#8220;your specific alias provider closes in any given year&#8221; is hard to pin down precisely \u2014 the data isn&#8217;t published \u2014 but informal tracking against the providers on our <a href=\"https:\/\/emailalias.io\/blog\/email-alias-services-2026\/\">2026 email alias services comparison<\/a> suggests roughly one material event per year across the category, affecting a different provider each time. Over a five-year horizon, the cumulative probability that <em>some<\/em> change forces a migration is meaningful; the probability that the specific provider you&#8217;re on is the one affected this year is much smaller. Plan for the former, don&#8217;t panic about the latter.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"what-breaks-when-your-alias-provider-shuts-down\">What breaks when your alias provider shuts down<\/h2>\n\n\n\n<p>The most useful exercise during the alias provider shutdown planning conversation is to walk through what actually breaks, mechanism by mechanism. The list is shorter than the fear suggests \u2014 and for high-stakes account categories like banking, the practical containment is the same as the one we walked through in our <a href=\"https:\/\/emailalias.io\/blog\/should-i-use-email-alias-for-bank-account\/\">guide on using email aliases for bank accounts<\/a>: per-institution segmentation makes the blast radius bounded per alias rather than catastrophic.<\/p>\n\n\n\n<p>Mechanism by mechanism, an alias provider shutdown breaks the following:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Inbound forwarding to all provider-domain aliases.<\/strong> Mail to <code>name@<em>provider<\/em>.com<\/code> bounces or silently disappears, depending on whether the provider&#8217;s MX records survive the shutdown long enough to return errors. Either way, senders stop reaching you.<\/li>\n\n\n\n<li><strong>The provider&#8217;s dashboard.<\/strong> You can no longer log in, create new aliases, disable leaked ones, or view the historical message log. Anything the provider was rendering on its own infrastructure is gone.<\/li>\n\n\n\n<li><strong>The reply-from-alias feature.<\/strong> If you&#8217;d been using the provider&#8217;s relay to reply from aliases, those reply addresses (typically something like <code>chase.aBc123@reply.provider.com<\/code>) stop accepting outbound mail. Any in-flight reply chains threaded through that relay break.<\/li>\n\n\n\n<li><strong>API integrations.<\/strong> Browser extensions, password manager integrations, and any automation that talked to the provider&#8217;s API stop responding. The integrations themselves don&#8217;t break, but their backend has nothing to talk to.<\/li>\n\n\n\n<li><strong>Per-alias metadata.<\/strong> Exposure history, blocked-sender lists, custom forwarding rules, and any other data the provider stored on a per-alias basis \u2014 all gone, unless you exported it before the shutdown event.<\/li>\n<\/ul>\n\n\n\n<p>The pattern: anything the provider was uniquely responsible for stops working. Forwarding, dashboard, replies, integrations, metadata. The blast radius is real, but it&#8217;s bounded \u2014 and three of the five categories above are recoverable from a regular CSV export if you took one before the event.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"what-survives-even-if-the-provider-disappears-tomorrow\">What survives \u2014 even if the provider disappears tomorrow<\/h2>\n\n\n\n<p>Equally useful is the explicit list of what <em>survives<\/em> an alias provider shutdown. Most users underestimate this list \u2014 the fear is loud, the survivors are quiet. The list:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Your real inbox.<\/strong> Your underlying Gmail, Fastmail, Proton Mail, or whatever else you use as the forwarding destination is completely unaffected. The provider was a relay; the destination was always yours.<\/li>\n\n\n\n<li><strong>Every message ever forwarded.<\/strong> Mail that reached your real inbox before the shutdown is in your real inbox forever. No alias-provider event can reach back and delete delivered mail.<\/li>\n\n\n\n<li><strong>Every account you set up with an alias.<\/strong> The bank, brokerage, healthcare provider, and subscription on the other end of the alias have no idea anything happened. You can log into each one, change the email of record, and continue.<\/li>\n\n\n\n<li><strong>Your custom domain (if you have one).<\/strong> The domain is registered in your name with your registrar. The alias provider never owned it; they were just receiving mail on its behalf. Re-pointing the MX records to a different provider is the same DNS edit you&#8217;d make for any normal migration. <a href=\"https:\/\/en.wikipedia.org\/wiki\/MX_record\" rel=\"noopener\" target=\"_blank\">MX record routing<\/a> is, by design, controlled by the domain owner \u2014 not by the mail host.<\/li>\n\n\n\n<li><strong>Anything you exported.<\/strong> If you ran a CSV export in the previous 90 days, you have the full list of your aliases, the destinations they forwarded to, and (depending on provider) the per-alias labels and creation dates. Recreating them at the new provider is mechanical work, not detective work.<\/li>\n<\/ul>\n\n\n\n<p>The fundamental asymmetry: the alias provider owned the relay; you own everything that matters around the relay. Shutdowns burn the relay. The structural assets \u2014 domain ownership, destination inbox, account relationships, exported data \u2014 are all in your name and stay in your name regardless of what the provider does.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-custom-domains-change-the-math-entirely\">How custom domains change the math entirely<\/h2>\n\n\n\n<p>Custom domains are the single biggest variable in any alias provider shutdown calculation. Without one, recovering means logging into every service that had your old alias and updating the email of record \u2014 potentially hundreds of accounts over weeks of evening work. With one, recovering means changing the MX records on your domain and recreating the aliases at a new provider, with zero accounts to update because the addresses themselves are unchanged from the sender&#8217;s point of view.<\/p>\n\n\n\n<p>This is the same point we made in detail in our <a href=\"https:\/\/emailalias.io\/blog\/email-alias-portability-guide\/\">email alias portability guide<\/a>, but it bears restating in the shutdown-specific context: a custom domain converts a category-ending event into a routine DNS change. The cost difference is not 10x or 100x \u2014 it&#8217;s the difference between &#8220;manageable inconvenience&#8221; and &#8220;structural reason not to use alias services at all.&#8221;<\/p>\n\n\n\n<figure class=\"wp-block-image size-large is-style-default\">\n  <img data-recalc-dims=\"1\" src=\"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/diagram-alias-provider-shutdown-mx-repoint.jpg?resize=1080%2C567&#038;ssl=1\"\n       alt=\"How custom domains contain alias provider shutdown damage: re-pointing MX records to a new provider keeps every alias working\"\n       width=\"1080\" height=\"567\"\n       loading=\"lazy\" decoding=\"async\" \/>\n  <figcaption>The custom domain owns the addresses; the provider just hosts the relay. An MX record edit migrates every alias at once, without touching any of the downstream accounts that have the addresses on file.<\/figcaption>\n<\/figure>\n\n\n\n<p>The cost of a custom domain is approximately $10-15\/year at a reputable registrar \u2014 the <a href=\"https:\/\/www.icann.org\/resources\/pages\/registrars-0d-2012-02-25-en\" rel=\"noopener\" target=\"_blank\">ICANN-accredited registrar list<\/a> is the safe starting point. The cost of <em>not<\/em> having one in a shutdown event is roughly the time it takes to update the email of record on every account you care about, which scales linearly with how many services you&#8217;ve migrated to aliases. For anyone past about 20 aliased accounts, the custom domain pays for itself on the first shutdown event by an order of magnitude.<\/p>\n\n\n\n<p>The mechanism, in case it&#8217;s not obvious: when senders address mail to <code>chase@yourcustom.com<\/code>, their mail clients query the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Domain_Name_System\" rel=\"noopener\" target=\"_blank\">Domain Name System<\/a> for the MX records on <code>yourcustom.com<\/code>. Today those records point to provider A&#8217;s mail servers. Tomorrow you edit them to point to provider B. Senders never know the difference \u2014 they re-query DNS at each delivery attempt. The address didn&#8217;t change. The carrier did. That&#8217;s the entire mechanism, governed by <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc5321\" rel=\"noopener\" target=\"_blank\">RFC 5321 (SMTP)<\/a> and stable since the 1980s.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"your-alias-provider-shutdown-recovery-plan-step-by-step\">Your alias provider shutdown recovery plan, step by step<\/h2>\n\n\n\n<p>If the alias provider shutdown announcement lands tomorrow, here&#8217;s the exact sequence to follow. The order matters; doing it out of order is the single most common cause of preventable mail loss.<\/p>\n\n\n\n<ol>\n  <li><strong>Read the announcement carefully and note the cutoff date.<\/strong> Most provider shutdowns include a wind-down window of 30-90 days. That window is your safety buffer; spend the first day understanding it, not panicking.<\/li>\n  <li><strong>Export everything immediately.<\/strong> CSV export, JSON export, whatever the provider offers. Save it to two locations (local + cloud backup). This list is the canonical record of what existed; you&#8217;ll need it for steps 4 and 6.<\/li>\n  <li><strong>Pick a new provider.<\/strong> The <a href=\"https:\/\/emailalias.io\/blog\/email-alias-services-2026\/\">email alias services comparison<\/a> covers the portability properties of each major option. Pick one with custom-domain support and clean export tools, in that order.<\/li>\n  <li><strong>If you have a custom domain: re-point MX records, then recreate aliases.<\/strong> At your DNS host, change the MX records to point to the new provider. At the new provider, add your custom domain, then recreate each alias from your CSV export. Senders see no change.<\/li>\n  <li><strong>If you don&#8217;t have a custom domain: create new aliases at the new provider, then update each downstream account.<\/strong> Sign up at the new provider, generate aliases with similar labels to what you had, and log into each affected service to change the email of record. This is the long path; expect a week or two of evening work.<\/li>\n  <li><strong>Set up forwarding at the new provider before the old one goes offline.<\/strong> If both providers are operational during the overlap window, mail can be received via either \u2014 useful for catching senders you forgot to update during step 5.<\/li>\n  <li><strong>Test before the cutoff.<\/strong> Send a test message to each priority alias (banks, brokerages, healthcare first) and confirm it lands in your destination inbox. Catching configuration errors before the old provider goes dark is the difference between &#8220;smooth migration&#8221; and &#8220;missed 2FA code on cutoff day.&#8221;<\/li>\n<\/ol>\n\n\n\n<p>The whole sequence takes 2-4 hours of active work if you have a custom domain, 10-20 hours if you don&#8217;t. Either way, the wind-down window is enough \u2014 provided you start within the first week of the announcement, not the last.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-to-pick-an-alias-provider-with-low-shutdown-risk\">How to pick an alias provider with low shutdown risk<\/h2>\n\n\n\n<p>Some providers are structurally more shutdown-resistant than others. The signals to look for, ranked by usefulness:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Profitability or a sustainable funding model.<\/strong> Bootstrapped services that charge a fair price are more durable than ad-supported or venture-backed services chasing rapid growth. Look for transparent pricing and an obvious answer to &#8220;how does this company make money.&#8221;<\/li>\n\n\n\n<li><strong>Custom-domain support as a free or low-tier feature.<\/strong> A provider that lets you bring your own domain is implicitly accepting that you can leave \u2014 they&#8217;re competing on service quality, not lock-in. Providers that gate custom domains behind expensive plans are signalling that lock-in is part of their retention strategy.<\/li>\n\n\n\n<li><strong>Clean export tools.<\/strong> CSV or JSON export of your alias list, ideally including labels and destinations. If a provider doesn&#8217;t expose this, treat it as a soft warning sign about their long-term thinking.<\/li>\n\n\n\n<li><strong>Open infrastructure or open-source clients.<\/strong> Not strictly necessary, but if the provider goes away, an open codebase gives the community a path to keep the service running in some form.<\/li>\n\n\n\n<li><strong>Public roadmap and changelog.<\/strong> Active communication is a leading indicator of continued investment. Silent providers are higher risk.<\/li>\n<\/ul>\n\n\n\n<p>Notably absent from this list: provider size. A large provider is not automatically lower-risk than a small one \u2014 large providers get acquired and have product lines deprecated all the time. Size correlates with stability up to a point and then stops correlating with anything useful.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-to-back-up-your-aliases-before-you-need-to\">How to back up your aliases before you need to<\/h2>\n\n\n\n<p>The single highest-leverage thing you can do <em>before<\/em> an alias provider shutdown announcement is take a regular export of your alias list. This converts a potential disaster into a routine migration. The export pattern that works for most users:<\/p>\n\n\n\n<ol>\n  <li><strong>Quarterly CSV export.<\/strong> Once every three months, log into your provider, navigate to Settings \u2192 Export, download the CSV, save it to a directory in your password manager&#8217;s secure notes (or in a folder synced to your cloud backup). Date the file (e.g., <code>aliases-2026-Q2.csv<\/code>) so older snapshots are easy to find.<\/li>\n  <li><strong>Annotate the export with destinations.<\/strong> Most provider exports include the alias address and the forwarding destination. Verify both fields are populated; if your provider&#8217;s export is missing destinations, ask support for a richer format, or maintain a parallel spreadsheet.<\/li>\n  <li><strong>Backup the destinations themselves.<\/strong> If your real inbox is critical, take periodic local backups of the destination inbox using your mail client&#8217;s archive feature. Mail already delivered is the largest single category of &#8220;what survives&#8221; in a shutdown, and it&#8217;s worth knowing you can restore it from local storage if needed.<\/li>\n  <li><strong>Keep a separate record of which services point at which aliases.<\/strong> The information lives in your password manager \u2014 every service entry should have the alias address in the email field. Audit the password manager annually to make sure entries are up to date.<\/li>\n<\/ol>\n\n\n\n<p>The whole backup discipline costs about ten minutes per quarter once it&#8217;s set up. The upside is that on the day a shutdown announcement lands, you already have the canonical list of what existed and don&#8217;t need to reconstruct it from memory.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"common-mistakes-that-turn-a-shutdown-into-a-disaster\">Common mistakes that turn a shutdown into a disaster<\/h2>\n\n\n\n<p>Most of the genuinely catastrophic alias provider shutdown outcomes come from a small set of preventable mistakes, not from anything intrinsic to the shutdown itself. The pattern to avoid:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Skipping the export.<\/strong> If you never ran the CSV export, reconstructing your alias list during a shutdown means searching your password manager, your email archive, and your memory. Adequate for 5 aliases; nightmarish for 50.<\/li>\n\n\n\n<li><strong>Using only the provider&#8217;s own domain.<\/strong> Without a custom domain, every alias dies with the provider, and every downstream account needs manual update. The 10 minutes of DNS setup for a custom domain prevents this category of pain entirely.<\/li>\n\n\n\n<li><strong>Letting the wind-down window expire before migrating.<\/strong> The wind-down window is the safety net. Burning it by procrastinating means losing the period when both old and new providers are reachable simultaneously \u2014 and missed 2FA codes during the final few days are the most common preventable failure mode.<\/li>\n\n\n\n<li><strong>Forgetting about reply-from-alias addresses.<\/strong> If you used the provider&#8217;s reply relay, recipients have those reply addresses saved in their threads. Old reply chains break at cutoff; you need to send fresh messages from the new provider&#8217;s reply relay to re-establish each thread.<\/li>\n\n\n\n<li><strong>Picking a replacement under time pressure.<\/strong> Choosing the new provider in the last week of the wind-down window means you&#8217;re optimising for &#8220;fastest to set up,&#8221; not &#8220;best long-term fit.&#8221; Better to spend the first week comparing replacements carefully, since you&#8217;ll likely live with the choice for years.<\/li>\n\n\n\n<li><strong>Using the same alias provider as a backup against itself.<\/strong> Some users assume &#8220;the provider has my data, so I don&#8217;t need a separate backup.&#8221; A provider in shutdown is exactly the worst time to discover this assumption was wrong.<\/li>\n<\/ul>\n\n\n\n<p>All six are 100% preventable with about an hour of upfront setup. The cost-benefit ratio on the prevention work is dramatically favourable; do it once at sign-up, audit annually, and the shutdown scenarios become routine rather than catastrophic. You can also use <a href=\"https:\/\/haveibeenpwned.com\/\" rel=\"noopener\" target=\"_blank\">Have I Been Pwned<\/a> as a sanity check that the recovery worked \u2014 if a leaked email address surfaces from a shutdown corpus, you&#8217;ll see it there before the spam volume tells you the same thing.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"final-thoughts\">Final thoughts<\/h2>\n\n\n\n<p>The alias provider shutdown question is the load-bearing objection to using alias services at all, and it deserves an honest answer rather than a dismissive one. The honest answer is that the risk is real but bounded, the recovery path is well-defined, and the cost of the most damaging outcome is roughly proportional to how much upfront planning you did. Users who keep regular CSV exports and route their important aliases through a custom domain experience a shutdown as a one-evening DNS change. Users who skip both experience it as a multi-week migration. The difference between those two outcomes is roughly an hour of preparation done once at the start.<\/p>\n\n\n\n<p>The deeper point: the objection is correct but the conclusion most people draw from it isn&#8217;t. &#8220;Alias providers can shut down, therefore aliases are unreliable&#8221; is a non-sequitur \u2014 the same logic would rule out using any third-party service, including the email host that your alias forwards to. The right conclusion is &#8220;alias providers can shut down, therefore plan for it like you&#8217;d plan for any other vendor risk.&#8221; Custom domains, quarterly exports, a password manager that records which alias points at which account. Done.<\/p>\n\n\n\n<p>If you want to start the planning process today, the EmailAlias.io free tier includes 10 aliases and supports CSV export out of the box; the Premium plan at $4\/month adds up to 5 custom domains for the shutdown-resistant setup. <a href=\"https:\/\/emailalias.io\/pricing\/\">Start with the free 10-alias tier<\/a>, take your first export within the first week, and decide from there whether to scale to a custom domain for the accounts that genuinely couldn&#8217;t survive a provider event. The upfront work is small. The downstream protection is unbounded.<\/p>\n\n\n\n<h2 id=\"frequently-asked-questions\">Frequently asked questions<\/h2>\n\n\n<div id=\"rank-math-faq\" class=\"rank-math-block\">\n<div class=\"rank-math-list \">\n<div id=\"faq-question-1780479752076\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">What happens to my aliases if my alias provider shuts down?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Aliases on the provider&#8217;s own domain (name@provider.com) stop working \u2014 there is no DNS change that can save them. Aliases on a custom domain you own (name@yourcustom.com) continue to exist; only the routing breaks, and re-pointing the MX records to a different provider restores forwarding within hours. Your destination inbox, all delivered mail, and the downstream accounts that have the addresses on file are completely unaffected in either case.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1780479761834\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">How often do alias providers actually shut down?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Material shutdown-adjacent events (full closures, acquisitions with policy changes, free-tier terminations, feature deprecations) happen across the category roughly once a year, affecting a different provider each time. The probability that the specific provider you&#8217;re on is the one affected in a given year is much smaller. Planning for the category-level base rate is reasonable; panicking about your specific provider isn&#8217;t.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1780479772819\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">Do I lose my real inbox if my alias provider shuts down?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>No. The provider was a forwarding relay, not the storage layer. Your underlying Gmail, Fastmail, Proton Mail, or whatever else you use as the destination is unaffected. Every message that reached your destination inbox before the shutdown is still there, and the inbox itself continues to function normally.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1780479784015\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">What&#8217;s the single most important thing to do before my alias provider shuts down?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Set up a custom domain. With one, a shutdown is a one-evening DNS change. Without one, a shutdown is a multi-week migration where you update every downstream account individually. The cost is about $10-15\/year for the domain registration, and it pays for itself on the first shutdown event by an order of magnitude.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1780479795150\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">How do I back up my alias list?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Run a quarterly CSV export from your provider&#8217;s dashboard (Settings \u2192 Export) and save it somewhere durable \u2014 your password manager&#8217;s secure notes or a cloud-synced folder. Date each export so older snapshots are easy to find. The whole discipline takes about ten minutes per quarter and gives you the canonical list of what existed on the day a shutdown announcement lands.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1780479807236\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">Can I switch alias providers without losing inbound mail?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Yes, if you have a custom domain. The MX records on your domain control routing, and re-pointing them to a new provider migrates every alias at once. Keep both providers active during a 24-48 hour overlap window so mail in flight reaches you regardless of which MX a sender hit. Without a custom domain, the migration is one-alias-at-a-time and takes weeks.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1780479821614\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">What survives an alias provider shutdown?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Your real inbox, every message ever delivered to it, every account you set up with the alias on file (the bank, brokerage, subscription on the other end), your custom domain (if you have one), and any data you exported. The provider owned the relay; you owned everything around the relay. Shutdowns burn the relay; the structural assets stay yours.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1780479833485\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">Should I use multiple alias providers to hedge against shutdown risk?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Usually no. The cost of running two provider accounts in parallel (two subscriptions, two dashboards, twice the routing complexity) outweighs the marginal protection. A custom domain plus quarterly CSV exports gives you better resilience than provider diversification, at lower cost. Two-provider setups only make sense for very high-value accounts where the cost of even one missed 2FA code during a migration is unacceptable.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>An alias provider shutdown is the single most damning objection to building any privacy infrastructure on top of an alias service. The fear is straightforward: you spend two years setting&#8230;<\/p>\n","protected":false},"author":3,"featured_media":123,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1,9],"tags":[],"class_list":{"0":"post-119","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-email-alias","8":"category-productivity"},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-what-happens-if-my-alias-provider-shuts-down.jpg?fit=1200%2C630&ssl=1","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":125,"url":"https:\/\/emailalias.io\/blog\/best-email-alias-for-developers\/","url_meta":{"origin":119,"position":0},"title":"Best Email Alias for Developers: API, CLI, Domains","author":"Troy Hunt","date":"June 4, 2026","format":false,"excerpt":"The best email alias for developers isn't the one with the prettiest landing page \u2014 it's the one with a documented API, a working CLI, and custom-domain support that survives the next provider shutdown. Developers create more accounts than anyone: every SaaS trial, every OSS release, every staging environment, every\u2026","rel":"","context":"In &quot;Comparisons&quot;","block_context":{"text":"Comparisons","link":"https:\/\/emailalias.io\/blog\/category\/comparisons\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-best-email-alias-for-developers.jpg?fit=1200%2C630&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-best-email-alias-for-developers.jpg?fit=1200%2C630&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-best-email-alias-for-developers.jpg?fit=1200%2C630&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-best-email-alias-for-developers.jpg?fit=1200%2C630&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-best-email-alias-for-developers.jpg?fit=1200%2C630&ssl=1&resize=1050%2C600 3x"},"classes":[]},{"id":103,"url":"https:\/\/emailalias.io\/blog\/email-alias-portability-guide\/","url_meta":{"origin":119,"position":1},"title":"Email Alias Portability with a Custom Domain","author":"Troy Hunt","date":"May 31, 2026","format":false,"excerpt":"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 \u2014 more\u2026","rel":"","context":"In &quot;Email Aliases&quot;","block_context":{"text":"Email Aliases","link":"https:\/\/emailalias.io\/blog\/category\/email-alias\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-email-alias-portability-guide.jpg?fit=1200%2C630&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-email-alias-portability-guide.jpg?fit=1200%2C630&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-email-alias-portability-guide.jpg?fit=1200%2C630&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-email-alias-portability-guide.jpg?fit=1200%2C630&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-email-alias-portability-guide.jpg?fit=1200%2C630&ssl=1&resize=1050%2C600 3x"},"classes":[]},{"id":71,"url":"https:\/\/emailalias.io\/blog\/how-email-aliases-work\/","url_meta":{"origin":119,"position":2},"title":"How Email Aliases Work: A Simple 2026 Guide","author":"Troy Hunt","date":"May 23, 2026","format":false,"excerpt":"If you have ever wondered how email aliases work, the short answer is forwarding: an alias is a stand-in address that quietly relays every message to your real inbox without ever revealing it. But the full picture \u2014 how the address is created, how mail is routed, how replies stay\u2026","rel":"","context":"In &quot;Email Aliases&quot;","block_context":{"text":"Email Aliases","link":"https:\/\/emailalias.io\/blog\/category\/email-alias\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/05\/og-what-is-an-email-alias-1.jpg?fit=1200%2C630&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/05\/og-what-is-an-email-alias-1.jpg?fit=1200%2C630&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/05\/og-what-is-an-email-alias-1.jpg?fit=1200%2C630&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/05\/og-what-is-an-email-alias-1.jpg?fit=1200%2C630&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/05\/og-what-is-an-email-alias-1.jpg?fit=1200%2C630&ssl=1&resize=1050%2C600 3x"},"classes":[]},{"id":47,"url":"https:\/\/emailalias.io\/blog\/what-is-an-email-alias\/","url_meta":{"origin":119,"position":3},"title":"What Is an Email Alias? Complete Guide for 2026","author":"Troy Hunt","date":"May 17, 2026","format":false,"excerpt":"An email alias is a forwarding address that hides your real inbox while still delivering every message you receive \u2014 newsletters, receipts, password resets \u2014 straight to the inbox you already use. Instead of handing out your primary address to every website, store, and signup form, you generate a separate\u2026","rel":"","context":"In &quot;Email Aliases&quot;","block_context":{"text":"Email Aliases","link":"https:\/\/emailalias.io\/blog\/category\/email-alias\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/05\/og-what-is-an-email-alias.jpg?fit=1200%2C630&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/05\/og-what-is-an-email-alias.jpg?fit=1200%2C630&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/05\/og-what-is-an-email-alias.jpg?fit=1200%2C630&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/05\/og-what-is-an-email-alias.jpg?fit=1200%2C630&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/05\/og-what-is-an-email-alias.jpg?fit=1200%2C630&ssl=1&resize=1050%2C600 3x"},"classes":[]},{"id":149,"url":"https:\/\/emailalias.io\/blog\/free-email-forwarding-service\/","url_meta":{"origin":119,"position":4},"title":"Free Email Forwarding Service: Best Picks for 2026","author":"Troy Hunt","date":"June 10, 2026","format":false,"excerpt":"A free email forwarding service is the cheapest way to put a forwarding alias in front of your real inbox \u2014 pick a provider with a working free tier, register an address on their domain, and inbound mail to that address starts landing in your real inbox without ever exposing\u2026","rel":"","context":"In &quot;Comparisons&quot;","block_context":{"text":"Comparisons","link":"https:\/\/emailalias.io\/blog\/category\/comparisons\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-free-email-forwarding-service.jpg?fit=1200%2C630&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-free-email-forwarding-service.jpg?fit=1200%2C630&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-free-email-forwarding-service.jpg?fit=1200%2C630&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-free-email-forwarding-service.jpg?fit=1200%2C630&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-free-email-forwarding-service.jpg?fit=1200%2C630&ssl=1&resize=1050%2C600 3x"},"classes":[]},{"id":158,"url":"https:\/\/emailalias.io\/blog\/best-email-alias-for-business\/","url_meta":{"origin":119,"position":5},"title":"Best Email Alias for Business: 7 Picks for 2026","author":"Troy Hunt","date":"June 12, 2026","format":false,"excerpt":"Choosing the best email alias for business is no longer just a privacy question \u2014 it is an operational one. Every signup an employee makes on a SaaS trial, every vendor that emails them once and never stops, every recruiter that scrapes a leaked database, and every conference badge that\u2026","rel":"","context":"In &quot;Comparisons&quot;","block_context":{"text":"Comparisons","link":"https:\/\/emailalias.io\/blog\/category\/comparisons\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-best-email-alias-for-business.jpg?fit=1200%2C630&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-best-email-alias-for-business.jpg?fit=1200%2C630&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-best-email-alias-for-business.jpg?fit=1200%2C630&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-best-email-alias-for-business.jpg?fit=1200%2C630&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/emailalias.io\/blog\/wp-content\/uploads\/2026\/06\/og-best-email-alias-for-business.jpg?fit=1200%2C630&ssl=1&resize=1050%2C600 3x"},"classes":[]}],"_links":{"self":[{"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/posts\/119","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/comments?post=119"}],"version-history":[{"count":3,"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/posts\/119\/revisions"}],"predecessor-version":[{"id":122,"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/posts\/119\/revisions\/122"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/media\/123"}],"wp:attachment":[{"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/media?parent=119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/categories?post=119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/emailalias.io\/blog\/wp-json\/wp\/v2\/tags?post=119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}