<spf> declare your smtp servers

SPF 详解

SPF 是“发件人策略框架”（Sender Policy Framework）的缩写，这是一种电子邮件认证标准，
它允许您声明哪些 SMTP 服务器被授权代表您的域名发送电子邮件。

它允许您确认发件人的地址及其与发送该邮件的服务器之间的关联。
如果邮件是使用您的发件人域名发送的，收件人可以确认该邮件是否来自您认可的某台 SMTP 服务器。

建议进行配置，因为如果完全未设置 SPF，部分收件人可能会拒收您的邮件。

如何让防晒霜发挥作用

有两种不同的方法：

• 一个“软”检查（~all 标签），如果消息是由未声明的服务器发送的，则会触发“软失败”错误
• 一个“严格”的规则（-all 标签），如果消息是由未声明的服务器发送的，则会触发“失败”错误

“软”配置会减少或完全避免收件人拒收邮件的情况。
“硬”配置则会导致部分邮件被拒收，例如当服务器未被声明时，或者在某些情况下邮件被重定向或通过邮件列表发送时。

“严格”配置为目标邮件服务器提供了更大的自主权来决定是否接受该邮件，这是我们建议的做法。

如何配置 SPF

配置 SPF 需要准确了解您用于发送电子邮件的具体服务器。

使用 RealSender 时，您的域名（example.com）的 TXT 记录应包含字符串
a:example.realsender.com 并呈现如下形式：

example.com   TXT   "v=spf1 a:example.realsender.com ~all" 

使用 HighSender 时，您的域名（example.com）的 TXT 记录应包含字符串
include:spf.realsender.com 并呈现如下形式：

example.com   TXT   "v=spf1 include:spf.realsender.com ~all" 

以下工具可帮助您验证配置：
www.kitterman.com/spf/validate.html *
检索指定域名的 SPF 记录，并判断该记录是否有效
在线 SPF 检查
通过发送电子邮件来验证您的电子邮件 SPF 设置

* = 外部网站链接，将在新页面中打开

SPF的缺点

即使所有设置都正确，如果邮件已被重定向（转发）或通过邮件列表发送，消息验证仍可能失败
。

In these cases, to keep the email authentication consistent,
configure the dkim signature domain to be aligned with the sender’s From address.
See: email authentication advanced » <dkim> alignment for dmarc.

<spf> check online

1. 发送电子邮件至：

spf@tester.realsender.com

2. 在线查看 SPF 验证结果：
   （页面加载需一分钟）

https://tester.realsender.com/spf

如果邮件未通过正确认证，RealSender 在线 SPF 检查会添加一个主题前缀：

!! spf-fail !!       该 SMTP 服务器未列入授权服务器列表
                      因此应拒绝或丢弃该邮件
!! spf-softfail !!   该 SMTP 服务器未列入授权服务器列表
                      但此情况应视为“软失败”  
!! spf-neutral !!    SPF 记录明确指出无法判断其有效性  
!! spf-none !!       发件人域名中不包含用于验证该邮件的信息  

有时在域级别记录的信息不正确或难以理解。

!! spf-permerror !!  发生永久性错误（例如：SPF 记录格式错误）  
!! spf-temperror !!  发生临时性错误

SPF 验证是针对隐藏在邮件头中的“Mail-From”邮箱地址进行的。
只有“From”邮箱地址是可见的。如果它们的根域名不同，则会显示以下警告：

!! spf-diff !!       “Mail-From” 和 “From” 的根域名不同

如果该邮件同时通过了 SPF验证和DMARC 的 SPF 对齐验证（宽松对齐），您将收到：

|OK| spf-pass        您的电子邮件通过了 SPF 验证和 SPF 对齐验证

如果 SPF或DKIM 中仅有一项通过 DMARC 的对齐检查（宽松对齐），
该邮件仍被视为“OK”（可信），并在开头添加 ~（波浪号）符号：

|~OK| spf-pass       您的电子邮件通过了 SPF 验证（但未通过对齐验证）+ DKIM 对齐验证

<dkim> seal the email content

DKIM 详解

DKIM 是 DomainKeys Identified Mail 的缩写，这是一种电子邮件认证标准，
旨在确保电子邮件（包括附件）自添加“签名”以来未被篡改。

它通过在每封外发电子邮件中附加一个与域名关联的数字签名来实现这一点。

使用两把密钥：一把“公钥”和一把“私钥”：

