邮件认证配置指南

按问题进入

Ghost + Postmark 发信失败：验证 newsletter 的实际 From，不要只验证适配器 fallback

Ghost 会把每个 newsletter 的发件地址作为 data.from 交给适配器，fromEmail 只在该值缺失时兜底；浏览器本地 400 状态规划器会核对实际 sender 集合、Sender Signature 或 Domain Verification、broadcast stream，以及 Postmark 400、401、406 的不同边界，不收集地址、Token、消息、订阅者、配置、DNS 值或日志。

Keycloak Realm 的 SMTP 配置丢失：不要从空 export 猜配置

逐个复核目标仓库的 9 个 realm export 历史版本后确认 smtpServer 始终为空；浏览器本地 256 状态规划器把权威发件账号、Keycloak Test connection、服务商与收件证据、真实密码重置或验证链接拆开，不收集域名、邮箱、主机、端口、账号、密码、Token、export、配置或日志。

Plane SMTP 测试邮件在保存设置前返回 500：分离表单草稿与持久化配置

测试弹窗只提交收件地址，后端仍读取旧的持久化 SMTP 设置并在异常保护外转换空端口；浏览器本地 144 状态规划器把未保存表单、持久化端口、请求配置来源和真实 SMTP 阶段拆开，不收集邮箱、主机、端口值、用户名、密码、发件人、消息、Cookie、配置或日志。

Microsoft 554 5.2.252 SendAsDenied：系统 SMTP 账号不能直接冒充当前用户

把 SMTP 登录账号、最终可见 From、Reply-To、显式 Send As 权限和 DATA END 结果拆开；浏览器本地 144 状态规划器覆盖签名邀请与 OTP 两条重复路径，不收集邮箱、租户、SMTP 主机、凭据、Token、收件人、正文、完整会话、配置或日志。

验证邮件链接成功后打开原始 JSON：分离人类落地页与一次性 Token 操作

把邮件 href、安全的页面 GET、明确的 POST 验证、重复或过期链接恢复，以及 active 或 pending-domain 下一步拆开；浏览器本地 192 状态规划器不会收集邮箱、组织 ID、Token、完整链接、API 响应、Cookie、授权头、数据库行或日志。

Supabase 已验证邮箱重复注册显示确认邮件已发送：保留防枚举并修正文案

把 Auth 接受、已确认账号的脱敏 200 响应、确认请求、服务商接受、收件可见与最新链接完成拆开；浏览器本地 192 状态规划器会生成一致的中性结果与回归条件，不收集邮箱、密码、项目引用、API Key、响应体、用户 ID、确认链接、Token、Cookie、服务商载荷或日志。

Supabase signUp 的 emailRedirectTo 丢失 GitHub Pages 仓库路径：先证明 redirect_to 在哪里消失

把 auth-js 的实际请求 URL、跨域后只剩根路径的 Referer、Auth Redirect URL 白名单与 SiteURL 回退、确认邮件模板和最终验证跳转拆开；浏览器本地 108 状态规划器不会收集邮箱、项目引用、确认链接、Token、OTP、API Key、Cookie、授权头或完整网络抓包。

ZITADEL Login V2 注册跳过邮箱验证：先证明 Login 容器的执行开关

把 EMAIL_VERIFICATION 的运行时位置、用户创建后的 isVerified 状态、自动验证邮件触发和验证前应用会话拆开；浏览器本地规划器不会收集邮箱、验证码、链接、Token、Cookie、用户 ID、实例地址、凭据、环境变量转储或日志。

Django Post Office 3.11.2 出现 SMTP 421 too many connections：先计算并发连接预算

把每进程线程数、命令进程数、重叠调度和多副本本地锁相乘，再与服务商连接上限比较；浏览器本地计算器给出收敛方案和回归证明，不收集 SMTP 主机、地址、凭据、IP、队列内容、配置或日志。

Docker / IPv6 让确认邮件被 429 静默拦截：先修复共享限流桶

当代理或 IPv4-only bridge 把大量 IPv6 访客折叠成同一个网关地址时，低额度 per-IP limiter 会误伤整个现场；浏览器本地 256 状态规划器把可信代理、诚实的 Retry-After、持久化 Pending 与 outbox、服务商事件和最终确认分开，且不收集邮箱、IP、header、配置或日志。

Authentik staging 仍指向 Mailpit：上线真实 SMTP relay 前先证明四个边界

