本页面向管理电子邮件系统的专业人士及其他电子邮件提供商提供关于 Email Service 的技术信息。
在此您可以找到有关 Email Service 的信息，以及最佳实践、规则、指南、故障排除工具，以及 Email Service 的配置详情。
联系我们的最佳方式是使用我们的社区论坛 ↗或我们的 Discord 服务器 ↗。
要举报电子邮件滥用，请通过 mailabuse@cloudflare.com 联系我们。
Email Service 支持 Authenticated Received Chain (ARC) ↗。ARC 允许中间电子邮件服务器（例如转发服务器）将原始身份验证结果的记录附加到邮件。即使由于转发导致 SPF 或 DKIM 在其他情况下会失败，目标服务器也可以验证转发邮件的真实性。包括 Google 在内的主要提供商也支持 ARC。
DKIM (DomainKeys Identified Mail) ↗ 通过公钥密码学确保电子邮件在发件人与收件人 SMTP 服务器之间传输时未被篡改。
通过此标准，发件人将其公钥发布到域名的 DNS 一次，然后在每封邮件离开服务器之前对邮件正文进行签名。收件服务器读取邮件，从域名的 DNS 获取域公钥，并验证签名以确保邮件在传输过程中未被篡改。
Email Service 代表客户的发送域为外发电子邮件添加 DKIM 签名，以确保电子邮件真实性并提高送达率。
Email Sending 和 Email Routing 使用不同的 DKIM selector。您可以通过查询以下内容找到域的 DKIM 密钥：
# Email Sending DKIM
dig TXT cf-bounce._domainkey.example.com +short
# Email Routing DKIM
dig TXT cf2024-1._domainkey.example.com +short对于转发的电子邮件，Email Routing 会添加两个 DKIM 签名：一个用于 email.cloudflare.net，涵盖发件人重写；另一个用于客户配置的收件人域。您可以直接查询 Cloudflare 发件人重写密钥：
dig TXT cf2024-1._domainkey.email.cloudflare.net +shortEmail Service 支持 Domain-based Message Authentication, Reporting & Conformance (DMARC)。发送电子邮件时，Email Service 确保正确的 SPF 和 DKIM 对齐，以通过 DMARC 身份验证。对于 Email Routing，如果传入电子邮件根据发件人的 DMARC 策略身份验证失败，将被拒绝。有关此协议的更多信息，请参阅 dmarc.org ↗。
建议所有域名实施 DMARC 协议，以实现最佳电子邮件送达率。
Cloudflare 要求传入电子邮件通过某种形式的身份验证。电子邮件必须通过 SPF 或以正确的 DKIM 签名。同时未通过这两项检查的电子邮件将被拒绝。
通过 Email Service 发送的外发电子邮件始终同时使用 SPF 和 DKIM 进行身份验证，以最大化送达率并维护发件人声誉。
Email Service 在入站和出站电子邮件投递中均支持 IPv6。对于出站，当收件人的 MX 服务器具有 AAAA 记录时，服务通过 IPv6 连接到收件人 SMTP 服务器，否则回退到 IPv4。对于入站，Email Routing 在其 MX 服务器上通过 IPv6 接受邮件。
您可以使用 dig 验证任何目标的 IPv6 连接性：
dig mx gmail.com
dig AAAA gmail-smtp-in.l.google.com将 Email Service 用于发送电子邮件时，您的域名上不需要特殊的 MX 记录。但是，如果您还使用 Email Routing 处理入站电子邮件，则会自动配置适当的 MX 记录。
对于 SPF 记录，Email Service 使用 _spf.mx.cloudflare.net。Email Sending 在 cf-bounce 子域上配置 SPF，而 Email Routing 在根域上配置 SPF：
v=spf1 include:_spf.mx.cloudflare.net ~all对于入站邮件，Email Routing 在 *.mx.cloudflare.net zone 下以不同优先级公告多个 MX 服务器。例如：
example.com. IN MX 13 amir.mx.cloudflare.net.
example.com. IN MX 86 linda.mx.cloudflare.net.
example.com. IN MX 24 isaac.mx.cloudflare.net.Email Service 在收件人 SMTP 服务器支持时使用 IPv4 和 IPv6 前缀发送流量。
如果您是 postmaster 并且在接收 Email Service 电子邮件时遇到问题，请在服务器配置中允许以下出站 IP 地址：
IPv4
104.30.0.0/19
IPv6
2405:8100:c000::/38
要验证当前权威范围，请直接查询 SPF 记录：
dig TXT _spf.mx.cloudflare.net +shortEmail Service 将为 HELO/EHLO 命令使用以下出站域：
cloudflare-email.netcloudflare-email.orgcloudflare-email.com
PTR 记录（反向 DNS）确保每个主机名都有对应的 IP。例如：
dig a-h.cloudflare-email.net +short104.30.0.7dig -x 104.30.0.7 +shorta-h.cloudflare-email.net.对于转发的电子邮件，Email Routing 使用 Sender Rewriting Scheme ↗ 将信封发件人（SMTP MAIL FROM 地址）重写为由 Cloudflare 控制的转发域。这种重写允许即使邮件正在中继，SPF 也能在目标服务器通过。邮件的 From: 标头不会被修改。
Email Service 提供详细的 SMTP 错误响应，以帮助诊断投递问题。对于 Email Routing，目标邮件服务器返回的上游 SMTP 错误会在会话中转发回发送服务器，而不是作为单独的退信消息。
Email Service 会监控发件人声誉，并可能临时延迟或拦截出现在实时封锁列表 (RBL) 上的 IP 发出的电子邮件。这有助于维护服务的整体声誉和送达率。
对于 Email Routing，来自 RBL 上发件人的入站邮件会被拒绝，并返回类似如下的 SMTP 错误：
554 <YOUR_IP_ADDRESS> found on one or more RBLs (abusixip). Refer to https://developers.cloudflare.com/email-service/reference/postmaster/#realtime-block-lists您可以使用 MxToolbox ↗ 等工具，一次性对照多个封锁列表检查发送 IP。如果您认为电子邮件被错误拦截，请直接联系 RBL 维护者，或通过 Cloudflare 支持渠道联系。
Email Service 在 _spf.mx.cloudflare.net 下发布其 SPF 数据。您可以直接解析底层记录：
dig TXT _spf.mx.cloudflare.net +short该记录使用 RFC 7208 ↗ 中定义的格式：
"v=spf1 ip4:104.30.0.0/20 ~all"~all 机制是 SoftFail。接收服务器应将记录中未列出的 IP 发出的邮件视为可疑，但不应仅因 SPF 就直接拒绝。
有关完整配置详情，请参阅：
以下是有关 Email Service 的已知限制信息，尤其是 Email Routing 功能。
Email Routing 不支持国际化电子邮件地址 ↗。Email Routing 仅支持国际化域名 ↗。
这意味着您可以使用带有国际化域名的电子邮件地址，但不能使用国际化的 local-part（电子邮件地址中 @ 符号之前的部分）。请参阅以下示例：
info@piñata.es- 支持piñata@piñata.es- 不支持
Email Routing 不会将非送达报告转发给原始发件人。这意味着发件人不会收到表明电子邮件未到达预期目的地的通知。
由于电子邮件转发的特性，严格的 DMARC 策略可能导致转发的电子邮件无法投递。有关更多信息，请参阅 dmarc.org ↗。
Email Routing 不支持从您的 Cloudflare 域名发送或回复。当您回复由 Email Routing 转发的电子邮件时，回复将从您的目标地址（例如 my-name@gmail.com）发送，而不是从投递该邮件的路由规则电子邮件模式（例如 info@yourdomain.com）发送。
在 Gmail 等电子邮件提供商中执行特殊操作的 . 字符，在路由规则电子邮件模式中被视为普通字符。