devgo.cn用 Gmail 收发邮件早已是日常，但如果你经营自己的域名，很早就有一个尴尬：想用 [email protected] 这样的地址发信，要么切到第三方邮件客户端，要么在 Gmail 里手动配置 SMTP，还要折腾一堆 MX、SPF、DKIM 记录。现在有个 Chrome 扩展叫 Alias，直接在 Gmail 编写窗口里加一个“Send via alias”按钮，把当前草稿通过你选择的投递通道发出去，不用改收件配置，连 MX 都不用动。
它的工作流程很直白：先添加一个你拥有的、已验证的域名地址，然后选择投递方式——要么用它自己托管的 Hosted 模式，要么连你自己的 Cloudflare Email Sending 或 Resend 账号，最后照常写信，点那个额外按钮。普通的 Send 按钮完全不受影响，收件逻辑也原样保留。这意味着你既不用把域名整套迁过去，也不用在 Gmail 设置里动任何东西。
这里值得展开的是两种投递模式的区别。Direct 模式（连你自己的 Cloudflare 或 Resend）会把草稿里的字段直接发给对应的邮件发送 API，支持 To、Cc、Bcc、富文本和附件，但需要你有一个已验证的发送方域名和一个受限的凭据。Hosted 模式则由 AudioFetcher 做中继，走 Amazon SES 投递，省去自己配 API 的麻烦，但目前只支持一个收件人和纯文本或 HTML 正文。两种模式都对 DKIM 有要求——DKIM 是邮件服务器用域名私钥给邮件签名、收件方用公钥验签的一整套机制，用来证明这封信确实来自你的域名，避免进垃圾箱。Hosted 模式还需要人工审核和 DKIM 的 DNS 验证。
隐私方面也值得说一句：只有在按下那个单独按钮后，扩展才会读取当前草稿中需要的字段，直接模式下数据只发给你自己选的提供商，托管模式下只经过 AudioFetcher 的中继和 SES。它不会扫描你的收件箱做广告，也不会卖数据。这点对于想保留 Gmail 体验又在意隐私的开发者来说很关键。
最让我意外的是它绕过了 Gmail 原生“发信人地址”功能的限制——那个功能要求你手动填 SMTP 服务器，还得处理一堆验证邮件。Alias 把整件事封装成一个按钮，本质上是把“发信”这个动作委托给了更灵活的外部通道。对开发者来说，这个思路可以迁移到任何需要“在不改变主流程的前提下，把特定动作路由到第三方服务”的场景——比如在聊天工具里加一个“用企业身份回复”的按钮，或者在内网系统里临时用外部网关发送通知。
目前的限制也很明确：只支持 Chrome 桌面版 Gmail，发出去的邮件不会自动出现在 Sent 文件夹，原始草稿还会留着，也没有定时发送和机密模式。如果你需要这些，还得等后续版本。但作为 0.6 版本，核心链路已经跑通，并且它明确声明是独立产品，和 Google、Cloudflare、Resend、AWS 都没有官方关联。
对于手里有自定义域名、又不想被 Gmail 默认发信体验约束的人，这个扩展等于把“域名发信”从运维事项变成了日常操作。开发者可以把它当成一个参考实现：用浏览器扩展劫持一个 UI 动作，再通过成熟邮件 API 完成投递，全程不碰 DNS 的 MX 记录——这个思路在需要快速集成外部服务的工具型产品里非常实用。当然，如果你对隐私极度敏感，也可以选择自己连 Cloudflare 或 Resend，直接控制数据去向。总的来说，这是一个小而巧的工程实践，值得邮件相关开发者看看它是怎么把复杂协议藏到按钮背后的。
内容与图片版权归原作者所有 · 原文: https://chromewebstore.google.com/detail/alias-custom-domain-email/hdmholmgdmnmdgbipelccdjidnjlmlke