1. 该“公钥”发布在签名域名的 TXT 记录中
2. “私有”密钥保存在 SMTP 服务器中，用于对电子邮件进行“签名”

在发送邮件时，SMTP 服务器会根据邮件内容和私钥生成一个“加密哈希签名”。

接收方系统可以通过将邮件头中的签名与邮件内容及发件人的“公钥”进行比对，来验证该签名。

如何让 DKIM 正常工作

DKIM签名对最终用户而言是不可见的，它们由电子邮件基础设施添加并验证。

RealSender 的 SMTP 服务器会使用 DKIM 签名对所有外发电子邮件进行签名。

如何配置 DKIM

RealSender 会自动使用其连接到 SMTP 服务器的自有域名（
）对所有外发邮件进行签名， 用户或管理员无需进行任何设置。

要获得“用于 DMARC 的 DKIM 域对齐”，
该邮件必须使用与发件人相同的域进行签名。

使用 RealSender 时，您需要在域名（example.com）的 DNS 设置中添加两条 CNAME 记录
， 具体如下：

key1._domainkey.example.com   CNAME   key1._domainkey.yourcompany.realsender.com
key2._domainkey.example.com   CNAME   key2._domainkey.yourcompany.realsender.com

此工具可帮助您验证配置：
toolbox.googleapps.com*

* = 外部网站链接，将在新页面中打开

DKIM 的缺点

经过 DKIM 签名的邮件无法被修改，但任何人都可以阅读。

如果签名消息无法通过验证，通常会被拒绝。
如果从发送方到接收方的传输过程中未发生任何更改，这种情况本不应发生。

我们遇到过极少数此类情况，均与行长度有关（行长度必须不超过 990 个字符）。
某些应用程序会将内容全部放在一行中发送，或在 HTML 中传输非常长的行。
在这种情况下，DKIM 签名会损坏，导致检查结果显示为“dkim=fail”。

<dkim> check online

1. 发送电子邮件至：

dkim@tester.realsender.com

2. 在线查看 DKIM 验证结果：
   （页面加载需一分钟）

https://tester.realsender.com/dkim

如果邮件未正确签名，RealSender DKIM 在线检查会添加一个主题前缀：

!! dkim-none !!      未找到任何 DKIM-Signature 标头（无论有效与否）  
!! dkim-fail !!      找到了有效的 DKIM-Signature 标头，但签名 
                      中包含的值与该邮件不符  

有时无法执行该检查：

!! dkim-invalid !!   签名本身或公钥记录存在问题。
                      即无法处理该签名
!! dkim-temperror !! 发现某些错误，这些错误通常是暂时的，
                      例如暂时无法检索公钥

当邮件使用不同的域名进行签名时，主题中将添加“diff”提示。
如果发件人通过了 SPF 验证且符合 DMARC 的 SPF 对齐要求，则不会显示此警告：

!! dkim-diff !!      该邮件未由发件人域名进行签名

如果该邮件同时通过了 DKIM验证和DMARC 的 DKIM 对齐验证（宽松对齐），您将看到：

|OK| dkim-pass        您的电子邮件通过了 DKIM 验证 + DKIM 对齐验证

如果仅有一个（DKIM或SPF）通过了 DMARC 的对齐检查（宽松对齐），
该邮件仍被视为“OK”（可信），并在开头添加 ~（波浪号）符号：

|~OK| dkim-pass       您的电子邮件通过了 DKIM 验证（未通过对齐验证）+ SPF 对齐验证

<spf> alignment for dmarc

DMARC 的 SPF 域名对齐

DMARC 是一项电子邮件认证标准，旨在防范伪造域名的邮件。
对于域对齐，它要求：

   当发件人使用 SPF 和/或 DKIM 对电子邮件进行身份验证时，  
   至少有一个域名必须与发件人域名一致

要在 SPF（发件人策略框架）中实现这一点，你需要处理两个域名：

• 发件人地址，即收件人可见的地址
• “Mail-From”地址（也称为“信封发件人”或“返回路径”），该地址是隐藏的

DMARC 支持两种 SPF 对齐方式：宽松对齐和严格对齐。
如果您未指定严格对齐，系统将默认采用宽松对齐。

宽松对齐

在宽松对齐模式下，只需“Mail-From”地址的根域名与“From”地址的根域名一致即可。
宽松对齐允许使用任何子域名，同时仍满足域名对齐要求。

示例：

