1. Direct Send机制解析：它是什么，为什么总被盯上
先聊一个真实场景：某公司安全管理员在邮件追踪日志里发现，公司内部域名下有大量邮件根本没经过公司邮件网关，直接从外部IP进了员工收件箱。邮件显示发件人是CEO，内容是“紧急：请立刻把本月供应商付款清单发我”，语气急促、格式简陋、落款缺失。仔细一查，发件服务器是某个云主机IP，连反解记录都没有。这不是个例——这类攻击利用的正是Exchange Online里一个默认开放、常被忽略的功能：Direct Send。
Direct Send，直译是“直接发送”，是Exchange Online为特定场景保留的匿名中继通道。它允许没有邮箱的应用程序、打印机、多合一设备、业务系统通过SMTP协议直接向组织内部的收件人投递邮件，无需对发件人进行身份验证。很多人第一次意识到它的存在，是在配置“扫描仪发送扫描件到邮箱”的时候——IT管理员在Exchange管理中心填一个连接器，域设为组织自己的域名，然后把公司打印机IP加进允许列表，配置就算完成了。日后再有来自这些IP的邮件，系统默认它们是可信的“内部设备”，直接放行到收件人邮箱。
这个机制本身是为可用性设计的，而可用性和安全性往往是一对此消彼长的矛盾体。Direct Send不需要身份验证，意味着它无法回答一个最基本的问题：发件人真的来自你声称的那个域名吗？攻击者只要让SMTP对话里的MAIL FROM字段显示为内部域名的某个地址，再通过一个被允许或未受限的通道把邮件发进来，收件人看到的就是一封来自“内部同事”或“领导”的邮件。如果收件人的客户端没有正确显示外部发件人标记，这封邮件就和真正的内部邮件几乎无法区分。
我遇到过不少同行在刚开始排查这类问题时，第一反应是怀疑用户密码被泄露、账号被盗。查了一圈日志发现登录记录干干净净，最后才想起去看传输日志，结果是某个设备IP偷偷发了钓鱼邮件。这也是这篇文章要专门讲Direct Send的原因：它和其他攻击手法的最大区别在于，攻击者不需要拿到任何账号口令，只需要找到一个可以利用的中继通道。理解了这个前提，防御思路自然就清晰了——不是去猜谁被钓鱼，而是先去堵住那个匿名通道。
同时要说明的是，Direct Send不是漏洞。微软官方文档明确记录了它的存在和用途，它只是被滥用了。真正的问题是很多组织在启用时没有做足够的限制，也没有意识到这个功能上线后，等于在自家邮件系统门口开了一扇不设门禁的侧门。这篇文章会从机制原理、攻击构造、检测方法到防御配置，完整走一遍我在实际项目里总结出来的排查路径和防线设计。
2. 攻击者的利用链条：从伪造到绕过检测的完整拆解
2.1 攻击构造的核心：伪造内部发件人为什么容易成功
攻击者要在Direct Send上构造一封看起来来自内部的钓鱼邮件，需要三个要素：可达的SMTP端点、允许的目标域名、按约定格式构造的邮件会话。前两个要素通常是配置层面的遗留问题，第三个要素则完全是协议层面的基础操作。
SMTP协议从诞生起就没有内置身份认证，MAIL FROM、RCPT TO这些命令参数都只是文本字符串。客户端说什么，服务器就信什么。攻击者在自己的服务器上执行以下步骤：
- 连接目标组织Exchange Online的接受域端点（通常是org.mail.protection.outlook.com，这是组织对外公布的MX指向地址）；
- 提交HELO/EHLO指令，声明客户端身份；
- 发送MAIL FROM，把地址写成内部域名的任意邮箱；
- 发送RCPT TO，指定受害者邮箱；
- 输入DATA，写入RFC 5322标准格式的邮件头和正文。
如果组织的Direct Send连接器允许匿名来源并且目标域匹配，这封邮件就会进入投递管道。攻击者不需要知道任何密码，不需要访问任何服务器，不需要在组织内先踩点。身份验证为零，信任全建立在IP地址和域名格式匹配上。
更麻烦的是，如果攻击者能找到一个与组织在同一个接入网络段、或者能伪造来源IP的场景，连连接器里的IP白名单都可能被绕过。虽然伪造TCP层来源IP在互联网环境下很难，但攻击者可以退而求其次——找那些配置了宽泛IP范围的连接器。比如有的公司为了省事，将多云厂商的整个IP段都加了进去，这些段里有任何一台机器被攻破或者被转租，都能直接复用这条通道。
从攻击者视角看，Direct Send还有一个隐藏优势：邮件流的日志记录往往不完整。因为这类邮件没有对应的邮箱登录事件，安全团队按“用户登录异常”去查怎么都查不到，而传输日志如果没开启详细记录，邮件头里也不会留下完整的Received链。攻击者构造的邮件头往往很短，甚至只有一个From和To，这反而是识别点——正常内部邮件经过多个传输组件，Received头通常有多行，Direct Send邮件往往只有一条来自边缘的连接记录。
2.2 绕过检测的三层策略：SPF、DKIM和DMARC为何集体失灵
我知道很多读者看到这里会问：组织不是配了SPF、DKIM、DMARC吗？为什么这些邮件还能进得来？
问这个问题说明你对邮件安全的认知已经有了框架，但恰好是这三件套的盲区，让Direct Send攻击能反复得手。
第一层，SPF（Sender Policy Framework）检查的是MAIL FROM域的授权发送服务器。如果组织在SPF记录里只列了Exchange Online的IP和第三方邮件服务商的IP，理论上外部直发的邮件应该被判定为失败。但要注意两个前提：一是SPF的检查节点在哪，二是接收端对SPF失败结果的处理策略。Exchange Online在接收外部邮件时默认是宽松模式，SPF失败不会直接拒收，而是标记为spf=softfail或spf=fail，然后继续投递到收件人垃圾邮件评估流程。垃圾邮件筛选对纯SPF失败的信誉权重并没有大多数人想象得那么高。
第二层，DKIM（DomainKeys Identified Mail）检查的是签名域和签名有效性。Direct Send通道根本不会对邮件做DKIM签名，因为它不是从Exchange Online正常出站管道走的。但Exchange Online在接收邮件时，对无签名的邮件并不会因为“缺少DKIM”就拒收，DKIM只是信誉分的一部分。
第三层，DMARC（Domain-based Message Authentication, Reporting, and Conformance）通常采用两种策略之一：p=quarantine或p=reject。quarantine策略下，DMARC失败的邮件被丢进垃圾邮件文件夹而不是直接拒收。但很多用户会主动查看垃圾邮件文件夹——尤其是当他们在等一封“紧急”邮件时。更重要的是，DMARC的对齐检查会看From头域，如果攻击者不只伪造MAIL FROM，还把From头同时改成了内部域名，而SPF结果又是permerror（语法错误）或temperror（临时错误），DMARC会走“无法判定”分支，邮件照样进得去。
某次我为一家公司复盘钓鱼事件时，发现攻击者甚至没有费心伪造SPF策略结果。那家公司的域名没有发布DMARC记录，接收端默认对所有邮件都执行none策略——不拒收也不隔离，只报告。这就等于三件套里两件没穿，光有一件SPF还不顶用。防御邮件欺骗不能只靠“有”，还要看“怎么配、配到什么等级、失败后执行什么动作”。这三层防线单独看都合理，但串起来只要有一层松懈，Direct Send邮件就能钻穿。
2.3 攻击场景图谱：谁在实际攻击中盯上了Direct Send
从真实攻击样本看，利用Direct Send机制的钓鱼主要有三类场景。
第一类是“假装领导催办”。攻击者伪装成CFO或部门总监，向财务、采购、行政发紧急指令，要求“马上转账”“立刻购买礼品卡”“把通讯录导出发我”。这类邮件文本极短、无签名、无附件，强调时效性，利用的是员工在压力下的判断力下降。我在一次演练中构造过类似场景：邮件标题“在吗”，正文“我在开会，帮我查一下上季度差旅报销最高的三个人发我，速回”。在未做任何防护的对照组里，点击率和回复率都超出预期。
第二类是“预告式投毒”。攻击者先发一封看似无害的“系统通知”或“会议邀请变更”，不急着植入恶意载荷，而是等收件人回复后，再以“回复链”的形式二次投递恶意链接或带宏附件。因为攻击邮件本身进入了内部邮件流，后续回复和转发都会带上攻击者的原始邮件头，在收件人客户端里看起来像完整的内部对话。这种做法的可怕之处在于：安全网关对第二封邮件的检测会被“这是内部线程”的上下文干扰。
第三类是“身份叠加欺骗”。攻击者利用Direct Send发一封声称来自“IT服务台”的密码重置通知，正文附带一个指向钓鱼页面的链接。页面同样模拟组织的登录界面，并且预先填入了员工邮箱前缀，受害者往往毫无防备就输入了密码。这个场景里，Direct Send邮件是入口，后续是凭据窃取链，最终可能演变为BEC（商业电子邮件诈骗）或内部横向移动。
这三类场景不是孤立的，攻击者常常混搭使用。比如先用“领导催办”试探组织邮件流的防护强度，等确认Direct Send通道畅通，再切换到“身份叠加欺骗”发起真正的凭据窃取。作为防御方，理解场景图谱的意义在于：排查和监控不能只盯单一特征，要建立“行为画像”的概念——谁在什么时间从什么渠道给你发了什么内容的邮件，三者组合是否合理。
3. 检测与发现：如何靠日志和邮件头抓住攻击
3.1 消息追踪与邮件头分析：找到那封“不该存在的内部邮件”
检测Direct Send攻击的第一步，是能回答一个基础问题：组织的邮件系统里，有没有从非正规通道投递的“内部域名邮件”？在Microsoft 365生态里，最直接的抓手是Exchange Admin Center的“消息追踪”功能。
消息追踪的操作路径是：Exchange Admin Center → 邮件流 → 消息追踪。搜索条件设为“发件人为内部域名的邮件”，时间范围按需拉长，然后在结果列表里看“源IP”和“状态”字段。正常从Exchange Online客户端（Outlook、Outlook Web App）发出的邮件，源IP一般是微软数据中心的内部IP段，扫描仪等设备的邮件则来自你配置过连接器的IP。如果你看到源IP是一串完全不属于组织、也不属于微软官方的地址，这封邮件就有极大的Direct Send嫌疑。
这里有个细节：有权限在Exchange Admin Center做消息追踪的管理员，至少要有“邮件收件人”或“邮件流”的管理角色。如果组织中管理员权限分散，建议由一个团队统一负责邮件安全相关日志和追踪权限，避免出现“发现线索但查不了日志”的尴尬。
拿到可疑邮件后，下一步是导出邮件头。方法有两种：一是通过消息追踪结果选中邮件，点击“导出”按钮，系统会生成包含完整邮件头的文件；二是让终端用户在Outlook里双击邮件 → 文件 → 属性，查看“Internet邮件头”。邮件头里的核心识别点有三个：
3.1.1 Received头溯源
正常内部邮件的Received头会有多条记录，分别对应Exchange Online的边缘传输、内部传输和邮箱服务器。Direct Send邮件通常只有一到两条Received记录。第一条Received会显示连接来源IP和发起HELO的客户端标识，如果HELO名称看起来像是伪造的域名或乱码，风险直接拉满。
3.1.2 Authentication-Results头缺失
Microsoft 365正常接收的邮件会带有Authentication-Results头，记录SPF、DKIM、DMARC的检查结果。Direct Send邮件因为绕过了正常外部入站检查管道（或者只是部分经过），这个头的呈现方式会有明显差异。比如，你会发现SPF字段后面跟着的是“sender-id=temperror”或干脆没有DKIM字段。这些细节单独看都不致命，但要读出“这封邮件没有经过完整的认证链”这个信息，组合在一起看就非常清楚了。
3.1.3 邮件路径与返程路径不一致
正常内部邮件的Return-Path、From、Sender字段通常是同一地址。Direct Send邮件可能出现From显示为“ceo@contoso.com”而Return-Path是“attackerMailbox@somewhere.net”的情况。虽然Exchange会尽力修复这种不一致，但在一封不走正规验证管道的邮件里，不一致依然时有发生。
我在实际排查时有一个固定动作：把可疑邮件的全部邮件头复制出来，丢进微软的邮件头分析器（Message Header Analyzer）之类的工具里跑一遍，可视化呈现邮件从发件人到收件人经过的所有节点。这个工具能直观地告诉你，所谓内部邮件到底是不是真的从内部来的。如果你看到节点列表里出现了一个不属于组织、也不属于微软的IP，结论基本就定了。
3.2 日志检测与审计：让每一次匿名投递都留下痕迹
只等用户报告钓鱼邮件再做响应，属于被动防御，效率太低了。更好的做法是在日常运行中就建立检测基线，让Direct Send的异常使用模式能被主动识别。这里涉及几个日志源和检测思路。
Microsoft 365的审计日志（Unified Audit Log）默认记录的是Exchange Online的管理操作和部分用户操作。对Direct Send场景而言，最有价值的日志是“Message trace”日志和“连接器”相关变更日志。生产环境建议把消息追踪日志的标准周期（默认30天）通过Exchange Online的“邮件流规则”或第三方SIEM集成，实时同步到集中日志平台。这样即便攻击邮件被用户删除，安全团队也依然能从日志里还原痕迹。
检测重点可以围绕几个规则展开。
规则一：所有源IP不在允许列表内的Direct Send投递尝试。Exchange Online连接器如果设置了IP限制，超过限制的投递会被拒收并生成事件。但要注意，默认新建连接器时IP限制可以是空——也就是允许所有IP。如果你的连接器是空的IP限制，检测规则就形同虚设。
规则二：短期内同一源IP向多个人员投递内部域名邮件。但这里要区分正常批量场景和攻击场景。比如人力资源部用打印机批量打印工资单、公司群发邮件到全员，都会有类似模式。更有效的区分维度是邮件内容的发件人显示名是否匹配已知员工姓名，以及邮件是否有DKIM签名。
规则三：使用“非工作时段”的Direct Send邮件投递。大部分员工不会在凌晨两点用打印机发扫描件。把时段特征加入检测规则，能显著降低误报率。
规则四：邮件头里出现异常HELO名称。很多攻击者用自动化脚本发信，HELO名称要么是IP地址本身，要么是一串无意义的随机串，极少会伪装成组织服务器的标准名称。将HELO名称与已知邮件系统的标准值做比对，是一个有效过滤器。
这些规则的落地方式有两种：一是写在Exchange Admin Center的“邮件流规则”（Transport Rule）里，设置命中后进入隔离、通知管理员或直接拒收；二是导出消息追踪日志到SIEM平台，用查询语言做离线和实时分析。前者适合规则明确、延迟敏感的场景，后者适合需要历史回溯和复杂关联分析的场景。
我在一次真实排查中遇到过一个很有意思的情况：某公司部署了市场上主流的邮件安全网关，但攻击邮件却直接绕过网关到达用户收件箱。复盘后发现，网关接收邮件的节点没有作为MX记录配置在公共DNS里，而Exchange Online在收不到网关投递响应时会自行入站接收。也就是说，所谓“网关防护”只是形式上存在，实际流量根本没走网关。这个教训值得所有管理员留意：防御链路不仅要有，还要确保每条入站路径都经过它。
4. 防御体系建设：从连接器加固到全链路拦截
4.1 连接器与传输规则加固：让Direct Send只给该用的人用
检测做得再好，也不如从源头把门锁好。Direct Send防御的第一件事，就是重新审视和加固现有的连接器配置。
进入Exchange Admin Center → 邮件流 → 连接器，重点核查两类对象：一是入站连接器（Inbound Connector）中配置了“Direct Send”或“On-premises”类型的项目，二是出站连接器中设置了“使用组织自身的邮件服务器”的项目。对每一条连接器都要回答三个问题：
这个连接器是给什么用的？ 使用者有没有明确的范围限定？ 如果不需要这个连接器，能不能直接删掉？
我见过不少组织在迁移到Exchange Online后，旧的本地邮件服务器已经退役了，但对应的连接器还留着。这些残余配置平时没人动，却相当于给攻击者留了一扇敞开的门。清理动作应该纳入邮件系统的变更管理流程：每次设备报废、办公地点搬迁、云服务变更时，都要同步更新连接器列表。
如果组织确实还需要Direct Send，比如打印机、扫描仪、OA系统投递邮件，一定要做三件事：一是将连接器的“限制来源IP”填上具体的出口IP段，精确到单个办公地点或云服务的段，而不是填“所有IP”；二是为这些设备单独准备一个发件域，比如scan@contoso.com、print@contoso.com，与主域区分开，方便识别和审计；三是在传输规则里对这些专用域的邮件做额外标注，比如添加自定义邮件头，便于邮件客户端或后续规则识别其来源属性。
传输规则的加固是另一层动作。优先级最高的一条建议：对“发件域是组织主域名，且来源连接器不是组织正规出站通道”的邮件，直接执行隔离或拒收操作。这个规则基本就是为Direct Send攻击量身定制的。配置方式是在Exchange Admin Center → 邮件流 → 规则中新建规则，条件选“发件人位于组织外部”（如果邮件来源会被识别为外部）或“发件人的域是contoso.com”，操作为“将邮件隔离”并“发送通知给安全管理员。执行顺序上，这类规则应当放在所有规则列表的最前面，避免被其他宽松规则覆盖或跳过。
需要注意一个技术细节：Direct Send邮件在Exchange Online内部并不会自动标记为“外部邮件”。因为Exchange信任连接器配置，又看到发件域是内部域，它会认为邮件来源是可信的。这也是为什么传输规则里“发件人位于组织外部”这个条件并不总是会命中——有时候你需要在规则里改用“发件人IP位于以下范围之外”之类的条件。所以更稳妥的做法是：先通过连接器上的IP限制把来源控制住，再结合传输规则做二次校验。
4.2 邮件安全策略配套：默认设置不是终点
仅靠连接器加固还远远不够，因为攻击者会不断尝试寻找新的可利用通道。更完整的防御体系需要叠加邮件安全策略，核心目标是把“未经身份验证的邮件”和“可疑的外部邮件”从一开始就隔离或标记，让Direct Send攻击即使进入管道，也到不了用户收件箱的显眼位置。
Exchange Online Protection（EOP）的反钓鱼策略是第一条配套防线。进入安全门户 → 策略 → 反钓鱼，找到默认策略，确保以下选项被启用：一是“欺骗检测”开启，当邮件头中的From域与SPF/DKIM验证结果不一致时，系统会在邮件顶部显示外部发件人警告横幅；二是“域欺骗防护”，将组织的主域名和自定义域名加入保护列表，系统会单独提高这些域名的信誉门槛；三是“模拟检测”，重点保护CEO、CFO等关键高管账号，设置“被保护的模拟用户列表”。
有必要单独说明一下外部发件人警告横幅的实际效果。当Outlook或Outlook Web App收到一封From域看似内部、但实际通过外部通道投递的邮件时，客户端会在邮件顶部显示黄色提示条。有人觉得这个功能啰嗦，但对Direct Send钓鱼的实际拦截效果极好——因为攻击者无法消除这个横幅，除非他们真的攻破了Exchange Online的身份认证机制，而那不是本文讨论的匿名通道场景。建议组织统一开启这个功能，并在员工安全培训中明确说明：看到黄色提示条，意味着发件人身份未被验证，任何要求转账、发敏感信息的指令都先电话核实。
除了EOP内置策略，还需要考虑扩展恶意软件和链接检测能力。微软默认的EOP对已知恶意链接的拦截效果不错，但针对零日或定向攻击的新链接，依赖信誉库可能不够。微软的Defender for Office 365的“安全链接”和“安全附件”功能是有效的补充：安全链接会在用户点击链接时实时检测目标地址，安全附件则会在沙箱中执行附件。对于规模较小的组织，可以考虑通过条件访问策略限制邮件访问的设备范围，或者添加第三方邮件安全服务，让入站邮件先经过一层独立的信誉过滤。
策略配置的最后一个要点是“不变量”。很多组织在配置完反钓鱼策略后就不再关注，但邮件系统的默认值和微软的推荐设置会随安全趋势不断调整。我建议每季度复查一次安全门户的所有策略状态，重点看有没有“未启用”的推荐项、有没有被用户创建但未更新的自定义策略、有没有被紧急事件临时放宽但忘了恢复的例外条款。
4.3 用户意识与应急响应：人是最薄弱的环节，也是最后一道防线
技术防线做得再完整，一旦有人点了一个恶意链接，一切防护都有可能被绕开。所以，Direct Send攻击防御体系的最后一环，一定是面向用户的安全意识培养和应急响应机制。
针对这类攻击，用户培训的重点不是泛泛的“不要点击陌生链接”，而是情境化的规则：凡是邮件里提到转账、购买礼品卡、紧急修改账号信息，无论邮件看起来来自领导还是IT服务台，都要通过电话、企业IM或当面方式二次确认。攻击者利用的是“紧急”和“权威”这两张牌，培训要做的就是拆掉这两张牌的效果。
一些组织会把安全意识做成固定季度活动，但效果往往不持久。更有效的做法是“小规模定期演练”：每季度由安全团队内部构造一封模拟Direct Send钓鱼邮件，投递给随机抽样的员工，统计点击率、回复率和报告率，然后针对点击率高的团队做定向加强培训。演练邮件的构造方式可以参考攻击者手法——用内部域名、伪装领导语气、含外部链接，配置专用连接器来投递，确保不污染生产邮件流。这样每次演练既是检测，也是实战验证：如果模拟邮件还没到用户手里就被传输规则或EOP拦截了，说明技术防线正在发挥作用。
应急响应机制同样需要提前演练。组织内应明确：谁负责查消息追踪、谁负责隔离邮件队列、谁负责通知用户删除邮件、谁负责对外沟通。许多小组织把应急响应分配给“懂点IT的人”来兼任，但一旦攻击真实发生，一两个人在压力下往往难以同时完成排查、处置和报告。建议提前写好一份可操作的应急手册，把每一步要查的系统、要看的字段、要执行的命令都列出来，平时按手册演练一遍，在真实攻击发生时就不会慌乱。
5. 实战复盘：一次模拟攻击从投递到拦截的完整过程
5.1 模拟攻击构造与投递记录
为了更直观地展示Direct Send攻击的检测与防御效果，我结合某公司实际演练项目做过一次完整的模拟。这里用“某公司”作为项目代称，目标域名统一用contoso.com代替。操作仅限授权范围内的安全测试环境。
第一步，准备一台独立云主机作为攻击跳板，安装一个简单的SMTP客户端工具。在工具里执行简单的SMTP会话，连接目标的入站端点。这里的入站端点不是邮件网关的公开MX地址，而是专门用于接收Direct Send的Exchange Online入口。然后依次提交EHLO、MAIL FROM（伪造为ceo@contoso.com）、RCPT TO（目标为财务部员工）、DATA。邮件正文很简单：“我在开会，马上有一笔紧急付款需要处理，你现在方便吗？确认后我发你具体户名和账号。”不携带附件，不包含任何URL——只是一封纯文本的“试探接触”邮件。
模拟结果分为三种情况。
情况一：未做任何防护加固。邮件在数秒内进入收件人邮箱，显示为发件人CEO，无外部标记。这条基线数据说明：在默认配置的Exchange Online租户里，Direct Send攻击是完全可行的。
情况二：连接器加固完成、IP限制生效。模拟邮件在SMTP阶段就被拒收，返回状态“451 4.7.0 Temporary server error. Please try again later”，同时消息追踪日志里会出现一条“拒绝”记录。我的实操体会是：从此类日志的源IP和拒绝原因字段可以很快定位到连接器配置，确认是否有漏网IP段。
情况三：连接器允许但传输规则隔离。模拟邮件被接收进管道，但命中传输规则后进入隔离邮箱，安全管理员收到通知。这种模式下，攻击者能看到的是“250 OK”，认为邮件已成功投递，但实际上它被隔离在管理员的审核区。这个设计的优势在于：你不仅能“防御”，还能把攻击者的构造手法留在隔离区里做分析。
5.2 防御配置检查清单
结合多次项目复盘，我把一套可直接落地的检查清单记录如下。
首先，检查所有入站连接器。类型为On-Premises且启用了Direct Send的连接器，逐一核对IP限制是否已填写；没有明确用途的，一律停用或删除。
其次，在发送域配置中，确认组织的权威域（Accepted Domain）里没有意外加入“内部中继”类型的域。内部中继域会让邮件系统对某些域采取更宽松的入站策略，攻击者如果找到一个内部中继域，伪造进而难度会大大降低。
然后，检查传输规则列表里是否有一条针对“内部域名发件人+外部来源”的强制隔离规则。如果没有，立即依据前文所述规则补充，并设置好规则优先级。
再次，确认EOP反钓鱼策略中的欺骗检测、域保护、模拟检测均已开启，且组织主域名加入了保护的域列表。
最后，把消息追踪日志导出到SIEM或集中日志平台，建立一条检测规则：检索条件为“发件域等于主域名且源IP不在允许列表内”的投递尝试，产生告警。这个规则能在攻击者还在踩点阶段时给你发出信号。
5.3 经验教训与注意事项
模拟过程的每一次读_response数据和配置行为，都会带来一些实际教训。这里分享几条最值得注意的。
在Only接收模式或隔离模式时，不要把消息追踪的默认日志留存时间调得太短。邮件被隔离后，管理员可能过了几天才去查看，如果日志早就被覆盖，后续分析就无从下手。Exchange Online默认的邮件追踪日志保留期通常是30天，但对于生产环境的关键租户，我建议即便存储成本有限，也要保证这个周期内日志可查。
需要特别提醒的是，隔离邮件不能直接转发给用户，否则会绕过检测。有些管理员在处置隔离邮件时，图省事直接用“一键转发到收件人”，结果把一个标定为可疑的邮件重新放行到员工收件箱，这是本末倒置的做法。正确的处置方式永远是：先分析邮件头和正文，确认确实无害后，再决定是否释放；无法确认的不如直接删除，让发件人从正规渠道重发。
另一个细节是SPF记录的“-all”与“~all”选择。无论采用哪个，都建议在DMARC策略中设置p=reject。很多人担心p=reject会影响正常邮件投递，但在做好SPF/DKIM的情况下，这个担忧大多是不必要的。一次配置后，持续跟踪一段时间的DMARC报告，观察有没有合法的发信源被误拒，远比一直停在p=none阶段要主动得多。
6. 长期运营与持续优化
6.1 建立邮件安全日常巡检机制
防御配置不是一劳永逸的。攻击者会持续扫描目标组织的MX记录、连接器配置、SPF策略，寻找可趁之机。作为管理员，你最好也能定期做同样的审视，只不过目的不同：你要赶在攻击者前面发现并修复自己的盲点。
我建议邮件系统管理员把以下项目纳入月度巡检清单：查看消息追踪日志中是否有异常的“内部域名邮件”投递记录；核对连接器列表，确认没有新增可疑项；审查发送域配置，防止内部中继域被意外添加；确认反钓鱼策略中的域保护和模拟保护列表仍与实际组织架构匹配；员工入职、离职频繁时，提醒人力资源部门同步更新邮箱和通讯组信息，防止离职员工或失效通讯组成为发件人伪造的目标。
这些巡检动作虽然看起来琐碎，但在实际运营中价值极高。一次月度巡检如果发现了3条可疑记录，哪怕是误报，也会让你对组织邮件流的“正常”状态有更清晰的感知。有了基线数据，日后任何异常都能更快速地被识别出来。
6.2 与身份安全策略联动
Direct Send攻击是邮件层面的问题，但它与身份安全密不可分。攻击者利用匿名通道发出钓鱼邮件，往往只是第一步，后续可能诱骗用户输入凭据、点击恶意链接、甚至发起内部钓鱼传播。因此，邮件安全的长期运营必须与身份安全联动。
一个可行的做法是，在条件访问策略中为高风险邮件触发链路增加额外控制：当用户访问邮箱或登录企业应用时，如果来自该用户终端的网络信号异常（例如使用了不同的IP地理位置、设备不满足合规要求），强制进行多因素认证和额外验证。同时，对高权限账号（邮箱管理员、财务系统管理员、HR系统管理员）实施专属的条件访问策略，提高其登录风险和操作门槛。
更进一步，可以在身份安全侧开启“异常登录检测”和“风险用户”告警。当疑似来自钓鱼邮件的受害者访问了恶意站点并输入密码后，身份平台会在后续登录尝试中捕捉到异常特征，及时触发密码重置和会话终止。这样，即使Direct Send钓鱼邮件成功骗到了一个账号，后续的横向移动也会被身份层控制住。
6.3 安全文化建设：让技术以外的防线同样牢固
最后想聊一个经常被技术类文章忽略但实际影响巨大的点：组织内的安全文化。
我参与过多个钓鱼演练项目，有一个共同规律：员工是否会上当，与组织是否建立了“多路径核实”文化有强相关性。那些在制度上明确规定“所有转账指令必须电话确认”的公司，即使接收到了非常逼真的Direct Send钓鱼邮件，员工的警觉性也显著高于那些只发过几次“警惕钓鱼邮件”通知的公司。后者更像是在墙上挂了一张安全海报，前者则是把安全要求写进了流程、嵌入了考核。
一个简单有效的落地动作：在新员工入职培训中加入8分钟的邮件安全情景演练，用内部构造的Direct Send模拟邮件“袭击”新员工，并当场讲解识别点。参加过这个环节的人，之后遇到真实钓鱼邮件时，识别速度往往明显更快。
另一个做法：把“报告可疑邮件”设计得足够简单。不要在邮件报表按钮上让用户陷入思考——用一键“报告钓鱼邮件”按钮，或者干脆让用户直接把可疑邮件转发到一个专用邮箱，由安全团队统一分析。降低报告成本，就是在提升实际响应率。
这些安全文化的建设成本很低，收益却能在一次真实攻击中放大无数倍。技术防线堵住了大多数攻击，但总有漏网之鱼会抵达用户端。在那一刻，真正能拦住攻击的就是用户脑子里那根“多核实一次”的弦。
