64 octets 是地址格式上限，不是命名目标
RFC 5321 将邮箱地址的 local-part 长度上限规定为 64 octets。这不是建议把前缀写满，也不代表每个服务都接受所有符合标准的格式。本周建议先给一个低风险订阅或项目入口定下简短、稳定、能看懂的标签，同时记录它对应的网站或项目。命名只负责辨认用途，不会替代过滤、邮件转发或账号恢复设置；敏感身份信息也别塞进地址。
适合正在维护多个订阅地址、希望减少收件混淆的个人用户。
按客户或项目分流的自由职业者，可以借此建立较易交接的标签约定。
如果正在搭建长期收件体系，也可把命名、地址台账和收件核验一起规划。
按网站还是按用途：先确定地址代表什么
这不是只有一个正确答案。给每个网站单独使用地址，来源容易追踪；按“新闻简报”或“购物通知”等用途归类，地址更容易复用，但不一定能看出具体是哪家网站。关键是先决定地址的主要任务，而不是创建后再靠记忆猜。
RFC 5322 描述了地址由 local-part 与域名组成，但格式本身并不规定前缀一定要表达网站、项目还是订阅类别。以下只是命名示意，不是现成地址，也不代表任何服务商的配置：
| 收件场景 | 命名思路 | 示意标签 | 取舍 |
|---|---|---|---|
| 单一网站注册 | 网站简称＋用途 | shopA-account |
来源清楚；网站改名时需更新台账 |
| 多家同类订阅 | 内容类别＋必要区分 | news-design |
便于按主题识别；难直接判断具体来源 |
| 长期客户往来 | 稳定客户代号＋工作用途 | client-k7-work |
便于交接；代号与客户的对应关系需安全保存 |
| 有期限的项目 | 项目代号＋项目阶段或用途 | proj-north-billing |
适合项目归档；项目结束后仍要核对账号依赖 |
网站单独分配更适合希望查明具体来源、并可能单独停用地址的情况。用途归类更适合只需区分内容类别、且不会因来源不明而影响后续操作的情况。若单个网站涉及付款、售后、合同或账号找回，就别为了减少地址数量而把它混进一个含糊的“其他”地址。
还要区分地址前缀与管理界面中的标签。前缀属于实际收件地址的一部分；有些服务另有备注或标签字段，改备注并不会自动改动地址。邮件系统架构文档也说明，@ 左侧的 local-part 由相应域名一侧解释，其他系统通常不能仅凭它推断用途。RFC 5598 对 local-part 的说明可以帮助理解这条边界。(rfc-editor.org)
订阅与项目来信：标签写用途，别写敏感身份
订阅邮件的名称应让收件者一眼判断内容，而不是写成无法区分来源的“misc”或“mail”。例如，把新闻简报按主题命名，把购物通知与售后分开；如果同一类别下有多个来源，可在标签中加入简短来源缩写。标签太宽泛，后续看到邮件时仍得打开正文找线索，命名就失去作用。
客户和项目要分开考虑。客户关系通常可能持续较久，适合选不随单个交付任务改变的客户代号；短期项目则用项目代号，避免项目结束后仍把新任务误归到旧地址。若客户更名、项目改名或工作入口移交，应同时更新台账中的名称、负责人和状态，不能只改联系人备注。
地址里不要直接放真实姓名、生日、私人身份、客户全名、合同细节或敏感事项。客户名称是否能用，还要看它是否属于公开信息、地址会被谁看到、以及是否牵涉保密义务。对外展示的地址可能出现在注册记录、邮件抬头或转发链路中；用不含身份含义的代号，并把代号映射单独保存在权限合适的台账里，通常更稳妥。
⚠️ 邮件别名不等于团队共享邮箱。某个地址能否由多人共同查看、能否以该地址回复，取决于具体服务功能和授权；不能从名称本身推断。持续的客户沟通还要核实发信身份和共享权限，避免收件入口可共用、回复却意外暴露个人地址。
网站注册与多账户：记录对应关系，不靠前缀猜
网站改名、品牌合并，或同一网站同时有个人与工作账户时，容易出现“这个地址究竟绑在哪个登录名下”的问题。名称相似不代表账户相同，前缀里写了网站缩写，也不能证明该网站接受这种地址。注册前仍需看网站表单提示；注册后则把实际使用的地址和登录邮箱记清楚。
| 台账字段 | 记录内容 | 能解决的问题 |
|---|---|---|
| 服务或项目名称 | 当前名称，并可附旧名 | 避免网站更名后搜不到 |
| 实际收件地址 | 完整地址，不只记前缀 | 避免把相似地址贴错 |
| 登录邮箱 | 实际用于登录或恢复的地址 | 分清收件入口与账号凭据 |
| 用途与账户标识 | 订阅、订单、工作账户等 | 同一网站有多个账户时减少混淆 |
| 收件去向与规则 | 主邮箱、目标文件夹或筛选条件 | 区分转发配置与地址命名 |
| 维护责任与状态 | 负责人、仍在用／待核实／已停用 | 便于交接和停用前复查 |
邮箱别名管理不应只保留一张“前缀—网站名”清单。登录邮箱可能不同于对外填写的地址；邮件转发负责把来信送到另一个收件处；过滤规则决定邮件如何归档；台账则记录这些关系。它们互相配合，但不是同一个功能。需要厘清别名和转发边界时，可继续阅读邮箱别名的能力边界。
在地址格式上也要留余地。邮件格式标准列出的语法，不代表所有注册表单都允许其中每一种写法。RFC 5322 的地址规范包含多种格式；实际可创建、可投递与被网站接受，是不同层面的判断。特别是加号子地址：标准确实描述了用 + 分隔附加信息的用法，但相关过滤扩展针对的是允许该功能的邮件系统，不能假设每个邮箱或注册网站都支持。RFC 5233 对子地址的说明(rfc-editor.org)
| 格式或功能 | 可以据此判断什么 | 不能据此推断什么 |
|---|---|---|
+ 子地址 |
某些系统可将分隔符后的内容用于分类 | 所有服务都接受 + 地址，或能自动过滤 |
| 点号与连字符 | 可用作命名约定的一部分 | 所有服务都允许任意位置或组合 |
| 非 ASCII 字符 | 存在支持国际化地址的传输扩展 | 注册网站、邮件客户端和中转系统都支持 |
| 邮件转发 | 来信可能被送往另一个邮箱 | 地址名称会自动创建转发规则或实现发信 |
国际化地址需要传输双方具备相应支持；相关标准明确要求服务器提供 SMTPUTF8 扩展能力，客户端才能按该机制传输国际化邮箱地址。因此，实际命名优先选目标服务明确接受的字符，并用测试邮件验证，不要把“语法上存在”当成“当前服务可用”。RFC 6531 对国际化邮件传输的要求(rfc-editor.org)
先小范围试用，再把规则推广到其他地址
地址名称越多，统一格式的价值越明显；但一次性批量改动既有地址，可能打断账户登录或找回。先挑一个低风险用途试运行。测试时按下面的条件分支做决定：
- 若未来会长期收到该网站的通知，或需要找回账户，就为它保留可长期访问的独立地址，并记入台账；否则，若任务只是临时注册或收一次验证码，可选短期收件方式。
- 若相似用途只有一个来源，按用途命名即可；若同类来源有多个，增加来源缩写或网站标识。
- 若地址会用于客户交接，选稳定代号并记录维护责任；否则，按个人可理解、可检索的方式命名。
- 若地址用途改变，先更新台账和收件分类，再确认转发去向；如果用途不再需要，先核对关联账户和恢复渠道，不能只凭名称决定停用。
- 若需要多人查看或以别名发信，先核实服务能力和授权；不支持时回退到获准的共享邮箱或长期工作邮箱。
| 核验动作 | 检查内容 | 通过条件 |
|---|---|---|
| 选一个低风险入口 | 选择普通订阅或非关键项目 | 不涉及银行、支付、政务或唯一恢复渠道 |
| 创建或填写地址 | 复制完整地址，不凭手打猜字符 | 表单接受后，台账同步记录 |
| 发起收件测试 | 发送测试邮件或等待正常业务邮件 | 收件地址与预期入口一致 |
| 检查收件去向 | 若设置了邮件转发，核对目标邮箱 | 目标地址正确，台账记录了去向 |
| 检查分类规则 | 查看过滤器或文件夹实际效果 | 不把“命名标签”误当成自动分类 |
| 复查账户依赖 | 检查登录、通知和恢复邮箱 | 未确认前不批量改名或停用 |
如果测试时出现重名、看不懂缩写或地址容易贴错，先修改命名约定，再逐个处理新地址；不要一次性改动大量现有账户。需要长期订阅时，也可以先判断应使用地址别名还是过滤规则，再看订阅收件与邮箱选择思路。对重要账户，始终保留长期可访问的邮箱，不用临时邮箱承担银行、支付或政务账户的恢复责任。
给新规则留一次复查机会：确认标签能区分用途、台账能对应到网站或项目、邮件实际到达预期收件处。若只是临时注册或收一次验证码，SendTmp 首页提供免注册、即开即用的临时收件入口，可与长期别名分开使用；若后续还要接收通知、回复或找回账户，就先按这套命名规则建立长期地址和台账，再核实实际收件路径。(sendtmp.com)