• 如果您的“Mail-From”域为 mail.abc.com，而“From”域为 abc.com，则
  您的电子邮件将通过 SPF 对齐验证（根域“abc.com”匹配）

• 如果您的“Mail-From”域为 abc.mail.com，而“From”域为 abc.com，
  您的电子邮件将无法通过 SPF 对齐验证（根域“mail.com”和“abc.com”不匹配）

严格对齐

在严格对齐的情况下，Mail-From 地址的域名必须与 From 地址的域名完全一致。

示例：

• 如果您的 Mail-From 域为 mail.abc.com，且您的 From 域为 mail.abc.com，
  您的电子邮件将通过 SPF 一致性验证（“mail.abc.com” 这两个域匹配）

• 如果您的“Mail-From”域为 mail.abc.com，而“From”域为 abc.com，例如
  ， 您的电子邮件将无法通过 SPF 对齐验证（因为“mail.abc.com”和“abc.com”这两个域不匹配）

<dkim> alignment for dmarc

DMARC 的 DKIM 域对齐

DMARC 是一项电子邮件认证标准，旨在防范伪造域名的邮件。
关于域名一致性，它要求：

   当发件人使用 SPF 和/或 DKIM 对电子邮件进行身份验证时，  
   至少有一个域名必须与发件人域名一致

要在 DKIM（DomainKeys Identified Mail）中通过验证，
DKIM 签名域（DKIM-Signature: d=…）必须与发件人域（From）一致。

DMARC 支持两种 DKIM 对齐方式：宽松对齐和严格对齐。
如果您未指定严格对齐，系统将默认采用宽松对齐。

宽松对齐

在宽松对齐模式下，只需 DKIM 签名域的根域与发件人 From 域相匹配即可。
宽松对齐允许使用任何子域，同时仍满足域对齐要求。

示例：

• 如果您的 DKIM 签名域是 mail.abc.com，而发件人域是 abc.com，例如
  ， 您的电子邮件将通过 DKIM 一致性验证（根域“abc.com”匹配）

• 如果您的 DKIM 签名域是 abc.mail.com，而发件人域是 abc.com，例如
  ， 您的电子邮件将无法通过 DKIM 一致性验证（根域“mail.com”和“abc.com”不匹配）

严格对齐

在严格对齐的情况下，DKIM签名域必须与发件人地址的域名完全一致。

示例：

• 如果您的 DKIM 签名域是 mail.abc.com，且发件人域也是 mail.abc.com，
  您的电子邮件将通过 DKIM 一致性验证（“mail.abc.com” 这两个域匹配）

• 如果您的 DKIM 签名域是 mail.abc.com，而发件人域是 abc.com，例如
  ， 您的电子邮件将无法通过 DKIM 一致性验证（因为“mail.abc.com”和“abc.com”这两个域不匹配）

<dmarc> detects fake emails

dmarc 解释

DMARC 代表：基于域的消息认证、报告与符合性（Domain-based Message Authentication, Reporting and Conformance）。
这是一种电子邮件认证标准，旨在防范伪造域名的邮件。

发件人：

• 使用 SPF 和 DKIM 对他们的电子邮件进行验证
• 发布一份关于如何处理未经身份验证邮件的“DMARC 策略”

接球手：

• 根据发件人的“DMARC 策略”对未经身份验证的邮件采取相应措施
• 向发件人报告结果

对于某些邮箱服务商而言，这会对邮件送达率产生显著影响，详见：
2020年DMARC在Gmail和Office 365中的工作原理*
“Office 365通常会响应SPF和DKIM认证。
要确保邮件稳定送达收件箱，唯一的方法是将其与DMARC关联起来”

* = 外部网站链接，将在新页面中打开

如何让 DMARC 正常工作

DMARC 采用 SPF（发件人策略框架）和 DKIM（域密钥识别邮件）
来处理电子邮件认证测试失败的情况。

SPF 要求您声明用于发送电子邮件的服务器。
请查看如何配置 SPF以了解更多信息并正确设置。

RealSender 的 SMTP 服务器会使用 DKIM 签名对所有外发电子邮件进行签名。
如果您希望使用发件人的同一域名进行签名，则需要进行相关设置。
请查看如何配置 DKIM以了解更多信息。

RealSender 为您提供一个邮箱，用于收集收件方生成的 DMARC 报告。

如何配置 DMARC