把实际 Helm 环境、Secret 经 lookup 与 reconcile 进入当前 worker、服务商发件身份和同一封邮件的 DMARC 结果、收件可见与链接完成分开；浏览器本地 256 状态规划器不会收集域名、邮箱、SMTP 凭据、Secret、配置、消息或日志。

Authentik ak test_email 只显示 ResultTimeout：去 worker 找真正 SMTP 错误

把命令等待、后台 send_mail 任务、SMTP backend、服务商结果和收件证据分开；浏览器本地 256 状态规划器不收集邮箱、域名、SMTP 主机、凭据、环境变量、消息、Traceback、Token、Header 或日志。

Stalwart 主机名已被 Amazon SES MAIL FROM 占用：先拆分 DNS 角色

当候选主机名已经发布 feedback-smtp.REGION.amazonses.com MX 和 SES SPF 时，它是现有退信域而不是通用 SMTP 主机；浏览器本地 144 状态规划器会分开收件 MX、A/AAAA 与 PTR、Return-Path、DKIM 和 DMARC，不收集域名、IP、记录值、密钥、配置或日志。

Resend DKIM 公钥是空的 p=，同时 DMARC 已是 p=reject：先恢复发信认证

空的 DKIM p= 表示 selector 已撤销，不是等待生效；浏览器本地 144 状态规划器会分开发信能力、精确 DKIM selector、默认或自定义 Return-Path 的 SPF/MX，以及新邮件的严格 DMARC 对齐，且不收集密钥、邮件、地址、配置或日志。

DKIM 记录已发布，但 Authentication-Results 仍是 dkim=none：先证明签名边界

把 selector 公钥、邮件中的 DKIM-Signature、收件方验证结果和 Postfix 提交路径分开；浏览器本地 144 状态规划器会检查 smtpd_milters、non_smtpd_milters 与 OpenDKIM InternalHosts，且不收集域名、密钥、邮件头、配置或日志。

Roundcube 多域配置出现 AUTHENTICATE PLAIN failed：先核对 IMAP 登录身份

区分 Webmail 请求主机、host-specific 配置、username_domain 追加或强制替换、提交的登录名形态与后续 IMAP 重连；浏览器本地 144 状态规划器不会收集域名、账号、密码、配置、会话或日志。

Termux 上 Mutt 提示 No authenticators available：检查 libcrypt 依赖

区分 SASL 插件文件存在与真正可加载，覆盖当前官方 libsasl 包中 PLAIN/LOGIN 对 libcrypt 的运行时边界、TLS 后 AUTH 列表、smtp_authenticators 策略和后续凭据拒绝；浏览器本地 1024 状态规划器不会收集账号、密码、配置或完整日志。

Django 密码重置只对已注册邮箱返回 500：不要用未知邮箱证明发信正常

未知邮箱不会进入令牌、模板和发信循环；用第二个受控已注册账号区分共享故障与账号特定故障，再按私有异常、SMTP 交接、服务商事件和收件结果逐层定位。

Keycloak 验证邮件链接在重启后返回 500：检查原始 authentication session

当邮件已收到、链接只在服务重启后由无痕窗口打开时失败，先区分签名 action token 与原始 root authentication session；用浏览器本地规划器生成 null-session 修复和四象限回归计划。

注册返回 500 但账号已创建：分离账号提交与可选验证

当账号和密码已经提交，后续 Redis 验证令牌或发信失败不能再伪装成注册失败；用浏览器本地规划器按 Required、Optional 与 None 策略生成诚实响应和恢复路径。

Spring Boot 注册声称验证邮件已发送，但 @Async 尚未发信：建立诚实发布门禁

把哈希验证码、事务提交、持久化 outbox、异步 worker、SMTP 接受、收件箱可见与单次验证拆开；浏览器本地规划器会给出当前证据允许的最强 API 文案和下一项测试。

Docker Compose 的 .env 有 SMTP，但密码重置邮件未发送：先证明变量与认证状态

区分 Compose 插值输入、app 服务导出、无认证/仅用户名/用户名加密码、运行容器状态、一次受控发信、服务商事件和重置链接使用；用浏览器本地 180 状态规划器生成下一步。

Rails Devise 密码重置邮件未到 Gmail：不要先盯 Sidekiq

先私下核对 User 地址和占位邮箱，再按 Devise 同步 deliver_now、Rails 交付结果、服务商事件、Gmail 接受、收件箱可见和最新链接使用逐层验证；浏览器本地 225 状态规划器不会收集邮箱或令牌。

SMTP 故障后密码到期邮件没有重发：持久化当前意图而非旧邮件

