Actionable Knowledge
检测只是开始。这里把常见结果翻译成处理顺序、验证方法和容易踩坑的边界。
Guide 01
先处理证据明确、影响直接的问题，再看需要上下文解释的信誉线索。一个高分不代表网站没有漏洞，一个低分也不一定意味着正在被攻击。
域名到期、证书过期、DNS 地址或权威委派错误会直接导致业务中断，应立即确认负责人和修复期限。
安全头和 TLS 配置通常有明确修复路径，但 CSP 等策略上线前必须在真实页面验证兼容性。
黑名单或多引擎命中需要结合记录时间、列表类型、访问日志和当前业务行为解释。
记录修复前报告、变更内容和修复后结果；DNS 与缓存传播期间不要过早判断失败。
Guide 02
IP 信誉是时间相关的外部信号，不是身份判决。云主机、共享出口、移动网络和已重新分配的地址都可能带来历史噪音。
确保告警中的 IP、事件时间和查询结果属于同一使用周期，避免拿历史租户记录判断当前资产。
垃圾邮件、代理、扫描和恶意软件控制是不同问题，需要不同日志与处置方式。
对真实用户场景应优先增加验证、限速或二次确认，并监控误判和申诉。
停止异常流量、修复主机或联系供应商后，按列表要求申请复核并持续观察。
Guide 03
DMARC 的核心不是“有没有一条记录”，而是所有合法邮件能否通过 SPF 或 DKIM 对齐。过早拒收可能让官网、工单、营销或第三方平台的正常邮件一起失败。
列出所有合法发信平台、退信域、DKIM 选择器和业务负责人，清理未知或停用来源。
使用 p=none 收集汇总报告，至少覆盖正常业务周期，并确认主要来源已经对齐。
从较低比例的 quarantine 开始，持续监控退信和用户反馈，再逐步提高比例。
只有在合法来源清晰、例外已处理、恢复流程可用时，才评估 p=reject。
Guide 04
泄露记录意味着某个历史系统暴露过相关数据，不等于邮箱本身当前已被接管。处理重点是识别受影响账号、切断密码复用并检查异常会话。
记录事件名称、暴露时间和可能泄露的数据类型，谨慎对待要求输入密码的所谓查询页面。
为受影响账号更换独立密码，并检查其他网站是否复用了相同或相似密码。
启用多因素认证，退出其他会话，检查邮箱转发规则、恢复方式和近期登录。
按用途使用别名，减少主邮箱公开范围，并为重要账号设置独立恢复渠道。