1. 起初，您应将策略标签设置为“none”（p=none），
   这意味着邮箱提供商不会对伪造/钓鱼邮件采取任何措施。
   您应在您的域名（example.com）上添加一条 TXT 记录，内容应如下所示：
   

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc.example@rsbox.com"

2. 从第二天起，您将开始在线收到DMARC RUA 报告。
   
   您可能会发现，自己忘记对通过第三方部署的某次邮件营销活动进行认证。
   如果发生这种情况，只需对其进行认证，并确认下次邮件发送能通过 DMARC 测试即可。

3. 如果报告连续几周显示正常，请通知邮件服务提供商拒绝/拦截这些伪造/钓鱼邮件。
   
   您域名的 _dmarc TXT 记录应修改为如下形式：

"v=DMARC1; p=reject; rua=mailto:dmarc.example@rsbox.com"

DMARC 的缺点

如果贵组织已部署 DMARC，在引入任何新的电子邮件发送方式之前，请务必仔细查阅
。

Dmarc 对 SPF 和 DKIM 的测试制定了严格的政策
这可能会导致原本能够通过这些测试的邮件
被邮箱服务商拒收。

即使所有设置都正确，验证仍可能失败：

• SPF 验证，以确认该电子邮件是否已被重定向（转发）或通过邮件列表发送
• DKIM 验证：如果邮件内容被篡改，将导致 DKIM 签名失效

<dmarc> rua reports online

RealSender 会为您收集并分析 DMARC RUA(*) 报告。

* = rua 含义：
汇总数据的报告 URI。 

在 RealSender 中，“rua”是指提供给客户的电子邮件地址
， 那些收到声称来自您域名的邮件的域名
会将汇总报告发送至该地址。

报告于每天13:00（中欧时间）生成，包含过去七天的数据。

这是一份 DMARC 在线报告，示例页面：

统计数据

详细报告

RealSender 提供关于每个 SMTP 服务器及外发邮件活动的详细报告。

数据每五分钟自动更新一次。

如您需要，我们可以每周通过电子邮件发送一份摘要。

本页的更多信息：

• 摘要
• 月度历史
• 每月几号
• 星期几
• 营业时间
• 主持人
• 发件人邮箱
• SMTP 错误代码

摘要

返回顶部

月度历史

返回顶部

每月几号

返回顶部

星期几

返回顶部

营业时间

返回顶部

主持人

返回顶部

发件人电子邮件

返回顶部

SMTP 错误代码

注意：这些错误是由未经授权的尝试通过该服务器发送电子邮件所引起的

返回顶部

日志与交付

电子邮件数据

RealSender 允许您通过浏览器访问已处理的电子邮件数据：

• 状态页面显示今天发送的最近100封邮件，实时更新
• 显示当天所有已发送邮件的完整页面
• 显示过去七天内所有已发送邮件的完整页面
• 包含当天所有已发送邮件的完整日志（原始、未经处理），可用于检查连接情况
• 过去七天的完整日志（原始、未经处理）

显示的数据可以直接从浏览器保存到本地， 或按固定间隔（例如每天一次）自动记录，以保留历史数据。

本页的更多信息：

• 电子邮件日志示例
• 送达状态通知 (DSN)
• 配送成功通知

日志中包含的信息示例

5月31日 06:26:22 rs336 v4V4QL1K030027:from=sender@yourcompany.com
5月31日 06:26:25 rs336 v4V4QL1K030027:to=recipient@yourcustomer.com, dsn=2.0.0,stat=已发送（消息已接受并准备投递）

5月31日 08:58:04 rs336 v4V6w3jN001390:from=sender@yourcompany.com
5月31日 08:58:05 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=4.0.0, stat=Deferred: 421recipient@yourcustomer.com 服务不可用 - 过于繁忙
5月31日 09:02:03 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=4.0.0, stat=Deferred: 421recipient@yourcustomer.com 服务不可用 - 过于繁忙
5月31日 09:12:42 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=2.0.0,stat=Sent (消息已接受并准备投递)

5月31日 10:00:22 rs336 v4V80L9Z004176:from=sender@yourcompany.com
5月31日 10:00:24 rs336 v4V80L9Z004176:to=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1recipient@yourcustomer.com: 收件人地址被拒：灰名单机制生效，请稍后再试
5月31日 10:02:03 rs336 v4V80L9Z004176:to=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1recipient@yourcustomer.com: 收件人地址被拒：灰名单机制生效，请稍后再试
5月31日 10:12:04 rs336 v4V80L9Z004176:to=recipient@yourcustomer.com, dsn=2.0.0,stat=已发送（消息已接受并准备投递）