把调度器日志、内存队列、SMTP 接受和最终投递拆开；用当前密码到期代际去重、重发前复核账号状态、废弃过时任务，并用浏览器本地 36 状态规划器生成安全恢复动作。

Ticket requester 收到创建邮件但收不到解决通知：先证明逐收件人选择

当请求人收到工单创建回执、观察者收到解决通知而请求人没有时，先比较解决消息作者与请求人的不可变用户 ID，再把收件人选择、队列、服务商接受和收件箱可见性分开验证。

GLPI 技术员通知没有队列记录：区分工单负责人和关联资产负责人

GLPI 11 的 ASSIGN_TECH（目标 2）从工单 actor 表选择分派技术员，ITEM_TECH_IN_CHARGE（目标 5）读取关联资产的 users_id_tech；先核对持久化目标 ID，再调试队列或 SMTP。

证书已续期但 SMTP 通知失败：保持续期成功并隔离通知错误

把 ACME 结果、Kubernetes TLS Secret 提交、通知尝试和后台服务失败预算拆开；清除重复通知所有者，避免 SMTP 错误触发重复续期或改写证书结果。

Contact form 已保存但管理员通知邮件缺失：分离持久化收件与通知

区分表单持久化、管理员通知、提交者确认、邮件传输接受与最终投递；管理员提醒不能依赖访客是否填写邮箱或创建联系人，并用浏览器本地规划器定位下一步。

Contact form 显示已发送但没有请求：先建立持久化接收凭证

区分前端动画、真实 HTTP 请求、服务端持久化、通知队列、邮件 API 接受、收件服务器接受与收件箱可见性，并用浏览器本地规划器找到第一个未证实边界。

报价 PDF 邮件返回 provider configuration error：先定位附件、消息或服务商边界

把报价快照、PDF 生成、收件人与发件人校验、MIME 编码后大小、服务商交接、收件服务器接受和收件箱可见性拆开；浏览器本地规划器不会收集报价、地址或凭据。

Stellar Horizon 超时与收据邮件重试：先确认链上付款，再恢复邮件

把链上交易确认、Horizon 临时错误、业务履约、收据队列、邮件 API 接受、收件服务器接受和收件箱可见性拆成独立状态，并用浏览器本地规划器判断下一步。

Symfony Mailer 使用 mailer.transports 但邮件未到：先核验 DSN、Messenger 与投递证据

Symfony 7.4.14 的复数 transport 服务是有意设计；不要先改容器别名，而应逐层核对生产有效配置、同步或异步路径、服务商接收、收件服务器响应与收件箱可见性。

Nodemailer 535 Authentication failed：Payload / Next.js 构建期 SMTP 验证失败

把 EAUTH、535 与 AUTH PLAIN 定位为 SMTP 认证拒绝，区分 Payload 配置导入时的 build-time verify、Mailgun 凭据与区域、端口 TLS、CI 密钥传递、运行时 readiness 和真实邮件投递。

Cloudflare Email Routing vs Email Sending：入站、受限通知与用户邮件选型

区分入站转发、仅向已验证目的地址发送的受限 Workers binding，以及 Workers Paid 上面向任意用户的 Email Sending；分别处理 DNS、计划限制、投递事件和失败恢复。

Cloudflare Email Service + Proofpoint 554：共享发送 IP 被拒

核对 Cloudflare 实际使用的 cf-bounce SPF、DKIM、MX 与 DMARC，保存 554 中的出口 IP，并把共享 IP reputation、服务商升级、目标收件方测试和 magic-link 恢复分开处理。

验证码已到但账号不存在：定位待验证账号

先追踪注册与验证码核验是否使用同一个 pending account、API origin、环境、租户和数据库，再处理 Nodemailer/Ethereal 测试传输、durable outbox、服务商 message ID 与收件证据。

Auth0 verification email not received：任务、服务商与收件方分层

区分注册或重发请求、Management API 任务、只生成链接的 verification ticket、租户日志、内置或外部邮件服务商、收件方证据和链接或 OTP 使用结果。

Firebase Auth verification email not received：SDK、邮件发送与 Action Code 分层

区分 Client SDK 发信请求、Admin SDK 只生成链接、项目与用户状态、邮件额度、默认或自定义发送、收件方证据和 action-code 使用结果。

AWS Cognito verification email not received：验证码与密码重置邮件分层

从 API 请求、用户与恢复属性、Cognito 发信模式、Amazon SES 沙箱和事件，到收件服务器与收件箱可见性，定位首个没有证据的边界。

