工作流程：确保电邮系统与 Zendesk 的兼容性

使用此指南确保您的电邮系统已针对与 Zendesk 无缝整合进行优化。通过遵循本文所述的最佳实践，您可以提高电邮服务器的信任级别，并将 Zendesk 使用过程中出现任何问题的风险降至最低。

本文章包括以下设置建议和最佳实践：

确保您用于发送电邮到 Support 的所有 IP 地址都有指针 (PTR) 记录。PTR 记录可进一步确保给定 IP 地址与域名所有者存在关联。例如，如果有人从 domain.com 发送电邮到 Support，IP 地址 1.2.3.4 应解析为 mail.domain.com。

理想情况下，PTR 记录应属于发送电邮到 Support 的相同域名。且不得包含表明 IP 地址属于居民互联网服务提供商的 IP 地址数字或关键字。

domain.com 的正确记录示例：

缺失记录的示例：

不应用于发送电邮的记录示例：

host 1.2.3.4
Host 4.3.2.1.in-addr.arpa. domain name pointer 4-3-2-1-cable-subscribers.isp.com

THELO 名称是 SMTP 服务器用来互相问候的。根据 RFC 5321 (第 2.3.5) 条，HELO 记录可进行解析，应属于电邮发件人的域名，并与 MX 记录匹配。Support 希望发送电邮到 Support 的 SMTP 服务器具有可解析的 THELO 主机名。

domain.com 的正确记录示例：

被视为低信任度的HELO问候语示例：

向 Support 发送电邮的域名应具有有效的 SPF 记录，该记录可授权 IP 地址代表该域名发送电邮。

以下情况的正确 SPF 记录有两个示例：

这两个示例都会启用 1.2.3.4 代表 domain.com 发送电邮。

要减少您收到的欺骗电邮和垃圾邮件数量，请启用符合 SPF、DKIM 和 DMARC 的发件人身份验证，为您的入站电邮添加额外的安全保护。有关更多信息，请参阅文章：对新到的电邮进行身份验证(SPF、DKIM、DMARC)。

不建议（目前也不支持）使用网络表格或自动脚本向 Support 发送电邮。要发送这些类型的电邮，客户必须遵守以下规则。

所有发送网络表格应要求身份验证或使用 CAPTCHA，或两者兼有。Zendesk 无法阻止您允许并鼓励的垃圾信息攻击。
当您使用网络表格、Web 应用程序或自行程序脚本发送电邮给 Support 时，电邮应符合 RFC 5322的正确格式。
消息应包含格式正确的标题：“ 主题：”、“ 发件人：”、“收件人：”和 “回复到：”。
发送 IP 地址应有 PTR 记录（反向 DNS 解析）。
Support 建议您添加有效的 SPF 记录，使用在发送域名的 DNS 区域上发布的 DKIM 密钥对这些电邮进行签名，并发布 DMARC 政策以指定电邮的处理方式。
THELO 问候语应有一个有效的可解析 DNS 名称。
通过外部客服电邮地址转发来自网络表格的任何电邮，以保留数据冗余并降低被阻止的可能性。
如果您要发送到原生 Zendesk 客服电邮地址（support@子域名.zendesk.com）那么您的表格应能够处理暂时性网络错误，或者 4xx 回复，以提高抵御能力。
请勿将 MX 转发硬编码到我们的任何 MX 记录。每个中继都应执行 MX 查找。
请勿将 标为垃圾 信息功能用于从您的网络表格提交中。这将对您的表格发送声誉产生负面影响。
Zendesk 客户支持不为您的网络表格的功能提供支持。

Zendesk 不信任：

发送者没有在域名所有者的 DNS 区域中发布授权 SPF 记录的欺骗电邮
带有欺骗性发件人地址、无效 DKIM 签名或未通过 SPF 检查的电邮
注意：如果您将电邮从您的域名转发到 Zendesk Support 子域名，例如 support@yourdomain.com >> support@subdomain.zendesk.com，Zendesk 会尝试检测转发的电邮。如果 Zendesk 检测到电邮转发，Zendesk 会采用其他方法对发送 SMTP 服务器进行身份验证。但是，请配置转发 SMTP 服务器以保留 DKIM 签名，不要篡改原始电邮正文和敏感标头。
在电邮的发件人和收件人标头中使用无效、不存在或不可解析域名的电邮

Support 对通过 SMTP 服务器发送且 PTR 记录缺失或 THELO 问候语无效的电邮行使低信任级别。

翻译免责声明：本文章使用自动翻译软件翻译，以便您了解基本内容。我们已采取合理措施提供准确翻译，但不保证翻译准确性

如对翻译准确性有任何疑问，请以文章的英语版本为准。