电子邮件服务器

如何在 Plesk 中正确配置 SPF、DKIM 和 DMARC

在本指南中，我将逐步向您介绍如何 SPF DKIM 和 DMARC，从而可靠地验证您的电子邮件。您将收到有关 DNS 条目、Plesk 开关和测试方法的明确程序，通过这些程序，您可以提高邮件的可送达性并阻止滥用发件人。

中心点

SPF 决定哪些系统有权为您的域发送邮件。
DKIM 对发出的信息进行签名，防止信息被篡改。
DMARC 将 SPF/DKIM 与准则和报告联系起来。
Plesk 提供了快速入门向导和 DNS 模板。
监测 DMARC 报告可使您的政策在运行中更加明确。

在 Plesk 中检查先决条件

在进行任何设置之前，我都会检查在 Plesk 和 DNS 管理。在 Linux 上，我通常使用 Postfix，在 Windows 上使用 SmarterMail，因为这些服务提供 SPF、DKIM 和 DMARC 功能。我还会检查域名的 DNS 区域是在 Plesk DNS 中还是在外部提供商处，因为这样我就可以在 Plesk DNS 之外管理条目。 Plesk 必须添加。为了顺利运行，我会保持主机名、反向 DNS 和有效 TLS 证书的干净，因为交付服务器会检查这些点。一个干净的起点可以节省大量时间，并加强声誉.

在 Plesk 中设置 SPF - 具体步骤

开始时，我打开 "工具和设置"→"DNS 设置"，然后搜索以以下内容开头的 TXT 记录 v=spf1 开始。例如，如果它不见了，我就把它戴上： v=spf1 a mx include:yourmailprovider.de -all以便允许授权系统发送，并阻止所有其他系统发送。如果域使用 Microsoft 365、Google Workspace 或时事通讯服务等其他发件人，我会添加相应的包括-机制。保存后，我会在 48 小时内让更改在全局范围内生效，然后使用 SPF 检查器向选定邮箱发送测试邮件，测试记录。您可以在以下文档中找到机制交互的简明分类紧凑型指南其中解释了最重要的情况。

在 Plesk 中激活 DKIM - 具体步骤如下

对于 DKIM 我进入 "工具和设置"→"邮件服务器设置"，激活了外发邮件签名选项。然后打开域级别的 "网站和域"→"域"→"邮件"→"设置"，检查是否为每个域开启了签名功能。如果我从外部管理 DNS，我会从以下地址导出数据 Plesk 生成的 DKIM 公钥，并将其作为 TXT 记录输入 DNS 提供商（注意选择器名称）。最长 24-48 小时后，收件人应验证 DKIM 签名，我通过向 DKIM 检查邮箱发送测试邮件或标题检查来确认这一点。有效的签名可以加强 交付能力 值得注意。

定义 DMARC 政策并使用报告

现在我设定 DMARC 作为 TXT 记录在 _dmarc.yourdomain.tld 值为 v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s.标签 p, rua 和致电控制政策和报告，同时 adkim/aspf 定义严格对齐（strict）。在实际操作中，我通常从 p=none对报告进行 2 至 4 周的评估，然后起草 隔离 或 拒绝 上。报告会显示哪些系统代表您发送邮件，以及 SPF 或 DKIM 在哪些地方出现故障，从而可以直接进行更正。更详细的步骤序列说明了 DMARC 的实施具体实例。

DNS 传播、测试和最佳实践

每次 DNS 更改都需要时间，因此我计划全球范围内的 DNS 更改最长需要 48 小时。传播上。在这一阶段，我会向外部邮箱发送测试邮件，并检查邮件头中的身份验证结果。 spf=pass, dkim=pass 和 dmarc=pass.如果邮件收到 软失败 或中性我检查 SPF 机制、DKIM 选择器和信封-发件人（返回路径）是否与发件人一致。在使用重定向时，我会监控 DMARC 结果，因为 SPF 经常会在此中断；DKIM 通常会对此进行补偿。我避免 ~全部 永久性和生产性设置始终依靠 -所有.

DMARC 标记和值 - 结构紧凑的表格