Supabase Auth email not received：确认邮件与 magic link 故障分层

从 Auth 请求、内置或自定义 SMTP、服务商事件、收件方可见性到 otp_expired 与安全扫描器预取，定位第一个未证实边界，不输入令牌或项目密钥。

Supabase + Brevo SMTP account not activated：账户激活边界

当 Supabase Auth 返回 500、Brevo relay 明确提示 SMTP 账户尚未激活时，先处理服务商账户状态，再验证 SMTP login、SMTP key、发件身份和一次真实 Auth 流程。

Resend delivered but not received：服务商已投递但收件箱不可见

把 queued、sent、suppressed、failed、delivery_delayed、bounced 与 delivered 映射到应用、Resend、SMTP 或收件方的第一责任动作，避免把收件服务器接受误写成进入收件箱。

SMTP 250 accepted but email later bounced：逐收件人投递状态

区分同步 relay acceptance、逐收件人提交失败、异步 DSN 或服务商事件和收件箱证据，并用稳定 ID、安全解析与幂等状态转换处理后续退信。

First email arrived, later emails are missing：首封成功、后续业务邮件消失

先比较首版、后续版本、招标、提醒或附件邮件的真实代码路径，证明客户发信触发、队列、服务商请求和接收方证据，再判断是否属于投递问题。

Web3 verification email not arriving：验证码与登录邮件故障分层

按应用生成、服务商事件、抑制、SMTP 投递和收件箱证据排查钱包登录、2FA、密码重置与交易通知，不用无证据地重复发送。

Crypto wallet verification email not received in Outlook：按收件方分层

当 Gmail 对照邮箱收到、Outlook、Hotmail 或 Live 收不到钱包登录或 OTP 邮件时，分别保留应用、服务商、SMTP、Microsoft 接收端和安全恢复证据。

Outlook 550 5.7.1 S3150：发送 IP 被 Microsoft 拒收

从完整 NDR 提取实际出口 IP，区分共享服务商与专用 IP 的责任边界，并处理上游先接受、Microsoft 随后异步退信导致的 failover 盲点。

Verification email incident triage：生成本地事故响应计划

选择应用、服务商、SMTP、收件方、影响范围、时间和认证状态，立即得到首个未证实边界、证据包、责任动作与安全重试立场，不输入邮箱、验证码或消息内容。

Web3 DMARC enforcement checklist：从 p=none 到执行策略

逐条盘点钱包提醒、登录邮件、交易回执、治理、客服和 newsletter，使用接收方证据验证对齐，并在 quarantine 或 reject 前准备回滚。

Separate sending domain launch checklist：独立发信域上线

为新的 outreach、newsletter 或产品通知域名分离发信身份，先确认每个服务商实际拥有的 MX、SPF、DKIM 与 Return-Path 边界，再按 warmup、进箱证据、退信、投诉和回滚建立上线证据。

Web3 email security：交易通知、钱包提醒与治理邮件认证

面向 Web3 团队，按消息路径核对 SPF、DKIM、DMARC、PTR 与传输安全，并直接进入英语免费扫描器。

Crypto phishing email check：先分析钱包与交易通知邮件头

在点击链接、连接钱包或签名之前，本地核对可见 From、SPF、DKIM、DMARC、ARC 与 Received 路由，并明确区分认证通过和内容安全。

Email sender inventory：先梳理全部 Web3 发信系统

在浏览器本地登记交易通知、钱包提醒、治理、客服和 newsletter 的 From 域、服务商、负责人、DKIM、Return-Path 与邮件头证据，再评估 DMARC 执行。

SMTP error decoder：粘贴退信并定位状态码

退信只在浏览器本地解析；区分临时与永久错误、Gmail 专用规则和通用 RFC 类别，再进入对应实时检查或修复指南。

Reverse DNS checker：检查发送 IP 的 PTR 与回指

只输入退信中的实际公网 IPv4 或 IPv6，实时检查 PTR 是否存在，以及对应 A/AAAA 是否解析回原发送 IP。

Email authentication header analyzer：分析 SPF、DKIM 与 DMARC 对齐

Gmail Show original 或其他完整邮件头只在浏览器本地解析；区分接收方的 Authentication-Results、ARC 断言、可见 From、Return-Path、MAIL FROM 和 DKIM 签名域。

SPF lookup counter：实时展开 include 与 redirect 查询预算

