TL;DR & FIXME

• Severity: High / Data Loss

• Component: Microsoft Account Alias Management (hxxps://account.live.com/names/manage)

• Core Issue: Misleading UI (“Remove” action) combined with zero grace period leads to instant, unrecoverable deletion of Microsoft-domain email addresses.

• Proposed Fix: Implement the standard 30-day account closure grace period for Microsoft-domain alias deletion.

• 严重程度：高 / 数据丢失

• 受影响组件：微软账户别名管理 (hxxps://account.live.com/names/manage)

• 核心问题：极具误导性的 UI（“移除”操作）与“零容错/无宽限期”机制叠加，导致微软域名邮箱地址被瞬间、不可逆地永久销毁。

• 修复诉求：为微软域名别名的删除操作，引入（实装）与标准微软账户注销同等的 30 天宽限期（恢复窗口）。

TL;DR for Microsoft Users

• Never click “Remove” on any Microsoft-domain email address (regardless of whether it is an alias or the primary address).
• Due to the fundamentally flawed design logic of this interface, consider avoiding the alias feature entirely.
• If strict security is a priority, avoid using an Outlook email address as the primary email for any critical third-party accounts.

给 Microsoft 用户的 TL;DR

• **永远不要移除（Remove）**任何基于 Microsoft 服务/域名的电子邮件地址（无论是不是别名）。
• 由于它的设计逻辑缺陷，可以考虑完全避免使用别名功能。
• 如有极端安全性必要，避免将 Outlook 邮箱作为任何账户的主邮箱。

Core Issue

The Microsoft Account address management interface (which doubles as the email alias management page) displays all contact methods—third-party emails, phone numbers, Microsoft-domain emails, and Microsoft aliases—using an identical UI layout, with each featuring a generic “Remove” button.

For third-party emails and phone numbers, this button simply removes the contact method (essentially unbinding it from the account). However, for Microsoft-domain emails and aliases, clicking this identically labeled button results in the permanent, irrecoverable destruction of the email address (permanently disabling its ability to send or receive emails).

This severe design defect makes it incredibly easy for users to make a fatal mistake, leading to the absolute and irreversible loss of their email accounts.

We could analyze why users click “Remove” (e.g., to stop brute-force hacking attempts or clean up old identities). However, from a security design perspective, a user’s actions or underlying motivations do not alter the severity of this flaw.

The core issue is that no competent developer or product manager would place an action as catastrophic as “permanently destroying an email account” in a standard list with a generic, unalarming button.

By any modern UI/UX standard, destructive actions of this magnitude require strict guardrails:

1. Visual Cues: A clearly marked red button (Danger Zone).
2. Cognitive Friction: Requiring the user to manually type the exact email address being deleted (similar to GitHub repository deletion).
3. Strong Verification: A mandatory 2FA prompt.
4. Fault Tolerance: A soft-delete state or a 30-day cooldown period.

In Microsoft’s alias management interface, all four of these standard safeguards are completely absent. This is not just poor UX; it is a profound dereliction of duty regarding user data protection.

主要问题

Microsoft 账户的地址管理界面（同时也是电子邮箱别名管理界面）将所有联系方式（第三方邮箱、电话号码、基于 Microsoft 服务的邮箱、基于 Microsoft 服务的邮箱别名）以完全相同的外观展示，且提供移除（Remove）按钮。对于第三方邮箱和电话号码，此按钮代表删除此联系方式（即某种意义上的解除绑定）。然而，对于基于 Microsoft 服务的邮箱/别名，此相同文案的按钮会导致它被永久删除（无法发送和接收电子邮件）且无法恢复。此设计缺陷导致用户极易发生误操作，导致用户电子邮箱彻底无法使用。

我们可以去分析为什么用户会去点击“移除”（比如为了阻挡黑客频繁撞库，或是清理旧身份），然而，从安全设计的角度来看，用户的任何行为或者具体动机并不影响该缺陷的严重性。

真正的问题在于：没有任何一个合格的开发者或产品经理，会把“永久销毁一个电子邮件账户”这种灾难性操作，堂而皇之地放在一个普通的列表里，并用一个毫无警示感的按钮来处理。

按照现代互联网产品的基本 UI/UX 规范，任何涉及资产销毁的“高危操作”，都必须具备以下四个防呆底线：

1. 视觉警告：醒目的红色警示按钮（Danger Zone）。
2. 认知阻断：要求用户手动输入一遍目标邮箱地址以确认销毁（就像 GitHub 删除仓库那样）。
3. 强身份验证：强制触发一次 2FA（双重验证）。
4. 容错机制：提供软删除或 30 天的冷却期。

而在微软的别名管理界面中，这四道防线全部缺席。这不仅仅是体验不好，这是对用户数字资产的极度不负责任。

References

Reddit Discussions

• PSA: Don’t Be an Idiot Like Me – Learn From My Email Alias Mistake
• What happens when you remove a Microsoft email alias from the account using that same email address?
• RIP 20.000 hours jagex account email gone (hotmail alias changed)
• Account Problem
• Deleted Alias
• Recovering an Outlook account with no attached Microsoft Account (Outlook.com)

Complaint Message

The Microsoft Account alias management interface (hxxps://account.live.com/names/manage) presents a severe security and UX hazard by labeling the permanent, irreversible destruction of Microsoft-domain email addresses as a generic “Remove” action. Users routinely mistake “Remove” for simply unbinding an address or removing sign-in permissions, leading to immediate account self-sabotage where decades of digital identity, bound 2FA codes, and critical communications are vaporized instantly without a recovery window.

To fix this, Microsoft must align alias deletion safeguards with standard MSA account closure policies by implementing an identical 30-to-60-day grace/cooldown period during which deleted aliases can be restored. Furthermore, removing a primary or secondary alias should trigger the exact same level of high-severity warnings and multi-step verification required when closing an entire Microsoft Account, rather than relying on a misleading prompt that masks a catastrophic action.

投诉消息（简体中文）

微软账户的别名管理界面（hxxps://account.live.com/names/manage）存在严重的安全与 UX（用户体验）高危隐患：它将“永久且不可逆地销毁微软域名邮箱地址”这一极具破坏性的操作，仅仅标记为一个平白无奇的“移除（Remove）”按钮。用户普遍会误将“移除”理解为仅仅是“解绑邮箱”或“取消登录权限”。这种误导导致了灾难性的“账户自毁”——在没有任何挽回窗口的情况下，用户积累了十几年的数字身份、绑定的双因素认证（2FA）以及极其重要的通讯记录，在点击的瞬间便灰飞烟灭。

为了修复这一缺陷，微软必须使别名删除的安全防护机制与标准的微软账户（MSA）注销政策看齐：引入完全一致的 30 至 60 天的宽限期/冷却期（Grace/Cooldown period），在此期间允许用户恢复误删的别名。此外，无论是移除主别名还是次要别名，都应当触发与“注销整个微软账户”同等规格的高危级别警告及多步验证流程，而不是仅仅依赖一个掩饰了灾难性后果的误导性弹窗。