我使用以下概述来 DMARC 我将在主域和子域之间保持数值一致，并以可追溯的方式记录更改。我保持主域和子域的数值一致，并以可追溯的方式记录更改。对于富有成效的域，我会设置严格的对齐方式，并始终激活汇总报告。取证报告 (致电我的计划符合数据保护规定。制定明确的指导方针可以稳定声誉的领域。

日	意思	可能的值	建议
p	主域政策	无、隔离、拒绝	从无到有，再到拒绝
sp	子域政策	无、隔离、拒绝	sp= 拒绝生产性设置
rua	汇总报告	mailto:adresse	使用自己的报告地址
致电	法医报告	mailto:adresse	仅在必要时启动
adkim	DKIM 对齐	r（宽松），s（严格）	adkim=s 用于明确分配
aspf	SPF 对齐	r（宽松），s（严格）	aspf=s 以减少误报
pct	申请百分比	0-100	使用 pct 逐步收紧

整合外部发送器：Microsoft 365、Google、时事通讯服务

如果域名使用了其他运送路径，我会添加 SPF 包含的微软 365、Google Workspace、Mailgun、SendGrid 或时事通讯工具的文档完全一致。对于每项服务，我都会检查是否有单独的 DKIM 密钥处于活动状态，以及发件人域名是否真的已签名。我避免重复或过多的包括-由于 SPF 的 DNS 查询次数仅限于十次，因此，我不会使用级联。如果查询预算不足，我会合并发件人或将单个数据流转移到有自己 DMARC 策略的子域。这就是我如何使 SPF 保持精简并确保签名来自

深入检查和服务器选择

对于收到的邮件，我在 Plesk 检查 SPF、DKIM 和 DMARC，以便服务器及早过滤垃圾邮件。在 Linux 系统中，这些检查默认是可用的，而在 Windows 系统中，它们是通过 SmarterMail 实现的。我确保邮件服务器正常更新，使签名例程和解析器保持最新。如果出现误报问题，我会调整评分阈值，但绝不会调整政策您自己的域名。这就是我如何保持高防护性并确保合法发件人送达的方法。

常见错误和快速解决方案

会面"SPF permerror"，通常是语法错误或超出了查找限制。如果 DKIM 失败，我会检查选择器、公钥记录以及 TXT 值是否以正确的倒逗号结束。如果 DMARC 失败 流产我首先检查对齐情况：发件人域名、返回路径和 DKIM-d= 必须完全匹配。如果 SPF 因重定向而中断，我就依靠 DKIM 并保持签名状态稳定。我使用这个序列来解决大多数快递问题，而无需长时间搜索。

Plesk 中的 DNS 模板和自动化

如果我管理多个域，我会设置 DNS 模板 并在 Plesk 中存储 SPF、DKIM 和 DMARC 的标准记录。新域会立即收到可靠的默认设置，我只需对其进行微调即可。我还使用模板和脚本实施计划中的变更，如在全域范围内实施更严格的 DMARC。对于 DKIM 密钥的轮换，我使用两个选择器，这样就可以逐步进行更改。这样就能在数十个域中保持一致的操作，并且 可维护.

评估 DMARC 报告并收紧政策

启用后，我每天分析汇总报告，并确定 资料来源未经授权就代表域名发送信息。在收紧政策之前，我会阻止意外的 IP 并清理过时的工具。从 p=none 在 隔离 以及后来的 拒绝 我与 pct 这样我就能以可控的方式衡量效果。如果失败报告中出现合法发件人，我会更正 SPF 包含的内容或激活自己的 DKIM 密钥。这种例行程序可加强声誉可见，减少欺骗。

正确理解对齐

这样 DMARC 我始终确保正确的校准。通过 SPF 是信封中来自（返回路径）的域或 HELO/EHLO 标识，必须与可见的来自域匹配（严格：相同，宽松：相同的组织域）。有 DKIM 我检查了 d=-签名的属性：必须指向同一域（严格）或同一组织域（宽松）。在实践中，我确保

所使用的反弹路径（返回路径）使用的域与发件人域相匹配，或故意外包给具有自己的 DMARC 策略的子域、
所有第三方提供商的 From 域征兆 (DKIM)，而不仅仅是他们自己的运输域、
DKIM 签名在转发过程中保持不变，以补偿 SPF 中断。

如果对齐缺失，尽管 SPF/DKIM 有效，DMARC 接收机仍会报告错误。 dmarc=fail.因此，我检查了电子邮件标题中的字段 认证结果, 返回路径 和 DKIM 参数。这使我能够快速识别 SPF 或 DKIM 是否提供了对齐功能，以及我需要在哪些方面进行改进。

密钥管理和 DNS 参数

坚固耐用 DKIM-我使用的是 2048 位密钥。在 Plesk 我可以设置每个域的密钥长度；我会及时调出较旧的 1024 位密钥。如有必要，我会将较长的 DKIM TXT 记录分割成几个倒逗号段，以便 DNS 服务器能正确发送。我还定义了有意义的 TTL-值：在推出阶段，我使用 300-900 秒的时间，而在生产阶段，我使用 1-4 小时的时间。这样我就能灵活应对变化，而不会使缓存超载。

该旋转我在使用两个选择器时都能做到这一点：

在 Plesk 中创建一个新的选择器，并在 DNS 中将公钥发布为 TXT。
将发件人更改为新的选择器并观察监控（显示标题） s=新的选择器).
转换所有流量后，删除 DNS 中的旧选择器，并在 Plesk 中停用它。

