邮件安全与钓鱼防护实战

SMTP 协议本身不校验发件人：
  FROM: ceo@company.com   ← 任何人都能写这一行

攻击者伪造发件人 → 收件人信任发件人 → 点击恶意链接/附件
这就需要在"信封发件人"上增加验证机制。

SPF（Sender Policy Framework）：
  在 DNS 中声明"哪些 IP 有权以我的域名发信"
  收件方反查 DNS，比对发送 IP 是否在白名单

# 域名的 DNS TXT 记录
example.com.  TXT  "v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 include:_spf.google.com -all"

字段说明：
  v=spf1              SPF 版本
  ip4:203.0.113.10   允许的 IPv4 发送地址
  include:_spf.google.com   引入第三方（如邮件服务商）
  -all                不在列表的一律拒绝（硬失败）
  ~all                不在列表的标记可疑（软失败）

SPF 只验证"信封发件人"（MAIL FROM），
不验证"显示的发件人"（Header From），两者可能不一致。
另外，转发场景（邮件经过中间转发服务器）容易 SPF 失败。

所以 SPF 单独用不够，必须与 DKIM、DMARC 配合。

DKIM（DomainKeys Identified Mail）：
  发送方用私钥给邮件头与正文签名
  收件方用 DNS 中的公钥验签

  · 签名覆盖：From、Subject、正文关键部分
  · 验签通过 → 邮件内容未被篡改、确实由该域名发出
  · 不依赖转发链：即使经过转发，签名依然有效

# DNS 公钥记录（选择器 s1）
s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

发送服务器侧（示意）：
  · 生成 RSA/Ed25519 密钥对
  · 私钥配置在 MTA（如 Postfix/邮件服务商）
  · 公钥发布为 DNS TXT 记录
  · 选择器（Selector）用于标识不同批次密钥，支持轮换

常见坑：
  · 换服务器忘了更新 DNS → 验签失败
  · 签名覆盖字段太少 → 关键头未签名
  · 密钥不轮换 → 长期风险

SPF 看信封发件人，DKIM 看签名，但两者各自只覆盖一部分。
DMARC 把两者结果统一起来，并让域名所有者声明处置策略。

核心概念：
  · 对齐（Alignment）：Header From 域名与认证域名是否一致
  · 策略（Policy）：p=none（只报告）/ p=quarantine（隔离）/ p=reject（拒绝）
  · 报告（RUA/RUF）：收件方回传认证结果，供域名所有者监控

# DNS TXT 记录（固定位于 _dmarc 子域）
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; sp=quarantine"

字段说明：
  v=DMARC1            版本
  p=quarantine        主域策略：可疑邮件进垃圾箱
  pct=100             100% 邮件应用策略
  sp=quarantine       子域策略
  rua=...             聚合报告接收地址
  ruf=...             取证报告接收地址

三步走，避免一封邮件都发不出去：
  ① p=none + rua → 观察 1-2 周，看合法邮件认证率
  ② 修问题（补 SPF/DKIM、调整对齐）→ 认证率达标
  ③ p=quarantine 或 p=reject → 强制，同时监控误伤

监控要点：
  · 合法邮件的 SPF/DKIM/DMARC pass 比例
  · 误伤（合法邮件被隔离/拒绝）是否有上升
  · 未认证发件量的变化

原始链接：https://evil.example/click?user=abc

网关重写后：https://secure.example.com/url-check?url=encoded(原始链接)

效果：
  · 用户点击先经过网关
  · 网关实时查信誉库 / 打开沙箱渲染
  · 恶意则拦截并告警，安全才放行
  · 管理端能审计"谁点了什么链接"

局限：
  · 重写可能被绕过（复制链接、二维码、二维码照片）
  · 依赖情报时效，新域名可能漏判
  · 加密链接仍需在网关侧解密检查（合规要求）

第一层 来源信誉：黑名单 IP/域/发件人 → 直接拒收
第二层 认证策略：DMARC fail + 高相似域名 → 隔离并告警
第三层 附件沙箱：可执行附件/宏文档 → 沙箱检测
第四层 URL 重写：所有链接改写 + 点击时实时检查
第五层 意图分析：紧急转账、账号锁定、礼品卡等高频骗术 → 高可疑

正常业务邮件 → 不发紧急链接、不索要验证码、不要求秒回转账
钓鱼邮件 → 制造紧迫 + 单一诉求 + 高摩擦动作（转账/输密码）

实用规则：
  · 验证码绝不通过邮件/链接索取
  · 转账、改密、下载附件走独立通道二次确认
  · 对"领导"的紧急指令用电话/当面核实
  · 悬停看链接域名，与机构官方域名比对

BEC（Business Email Compromise）：
  冒充 CEO/财务，诱导员工转账或窃取 W-2、发票信息

特点：
  · 很少带恶意附件，纯社会工程
  · 发件人或域名常被真实入侵/注册相似域
  · 金额高、低频，绕过自动化检测

对策：
  · 大额转账双人复核 + 电话确认
  · 供应商/收款账户变更必须走变更流程核验
  · 对"紧急且保密"类请求保持怀疑

模拟钓鱼演练流程：
  ① 设计仿真钓鱼邮件（贴近业务、不涉处罚）
  ② 小范围灰度发送，记录点击/输入凭证/报告
  ③ 对"上当者"即时教育，不点名羞辱
  ④ 对"主动报告者"正向反馈
  ⑤ 定期统计：点击率下降、报告率上升为有效

指标参考：
  · 点击率（Phish-Prone）：越低越好
  · 报告率（Report）：越高越好
  · 输入敏感信息率：重点治理人群

· 一键报告按钮：让"怀疑"低成本变成"上报"
· 报告闭环：SOC 审核报告 → 确认真假 → 全局处置
· 快速删除：确认钓鱼邮件后全局批量删除
· 与网关联动：用户报告的钓鱼样本反哺网关情报
· 关键：把"靠个人聪明"升级为"靠机制兜底"

· SPF 记录过长超过 DNS 限制 → 拆 include 或做子域策略
· 第三方代发（营销/问卷）没纳入 → 合法邮件被拒
· DKIM 选择器更换没同步 DNS → 验签中断
· 只配不监控 → DMARC 报告无人看，问题长期潜伏
· 模拟演练只测不教 → 点击率降不下来

每日关注：
  · DMARC pass 率（合法邮件认证比例）
  · 被隔离/拒绝的合法邮件数量（误伤）
  · 相似域名伪造量（如 domain.com vs d0main.com）
  · 用户报告钓鱼量及其真伪占比