我见过最逼真的一封钓鱼邮件，
2025 年底，安全公司 Check Point 披露了一起大规模钓鱼攻击：攻击者直接用了 Google Cloud 的官方邮件发送服务，从 Google 自己的服务器发出钓鱼邮件，目标超过 3000 家组织。邮件来自 @google.com 官方子域名，通过了所有标准邮件验证，但邮件里的链接最终把你引向一个伪造的登录页面，专门偷账号密码和 2FA 验证码。
这不是 Google 服务器被黑了。是攻击者在规则框架内，用合法工具干了非法的事。
所以今天说清楚一件事：邮件显示来自官方域名，为什么仍然可能是钓鱼，以及你该怎么判断。
第一步：搞懂"显示通过验证"不等于"这封信没问题"
目标是：理解 SPF/DKIM/DMARC 这三项验证到底在查什么，查不到什么。
这三个东西是邮件系统的基础防线。SPF 查的是"发件服务器 IP 是否在域名授权列表里"；DKIM 查的是"邮件内容发出去后有没有被篡改"；DMARC 查的是"SPF 和 DKIM 的结果是否和发件域名对齐"。
但注意一个关键漏洞：这三项验证只能确认"这封邮件确实来自该域名授权的服务器"，不能确认"这封邮件的意图是善意的"。
像这次 Google Cloud 被滥用的事件，攻击者在 Google Cloud 里建了一个自动化工作流，配置发件人为
完成标准： 你能说清楚——邮件验证通过，只能说明"来源机器是合法的"，不能说明"这封邮件的内容和链接是安全的"。
第二步：即便域名是真的，重点看邮件里的链接指向哪
目标是：拦截攻击链中真正致命的那一步——跳转。
怎么做： 在邮件正文里，别点任何链接。把鼠标悬停在按钮或链接上（手机端长按），看屏幕底部或弹出的提示框里显示的真实 URL 地址。
这次 Google Cloud 钓鱼攻击的套路是：邮件里的初始链接指向 storage.googleapis.com——这也是 Google 的官方域名，托管了一个极简的 HTML 页面。你点开后，这个页面会通过 JavaScript 或 meta 刷新，自动跳转到真正的钓鱼网站，比如 verify-login-secure[.]xyz。
只认第一步链接是远远不够的。 攻击者用官方域名托管页面，把跳转动作藏在了页面代码里。你看到的是 google.com 的链接，点进去可能已经被带到别处了。
完成标准： 你悬停后看到的域名，应该是你预期要访问的那个。如果跳转后的域名多了一个字母、少了一个字母、或者用了 -security、-help 这类看起来官方实则私注的域名，立刻关掉。
第三步：用"防钓鱼码"做最后的绝杀判断
目标是：用一个只有你和交易所知道的暗号，直接判真伪。
怎么做： 登录交易所官网（手动输入网址，别从邮件进），在安全设置里找到"防钓鱼码"或"Anti-Phishing Code"。设一个你能记住、别人猜不到的词或数字串。
设定好之后，官方发给你的每一封邮件正文里，都会显示你设的这个码。比如你设的是 我在2021年养的第一只猫，那真邮件的末尾一定会出现这句话。
钓鱼邮件永远显示不出你设的这个码。 因为攻击者不知道你设的是什么，也无法从交易所系统里偷出来。这就是一锤定音的判断依据。
不同交易所设置路径略有不同：
情况 A：Binance 用户 路径：登录官网 → 右上角头像 → 账户安全 → 防钓鱼码。设置后，所有官方邮件和部分短信都会包含该代码。
情况 B：KuCoin 用户 路径：个人中心 → 安全设置 → 安全码（防钓鱼码），需设置为 8 位纯数字。设置成功后，官方短信末尾会显示 [Safe Word: 你设置的8位数字]。
完成标准： 你收到邮件后，核对正文里是否出现了你设置的防钓鱼码。有且正确 → 真邮件。没有或内容不对 → 直接判假，举报+删除。
常见失败原因： 很多人只扫了一眼发件人域名，看到 @google.com 或 @binance.com 就觉得万事大吉。但这轮攻击打的就是你这个信任惯性。发件域名是真的，页面托管域名也是真的，唯独最后的登录页面是假的。你只要在假页面输了账号密码，钱就没了。
操作完成的校验方式： 现在就去你用的交易所，把防钓鱼码开了。这是判断邮件真伪最硬核的一道防线。开完之后，下次再收到任何"安全警报"、"异常登录"、"提现确认"邮件，第一件事不是点链接，是翻到邮件正文找你的防钓鱼码。