我尽可能使用第三方供应商、下放 DKIM 记录（例如，提供商选择器的 CNAME）。这样，我就可以保持对我的区域的控制，并在不冒运行中断风险的情况下轮换密钥。

特殊情况：转发、邮件列表和网关

在实际环境中，我经常看到重定向、邮件列表或安全网关重写电子邮件。我特别注意这里的影响：

转发SPF 经常出现故障，因为转发 IP 不在发件人域的 SPF 中。在此，我依靠 DKIM提供内容保护。如果签名保持不变，则 DMARC 通过 DKIM 对齐存在。
邮件列表许多列表会更改主题或页脚，从而破坏 DKIM 签名。在这种情况下，我会计划放松对齐，并检查列表是否使用 SRS/ARC 或自己的签名。如果可能，我会使用具有自己 DMARC 策略的子域来处理列表。
安全网关重新签署邮件或重写信封发件人的网关必须与发件人域正确对齐。我会记录它们的作用，并在 SPF（ip4/ip6）中或通过包含锚定它们，以便保持对齐。

与以下邮件见面 spf= 失败 通过转发，这不会自动成为关键，只要 dkim=pass 且 DKIM 对齐正确。我评估的是整个验证结果，而不是孤立的单个信号。

共享 IP、HELO/EHLO 和 rDNS

如果多个域名共用同一个外发 IP，我可以依靠干净的 rDNS 和一致的 HELO/EHLO 名称。反向指针指向一个 FQDN（例如 mail.hosting-example.tld)，其 A 记录指向同一个 IP。MTA 报告的正是这个名称。我确保 SMTP TLS 证书 与 HELO 名称（如果提供多个名称，则为 SNI）相匹配。对于每个发件人域名，我还会确保 SPF/DKIM/DMARC 完全正确对齐--只要验证有效，仅共享 IP 不会影响 DMARC。

对于专用发件人（如交易邮件与营销邮件），我喜欢通过子域将它们分开，也可选择使用它们自己的 IP。这有助于 声誉管理简化了 DMARC 报告的评估，最大限度地减少了相互干扰。

监测和推广实践

为确保顺利运行，我将连续 DMARC 分析 有明确的推广步骤：

基线时间：2-4 周 p=none收集所有汇总报告（RUA），找出错误源。
清理删除未经授权的发件人，清理 SPF 包括的内容，在所有合法系统上激活 DKIM。
穿衣与 pct 逐渐到 隔离后来 拒绝 以百分比来衡量效果。
警报定义阈值（新 IP、每个提供商的失败率、来自域的新 IP）并设置通知。
文件将选择器、TTL、关键运行时间、SPF 预算和责任置于版本控制之下。

我检查了 SPF 查询预算 (最多 10 个机制与 DNS 查询），并合并包括。关键机制，如 ptr 或 +全部 我一般不使用它们； IP4/IP6, a, mx 并有针对性地 包括 仍然是首选手段。这就是我保持设置稳定和可审计的方法。

快速检查每个域

每次安装结束后，我都会运行一个固定的检查通过：SPF 记录可用、查找预算低于 10、机制排序正确、 -所有 激活。DKIM 签名有效，选择器记录在案，密钥长度足够，计划轮换。DMARC 具有有效的 TXT 记录，严格对齐，报告邮箱可访问并存档。显示测试邮件 spf=pass, dkim=pass 和 dmarc=pass 在页眉中。我使用这种顺序来保持设置的可重复性，并 低误差.

快速成功的实用总结

每个项目开始时，我都会明确标准保持 SPF 的精简，为每个发件人激活 DKIM，并推出带有报告功能的 DMARC。随后进行两到四周的监控，以消除盲点并加强指导。我以可控的方式整合外部服务，记录其中的内容，并控制查询预算。我为多个域使用 DNS 模板，并计划轮换 DKIM 密钥，以保持签名的新鲜度。我将有用的实用想法和故障排除技巧总结在我的 Plesk 提示 2025 这样您就能保持强大的 交付能力 达到。