An email alias forwards mail to a destination inbox. Provider documentation shows a split outcome instead: ending a paid subscription usually moves the account to a free plan, and forwarding often carries on, while deleting an account or an individual alias is what stops delivery for that address. Cancelling the service therefore changes what happens at that step, not at the destination inbox. The widespread expectation is that cancellation cuts forwarding at once and breaks every account registered with an alias.
Subscription cancellation, single-alias deletion and full account deletion are distinct actions with distinct effects. Provider help pages treat them separately, although everyday language uses "cancel" for all three. Planning a downgrade calls for different preparation than planning a full deletion.
Subscription cancellation, alias deletion and account deletion
| Action | Account status | Forwarding outcome |
|---|---|---|
| Subscription cancellation | Account stays on the free plan | Existing aliases often keep forwarding; paid features end |
| Single-alias deletion | Rest of the account keeps working | Mail to that one address stops, with recovery rules varying by provider |
| Account deletion | Account and its forwarding rules removed | Mail to provider-domain aliases stops |
| Service shutdown | Provider ends the service | Relay masks stop working after shutdown; other providers' shutdown terms vary |
In short, cancellation downgrades an account, while deletion removes an address or the whole account.
Forwarding after a subscription ends
SimpleLogin's pricing FAQ states the opposite of the common expectation: when a subscription ends, every alias created under it keeps receiving and sending mail as normal. The page illustrates this with 100 aliases still working after the subscription ends. What disappears is the ability to create further aliases beyond the free limit of 10, plus the ability to add a new domain, directory or mailbox. This wording was verified live on 2026-11-04.
Firefox Relay reports a comparable result for existing masks. Its Firefox Relay FAQ states that a downgrade from Relay Premium leaves mail forwarding through custom email masks already created, while blocking new masks on that subdomain and removing the ability to reply to forwarded messages. Mozilla support pages on cancelling a Relay subscription describe the same pattern: auto-renewal stops, premium features run out at the end of the subscription period, and the account returns to the free plan instead of closing. The Relay Premium FAQ repeats the downgrade rule for custom masks and replies. Mozilla pages disagree on the free mask limit, so this article gives no free-limit figure for Relay.
addy.io takes a stricter line on downgrade. Its addy.io FAQ states that a cancelled subscription stays live until the current billing cycle ends, and that a warning email arrives a few days beforehand with the steps needed to avoid mail loss. Shortly after the subscription ends, custom domains are deactivated, extra usernames are deactivated, recipients beyond one are deactivated, paid settings fall back to defaults, paid-plan-only alias domains are deactivated, and shared-domain aliases beyond 10 are deactivated. Resubscribing within 90 days reverses all of those changes automatically.
Forwarding after an account is deleted
Deleting a whole account ends its forwarding arrangement. Alias addresses belong to the provider domain or to the account record, so once the account closes no forwarding rule remains to carry mail to the destination inbox, and mail to a deleted provider-domain alias is rejected or discarded according to the provider. No provider day count is given here, because the account-deletion pages reviewed list deletion steps but publish no uniform retention window in the passages checked. The addy.io help centre groups account deletion under accounts and settings, with a guide to permanently deleting an account and what happens to aliases and data.
A service shutdown follows the same mechanism from the provider side. Firefox Relay states in its FAQ that if Mozilla closes the service, users get advance notice to change the email address on any account using Relay masks. The notice gives migration time but preserves nothing: every account holding a mask still needs its address changed.
Single-alias deactivation, deletion and forgetting
Three single-alias actions carry different consequences, and the distinction decides whether mail bounces, disappears silently or can come back. addy.io sets the three out plainly in its deactivating aliases guide: deactivation pauses forwarding and mail is discarded without notice, deletion removes the alias and mail is rejected while restoration stays possible, and forgetting surrenders the alias permanently. Its terminology page gives the rejection message for a deleted alias as 550 5.1.1 Recipient address rejected, and states that a forgotten shared-domain alias can never be restored or used again, whereas a forgotten standard alias can be created again later.
SimpleLogin works on a trash model. Its delete alias documentation states that a deleted alias moves to a global trash after 30 days by default and can be restored during that window, or goes into the trash at once under the other setting and cannot be reused. Historic information on the alias, including the creating account and its contacts, is deleted. Its restore alias documentation states that aliases on a user domain or a SimpleLogin subdomain are recreated rather than restored once removed from the domain trash, and contacts and settings do not carry over.
Apple Hide My Email offers a deactivate-or-delete choice. Apple Support states that mail to a deactivated address returns to the sender, that a deactivated address can be reactivated at any time, and that deleting an inactive address is permanent, with no reactivation possible. DuckDuckGo gives the related account rule on its help page on private Duck Addresses: private Duck Addresses do not expire, and mail keeps forwarding while the account stays active and the address has not been deactivated.
Accounts tied to provider-domain aliases
A broken alias hurts most through a small set of account types. Sign-in, password resets, security alerts, order confirmations and billing notices all travel through the address on file. When forwarding stops, a password reset sent to a dead alias never arrives, and proving ownership of the account may then require support intervention. Some services also demand confirmation through the existing address before accepting an address change, which creates a circular problem: the old alias must still receive mail for the switch to the new address to complete.
Sender suppression adds a further cost. addy.io documents in its FAQ that a sender receiving a rejection for an alias often adds the alias to a suppression list and stops trying, even once the alias works again. Restoring the alias alone may therefore fail to restore delivery from that sender: either the sender must clear the suppression entry, or the account address must change to a new alias. Delivery from that sender may stay interrupted after the alias is restored.
Pre-cancellation inventory
Provider documentation implies four parts of preparation, described here rather than given as instructions. First, an inventory: an export or written list of every alias, the service holding it, and whether that service uses the alias for sign-in, recovery or billing. addy.io offers an export of aliases and account data to CSV, documented in its aliases help category and its first-alias guide. Second, ranking: accounts controlling money, identity or recovery come ahead of newsletters and low-value accounts. Third, address change and testing: the address on each ranked account changes, and a test message confirms delivery to the new address before the old alias is touched. Fourth, overlap: the old alias stays live until the change is verified.
Each alias also needs its own decision, not one decision for the whole account. An alias for a service no longer used can go without migration. An alias for a service that still matters needs a new address first, with the old alias kept live until the replacement is confirmed.
Custom domains and portability
Owning a custom domain changes the exit entirely, because the domain owner controls where mail for that domain goes. addy.io documents the mechanism in its FAQ: a custom domain needs a TXT record to prove ownership and an MX record so the provider server can handle incoming mail, and a domain cannot point mail at two mail servers at once, so moving a domain means swapping the old provider MX records for the new ones. After that change, the same address, such as shop@example.com, can forward through the new provider without changing the address on any account holding it.
Portability preserves the address, not the alias record. SimpleLogin states that recreating a custom-domain alias does not bring back contacts, settings or other historic records deleted with the original alias, so rules, labels and notes tied to the old provider record must be rebuilt. Portability also fails for aliases on a provider shared domain: an address there sits inside that provider namespace, and no DNS change by the user can move it, so those addresses must be replaced account by account.
AliasFleet forwarding addresses
AliasFleet is an email alias service that provides one forwarding address per site, with aliases described as managed, persistent identities rather than short-lived addresses. Its introduction describes aliases that can be paused, rotated or deactivated, and its article on changing an email after a breach states that the free tier covers 10 active aliases. The AliasFleet site is the product home page. No AliasFleet cancellation or account-deletion retention rule was verified from an AliasFleet docs or pricing page in the sources reviewed for this article, so this article states no such rule for AliasFleet. That gap matters for a reader comparing exits, because the downgrade and deletion rules above are provider-specific and do not transfer from one service to another.
Cost of leaving an alias service
The cost of an alias service is not the monthly fee. It is the dependence built by handing a provider-controlled address to every account that matters, plus the migration work needed to undo that dependence. Downgrade rules soften that cost at some providers and sharpen it at others, and single-alias deletion rules decide whether a mistake can be undone. A custom domain removes the largest part of the cost, because the address outlives the provider, but the record-rebuilding work and the account-by-account replacement for provider-domain aliases remain.
Top comments (0)