输入域名后查询公开 DNS，显示唯一 SPF 记录状态、已观察到的 DNS 查询次数、10 次上限和未完整展开的链路。

DKIM selector checker：精确查询 public key 状态

输入真实签名中的 d= 域和 s= selector，实时检查 key 类型、发布或撤销状态、测试标志、email 服务范围与 SHA-256 支持。

DMARC policy checker：查找真正适用的策略

输入可见 From 域，按当前 RFC 9989 执行最多 8 次 DNS Tree Walk，区分直接记录、父域继承、p/sp/np、对齐模式与冲突记录。

MTA-STS policy checker：验证 DNS 与 HTTPS policy 发布

实时检查 STSv1 公告、固定 HTTPS policy 路径、mode、max_age、MX pattern 数量与 TLS-RPT 状态，不公开原始记录或报告地址。

DMARC record generator：生成当前 RFC 9989 记录

在浏览器本地组合 p、sp、np、对齐、报告与 t=y；明确排除已成为历史项的 pct、rf 和 ri，再用实时检查验证发布结果。

DMARC report analyzer：本地读取 RFC 9990 聚合报告

直接读取 XML 或 XML.GZ，按邮件数加权汇总发送源、SPF/DKIM 对齐、处置和失败；报告文件不离开浏览器。

SPF 为什么有 10 次 DNS 查询限制

区分会消耗查询预算的机制，识别嵌套 include 和 redirect，避免发布后产生 PermError。

DMARC p=none 应该何时升级

理解监控、隔离和拒绝策略之间的差异，先确认合法发件源对齐，再逐步提高执行强度。

如何找到并验证 DKIM selector

DKIM 不在固定 DNS 主机名。学习从服务商后台或真实邮件头取得 selector，避免靠常见名称猜测。

MTA-STS 与 TLS-RPT 的完整组成

同时检查 DNS 公告、HTTPS policy、MX 模式和报告地址，并区分目标配置错误与扫描节点网络故障。

Gmail 与 Yahoo 批量发件要求

核对 SPF、DKIM、DMARC 对齐、PTR、TLS、投诉率和一键退订，并区分 DNS 可验证项与真实邮件验证项。

Outlook 高量发件要求与 5.7.515

理解每日超过 5,000 封邮件时的认证要求、适用的消费者邮箱范围和永久拒信后的修复顺序。

Gmail 451 / 421 4.7.23 PTR temporary rate limit

English guide with a live IPv4/IPv6 PTR and forward-DNS check for Gmail's temporary reverse-DNS rate limit.

Gmail 451 4.7.24 / 550 5.7.24 suspicious SPF entries

English guide with a live SPF structure check for duplicate records, broken include or redirect chains, broad policies, ptr, and DNS lookup limits.

阿里云 ECS / EIP 公网 IPv4 配置 PTR 反向解析

确认同账号 ECS 静态公网 IPv4 与 EIP 的支持范围，在 Reverse DNS Lookup 创建 PTR，并验证邮件主机名的 A 记录正向返回原发送 IP。

Gmail 550 5.7.25 PTR record 缺失或不匹配

从完整退信取得发送 IP，核对 PTR 反向结果与 A/AAAA 正向记录是否互相匹配，并找到真正的配置责任方。

Gmail 550 5.7.26 未通过身份认证

先按完整退信区分 SPF hard fail、SPF/DKIM 都未通过和 DMARC policy 拒绝，再修复对应身份。

Gmail 550 5.7.27 SPF authentication failed

使用退信中的 MAIL FROM 域和发送 IP 核对授权路径、唯一 SPF 记录与递归 DNS 查询预算。

Gmail 550 5.7.29 TLS required

定位连接 Gmail 的实际出站 SMTP 跳点，检查 STARTTLS 协商、明文回退、旧网关和服务商投递日志。

Gmail 550 5.7.30 DKIM authentication failed

从真实邮件签名取得 d= 与 s=，核对 selector 公钥、密钥轮换和签名后消息改写。

Gmail 4.7.32 / 5.7.32 DMARC alignment failed

比较可见 From、SPF MAIL FROM 与 DKIM d= 域，判断哪条已通过的认证身份没有与 Author Domain 对齐。

Gmail 550 5.7.40 DMARC record or policy missing

识别可见 From 的 Author Domain，并按 RFC 9989 检查直接记录、父域策略和适用 policy 标签。

No DMARC record found：未找到 DMARC 记录

区分当前主机名直接记录缺失与父域 policy discovery，并按 RFC 9989 使用 p、t 和聚合报告。