假客服短信和钓鱼邮件的老套路，是把自己的邮件伪装成交易所官方发出。很多人以为发件人显示成官方域名就代表邮件真的来自那个域名——这个判断在邮件协议里恰好是最不可靠的一环。机制说明撰写于 2026 年 9 月，本文解释交易所与所有正规机构邮件背后共同依赖的三层发件人验证机制：SPF、DKIM 与 DMARC，以及普通用户如何把它们变成一个具体的自查动作。具体品牌是否启用、启用策略如何，请以各平台公开的 DNS 记录与官方安全页面为准。
先理解问题出在哪。电子邮件的源头协议设计得很早，发件人地址这行字任何人都可以随便写，就像信封上寄件人一栏可以用笔涂改。传统上收件方没有任何手段核实”这封信是不是这个域名的服务器发出的”。三层验证就是给邮件系统补上的三道盖章程序。第一层 SPF：域名的所有者在公开的域名解析记录里声明”允许哪些邮件服务器代表我发信”，收件服务器核对这封信的实际发出服务器是否在这份白名单里。第二层 DKIM：正规发件方在邮件上附加一个用域名私钥生成的数字签名，收件方用公开在 DNS 里的公钥验签，签名有效说明内容从发出去之后没有被改过，也确实来自持有私钥的那一方。第三层 DMARC：域名所有者声明”当 SPF 或 DKIM 校验失败或域名对不齐时，收件方应该拒绝、隔离还是仅仅上报”，并留下接收报告的地址。三道章合起来，才让”伪造某域名发件人”从一件零成本的事变成一件大体做不成的事。
DMARC 里有个容易被忽略的细节叫域名对齐：SPF 通过的可能是邮件实际经过的某台中转服务器所在域名，DKIM 签名可能来自第三方发信服务商的子域名，DMARC 要求其中至少一项的域名与你看到的那个发件域名一致或同属一个管理域，才算真正通过。这解释了为什么有些骗子确实拼凑出了”SPF 通过”的邮件却过不了 DMARC——他们借的是别人家的合法发信服务器。对用户的实际含义是：邮件头里的验证结果要连起来看，一项 pass 不等于整体可信。
那么普通用户能做什么？多数网页邮箱在邮件详情里提供”显示原始报文""查看邮件头”的入口，里面通常有 authentication-results 一行，SPF、DKIM、DMARC 各自标注 pass 或 fail。这不要求你懂协议细节，只需要养成一个动作：凡是邮件里带链接、带附件、要你登录或转账的，先花二十秒查这一行。三项都是 pass、且发件域名拼写与官网一致，可信度上一个台阶；出现 fail 或 none，或者域名是官方域名加奇怪后缀、连字符变体，直接按钓鱼处理。手机系统邮件客户端往往不展示邮件头，遇到重要邮件换到网页邮箱里再看一遍原件。
同时要给这套方法划清边界，它防的是一类攻击，不是全部。DMARC 管不住短信和站内消息，管不住一个真实被盗的员工邮箱发出的邮件（三层验证会全部通过，因为邮件确实来自真服务器），也管不住攻击者用刚注册几天的新域名冒充”客服服务中心”——那种域名没有任何历史，三层验证可能都是合法的 pass。所以邮件头核验要和其他信号叠加使用：交易所真正的敏感通知机制、链接落地域名、是否需要你输入密码，这些维度共同决定一封邮件的处理方式。任何要求你在邮件链接里输入密码、验证码或下载文件的交易所邮件，无论验证结果多漂亮，都应该改从官方 App 或手动输入的官网进入验证。另外，正规交易所普遍会在帮助文档里声明自己不会通过邮件索要的内容清单，这份清单比任何单封邮件的措辞都更值得先读。
总结一下自查顺序：看域名拼写，查邮件头三项验证，回官方渠道核对是否真有这则通知，最后才决定点不点。把这四步固化成条件反射，伪造官方邮件这一整类攻击的性价比就会掉到攻击者的底线之下。本文提供的是防御性技术常识，不构成投资建议，也不构成对任何平台安全能力的认证。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。