5月31日 16:17:14 rs336 v4VEHCk6017038:from=sender@yourcompany.com
5月31日 16:17:15 rs336 v4VEHCk6017038:to=recipient@yourcustomer.com, dsn=5.1.1,stat=用户未知
5月31日 16:17:15 rs336 v4VEHCk6017038: v4VEHFk5017041: DSN: 用户未知

5月25日 12:43:37 rs336 v4PAhZw1019212:from=sender@yourcompany.com
5月25日 12:43:38 rs336 v4PAhZw1019212:to=recipient@yourcustomer.com, dsn=5.0.0,stat=服务不可用
5月25日 12:43:38 rs336 v4PAhZw1019212: v4PAhcw0019217: DSN: 服务不可用

5月25日 09:17:41 rs336 v4P7Hc6P011481:from=sender@yourcompany.com
5月25日 09:17:42 rs336 v4P7Hc6P011481:to=recipient@yourcustomer.com, dsn=4.1.1, stat=Deferred: 452 4.1.1recipient@yourcustomer.com 4.2.2 邮箱已满
[…] 系统每隔十分钟重试一次投递* […]
5月25日 13:25:47 rs336 v4P7Hc6P011481:to=recipient@yourcustomer.com, dsn=4.1.1, stat=Deferred: 452 4.1.1recipient@yourcustomer.com 4.2.2 邮箱已满
5月25日 13:25:48 rs336 v4P7Hc6P011481: v4PBPko0020848: 发件人通知： 4小时内无法发送邮件*

* = 参见下一段末尾的注释

返回顶部

送达状态通知 (DSN)

退回的邮件（例如“用户不存在”）将退还至发件人的电子邮件地址，或退还至返回路径地址（如果已指定）。

如果消息发送出现延迟，30 分钟后*，您将收到如下提示：

主题：  
      警告：过去30分钟内无法发送消息  

正文：  
      **********************************************  
      **      此为纯警告信息      **  
      **  您无需重新发送消息  **  
      **********************************************  
      [...]  

系统将在四小时内自动重试*。如果您未收到进一步的通知，则说明消息已成功送达。您可以在日志中查看详细信息（参见上述示例）。

经过四小时*的多次重试仍未成功后，系统将向发件人的电子邮件地址或返回路径地址（如已指定）返回明确的错误信息，如下所示：

Subject:  
      Returned mail: see transcript for details  
Body:  
      The original message was received at ...  
      ----- The following addresses had permanent fatal errors -----  
      <recipient@yourcustomer.com>  
      ----- Transcript of session follows -----  
      Deferred: Connection timed out with yourcustomer.com.  
      Message could not be delivered for 4 hours  
      Message will be deleted from queue  
      [...]  

* = 发送批量邮件时：
已禁用延迟投递状态通知，
投递尝试之间的间隔已延长（从10分钟延长至30分钟），
队列中的最大保留时间已延长（从4小时延长至24小时）

返回顶部

配送成功通知

根据要求，我们也可以为已成功送达的邮件开启“送达通知”功能。这样一来，每封送达的邮件，发件人都会收到来自目标服务器的送达回执，如下所示。此选项对于需要为每封发送的邮件获取送达回执的用户非常有用。

Subject: 
      Return receipt
Body:
      The original message was received at ...
      ----- The following addresses had successful delivery notifications -----
      <recipient@yourcustomer.com>  (successfully delivered to mailbox)
      ----- Transcript of session follows -----
      <recipient@yourcustomer.com>... Successfully delivered
      [...]

在极少数情况下（少于1%的已发送邮件），发件人将无法收到回执。这种情况通常发生在收件人已在邮件服务器上启用了特殊的“隐私/不接收回执”选项时。一般不建议使用此设置，因为它也会阻止标准未送达通知的发送。

返回顶部

检查电子邮件

有时，为了弄清楚发生了什么，有必要查看已发送的电子邮件。

根据要求，RealSender 可启用将所有发出的电子邮件自动复制到专用邮箱的功能。

该邮箱经过配置，可在短时间内轻松接收大量邮件。
电子邮件将在7天后自动删除。

请注意：如果邮件是从个人邮箱（即使是公司邮箱）发送的，
您需要告知发件人，其发送的邮件可能会被阅读，以便进行技术检查。