岗位

SPF 用户每天面临的一个非常普遍的问题是,产生过多的 DNS 查询,使他们很容易超过 SPF 的硬限制。当启用DMARC监控时,这会返回一个SPF PermError的结果,并导致电子邮件的交付问题。随着行业专家提出SPF扁平化服务等解决方案来缓解这一问题,PowerSPF实际上实现了它的主张,并超出了预期。请继续阅读,了解如何做到这一点!

太多的DNS查询。为什么会发生这种情况?

你应该明白的第一件事是,为什么你最终会产生太多的DNS查询。这是因为,无论你使用什么电子邮件交换解决方案,你的服务提供商都会在你的记录中添加更多的机制,从而导致更多的查询。

例如,如果你使用谷歌的电子邮件交换器,即Gmail,一个SPF记录如 v=spf1 include:[email protected] -all 的记录实际上会产生 4 次 DNS 查询。嵌套包括也会启动更多的查找,如果你使用几个第三方供应商使用你的域名发送电子邮件,你可以很容易地超过10个DNS查找的限制。

SPF平坦化是解决方案吗?不是!

答案是否定的。SPF 手动平坦化可以帮助你保持在SPF 10的查询限制之下,但是它有自己的一套限制和挑战。如果你手动平坦化你的 SPF,它只是将你的 SPF 记录中的 include 语句替换为其对应的 IP 地址,以消除查找的需要。这可以确保你不会首先产生过多的 DNS 查询,从而帮助你保持在 10 次查询的 SPF 限制之下,并避免 permerror 。但是,手动SPF扁平化解决方案的问题是。

  • SPF记录的长度可能太长(超过255个字符)。
  • 你的电子邮件服务提供商可以在不通知你的情况下改变或增加其IP地址
  • 没有仪表板来监控电子邮件流,改变或更新你的域名和机制,并跟踪活动。
  • 你需要不断地对你的DNS进行修改以更新你的SPF记录
  • 由于频繁的IP变更,你的电子邮件交付能力可能会受到影响。

这些对你有什么影响?好吧,如果你的SPF记录没有在你的电子邮件服务提供商使用的新IP地址上更新,那么每当这些IP地址被使用时,你的电子邮件将不可避免地在接收方的SPF上失效。

动态SPF扁平化以解决过多的DNS查询问题

一个更聪明的解决方案是PowerSPF,你的自动SPF记录平整器,可以告别DNS查询错误。PowerSPF 是你的实时 SPF 扁平化解决方案,它可以帮助你。

  • 只需点击几下,就可以为你的域名轻松配置SPF
  • 一键式即时平移SPF记录,只需一条包含语句即可享受自动的SPF包含管理
  • 始终保持在10个DNS查询限制之下
  • 自动更新网络屏蔽,不断扫描变化的IP地址,以保持你的SPF记录是最新的。
  • 保持一个用户友好的仪表板,在那里你可以很容易地更新你的政策的变化,添加域和机制,并监控电子邮件流。

为什么要依赖SPF压缩工具,而这些工具可以提供暂时的结果,并有潜在的限制?今天就用Automatic SPF来优化你的SPF记录,缓解SPF的硬性限制吧!现在就注册使用 PowerSPF?

避免SPF扁平化的原因

发件人政策框架,或者说SPF是一个广受赞誉的电子邮件认证协议,它通过对你的SPF记录中为你的域名注册的所有授权IP地址进行认证,来验证你的邮件。为了验证邮件,SPF规定接收邮件的服务器要进行DNS查询,以检查授权的IP,从而进行DNS查询。

你的 SPF 记录以 DNS TXT 记录的形式存在,它是由各种机制组合而成的。这些机制中的大多数(比如 include, a, mx, redirect, exists, ptr) 都会产生 DNS 查询。然而,SPF 认证的 DNS 查询的最大数量被限制在 10 个。如果你使用各种第三方供应商使用你的域名发送电子邮件,你可以很容易地超过 SPF 的硬限制。

你可能想知道,如果你超过这个限制会怎样?超过10个DNS查询的限制会导致SPF失败,甚至会使从你的域名发出的合法邮件无效。在这种情况下,如果你启用了 DMARC 监控,接收邮件的服务器会向你的域名返回SPF PermError报告。SPF扁平化。

什么是SPF平坦化?

SPF 记录平坦化是行业专家用来优化你的 SPF 记录并避免超过 SPF 硬性限制的流行方法之一。SPF 扁平化的程序非常简单。扁平化你的SPF记录的过程是将所有包含机制替换为各自的IP地址,以消除执行DNS查询的需要。

例如,如果你的SPF记录最初是这样的。

v=spf1 include:spf.domain.com -all

一个扁平化的SPF记录看起来会是这样的。

v=spf1 ip4:168.191.1.1 ip6:3a02:8c7:aaca:645::1 -all

这种扁平化的记录只产生一个DNS查询,而不是进行多次查询。减少接收服务器在电子邮件验证过程中执行的DNS查询次数确实有助于保持在10次DNS查询限制之下,然而,它也有自己的问题。

SPF扁平化的问题

除了你手动平铺的 SPF 记录可能会变得太长,无法在你的域名的 DNS 上发布(超过 255 个字符的限制)之外,你还必须考虑到你的电子邮件服务提供商可能会改变或增加他们的 IP 地址,而不通知你这个用户。每当你的供应商对他们的基础设施进行修改时,这些修改不会反映在你的 SPF 记录中。因此,每当你的邮件服务器使用这些改变了的或新的IP地址时,邮件就会在接收方的SPF中失效。

PowerSPF:你的动态SPF记录生成器

PowerDMARC的最终目标是提出一个解决方案,可以防止域名所有者遇到10个DNS查询的限制,以及优化你的SPF记录,使其始终保持在你的电子邮件服务提供商使用的最新IP地址上。PowerSPF是你的自动SPF扁平化解决方案,它通过你的SPF记录拉动,生成一个单一的包含声明。PowerSPF 可以帮助你。

  • 轻松添加或删除IP和机制
  • 自动更新网络封锁,确保你的授权IP总是最新的。
  • 轻松保持在10个DNS查询限制之下
  • 只需点击一下就能获得一个优化的SPF记录
  • 永久击败 "permerror"。
  • 实施无错误的SPF

今天就注册PowerDMARC,以确保增强电子邮件的可交付性和认证,同时保持在10个DNSSPF查询限制 之下

在这篇文章中,我们将探讨如何为你的域名轻松优化SPF记录。对于拥有电子邮件域名的企业和小型企业来说,他们在客户、合作伙伴和雇员之间发送和接收信息,很可能默认存在一条 SPF 记录,这是由你的收件箱服务提供商设置的。不管你是有一个预先存在的SPF记录,还是需要创建一个新的记录,你都需要为你的域名正确地优化你的SPF记录,以确保它不会造成电子邮件的交付问题。

一些电子邮件收件人严格要求SPF,这表明如果你的域名没有发布SPF记录,你的电子邮件可能会在收件人的收件箱中被标记为垃圾邮件。此外,SPF有助于检测未经授权的来源以你的域名名义发送电子邮件。

让我们首先了解什么是SPF,为什么需要它?

发件人政策框架(SPF

SPF本质上是一个标准的电子邮件认证协议,它规定了被授权从你的域名发送电子邮件的IP地址。它的运作方式是将发件人地址与特定域名的授权发送主机和IP地址列表进行比较,该列表公布在该域名的DNS中。

SPF与DMARC(基于域的信息验证、报告和一致性)一起,旨在检测电子邮件发送过程中伪造的发件人地址,并防止欺骗性攻击、网络钓鱼和电子邮件诈骗。

需要知道的是,尽管你的主机提供商将默认的 SPF 集成到你的域名中,确保从你的域名中发送的邮件能够通过 SPF 认证,如果你有多个第三方供应商从你的域名中发送邮件,那么这个预先存在的 SPF 记录需要被定制和修改,以适应你的要求。你怎样才能做到这一点呢?让我们来探讨两种最常见的方法。

  • 创建一个全新的SPF记录
  • 优化现有的SPF记录

关于如何优化SPF记录的说明

创建一个全新的SPF记录

创建 SPF 记录,只是在你的域名的 DNS 中发布一条 TXT 记录,为你的域名配置 SPF。这是一个强制性的步骤,在你开始了解如何优化SPF记录之前。如果你刚开始接触认证,对语法没有把握,你可以使用我们免费的在线SPF 记录生成器,为你的域名创建 SPF 记录。

一个具有正确语法的SPF记录条目将看起来像这样。

v=spf1 ip4:38.146.237 include:example.com -all

v=spf1指定正在使用的SPF的版本
ip4/ip6这一机制指定了被授权从你的域名发送电子邮件的有效IP地址。
包括这个机制告诉接收服务器包括指定域的 SPF 记录的值。
全部这个机制规定,不符合 SPF 标准的邮件将被拒绝。这是你在发布 SPF 记录时可以使用的推荐标签。不过,你可以用 ~ 代替 SPF Soft Fail (不符合规定的邮件将被标记为软失败,但仍会被接受),也可以用 + 代替,这说明任何和每一个服务器都可以代表你的域名发送邮件,但这是非常不可取的。

如果你已经为你的域名配置了SPF,你也可以使用我们免费的SPF记录检查器来查询和验证你的SPF记录并检测问题。

配置SPF时的常见挑战和错误

1) 10个DNS查询限制 

域名所有者在为他们的域名配置和采用 SPF 认证协议时,面临的最常见的挑战是 SPF 对 DNS 查询的次数有限制,不能超过 10 次。对于依赖多个第三方供应商的域名来说,10个DNS查询的限制很容易超过,这反过来又会破坏SPF,并返回一个SPF PermError。在这种情况下,接收服务器会自动使你的 SPF 记录无效,并将其屏蔽。

启动DNS查询的机制。MX, A, INCLUDE, REDIRECT修改器

2) SPF无效查询 

无效查询是指返回 NOERROR 响应或 NXDOMAIN 响应(无效回答)的 DNS 查询。在实施 SPF 的过程中,我们建议首先确保 DNS 查询不会返回无效答案。

3) SPF 递归循环

这个错误表明,你指定的域的 SPF 记录包含一个或多个 INCLUDE 机制的递归问题。这发生在INCLUDE标签中指定的一个域中,该域的SPF记录包含原域的INCLUDE标签。这导致了一个永无止境的循环,使电子邮件服务器不断地对SPF记录进行DNS查询。这最终会导致超过10次的DNS查询限制,从而导致电子邮件无法通过SPF。

4) 语法错误 

一个 SPF 记录可能存在于你的域名的 DNS 中,但是如果它包含语法错误,那就没有用了。如果你的 SPF TXT 记录在输入域名或机制名称时包含了不必要的空白,那么在执行查询时,接收服务器会完全忽略多余的空格前的字符串,从而使 SPF 记录无效。

5) 同一域名的多个SPF记录

一个域名在 DNS 中只能有一条 SPF TXT 记录。如果你的域名包含一个以上的SPF记录,接收服务器会使所有的记录失效,从而导致邮件无法通过SPF。

6) SPF记录的长度 

一个 SPF 记录在 DNS 中的最大长度被限制为 255 个字符。然而,这个限制可以被超越,SPF的TXT记录可以包含多个字符串串联在一起,但不能超过512个字符的限制,以适应DNS的查询响应(根据RFC 4408)。尽管后来对此进行了修订,但依赖旧的DNS版本的收件人将无法验证从含有冗长的SPF记录的域名中发送的电子邮件。

优化你的SPF记录

为了及时修改你的SPF记录,你可以使用以下SPF最佳实践。

  • 试着在你的SPF记录中按重要性从左到右依次打下你的电子邮件来源
  • 从你的DNS中删除过时的电子邮件来源
  • 使用IP4/IP6机制而不是A和MX
  • 尽可能减少INCLUDE机制的数量,并避免嵌套式包含。
  • 不要在你的DNS中为同一个域名发布一个以上的SPF记录。
  • 确保你的SPF记录不包含任何多余的空白或语法错误。

注意:SPF扁平化不被推荐,因为它不是一次性的。如果你的电子邮件服务提供商改变了他们的基础设施,你将不得不相应地改变你的SPF记录,每次都是如此。

用PowerSPF轻松优化你的SPF记录

你可以继续尝试实施上述所有的修改来手动优化你的 SPF 记录,或者你可以忘记这些麻烦,依靠我们的动态 PowerSPF 来自动完成这一切PowerSPF可以帮助你一键优化你的 SPF 记录,在这里你可以。

  • 轻松地添加或删除发送源
  • 轻松地更新记录,而不必手动修改你的DNS
  • 只需点击一个按钮,就能获得一个优化的自动SPF记录
  • 始终保持在10个DNS查询限制之下
  • 成功地缓解了PermError
  • 忘记SPF记录的语法错误和配置问题
  • 我们代表你解决SPF限制的问题,减轻你的负担

今天就注册 PowerDMARC,永远告别SPF值的限制!  

作为一个DMARC服务提供商,我们经常被问到这个问题。"如果DMARC只是使用SPF和DKIM认证,我们为什么要为DMARC费心?这不是没有必要吗?"

从表面上看,这似乎没有什么区别,但现实是非常不同的。DMARC不仅仅是SPF和DKIM技术的组合,它本身是一个全新的协议。它有几个特点,使它成为世界上最先进的电子邮件认证标准之一,并且是企业的绝对必需品。

但是,等一下。我们还没有准确回答你为什么需要DMARC。它提供了什么SPF和DKIM没有的东西?嗯,这是个相当长的答案;对于一篇博文来说,太长了。所以让我们把它分开,先谈谈SPF。如果你对它不熟悉,这里有一个简单的介绍。

什么是SPF?

SPF,即发件人政策框架,是一个电子邮件认证协议,可以保护电子邮件接收者免受欺骗性的电子邮件。它本质上是一个授权通过你(域名所有者)的渠道发送电子邮件的所有IP地址的列表。当接收服务器看到来自你的域名的邮件时,它会检查你的DNS上公布的SPF记录。如果发件人的IP在这个 "列表 "中,邮件就会被传送。如果不是,服务器会拒绝该邮件。

正如你所看到的,SPF做得很好,把很多不怀好意的电子邮件拒之门外,这些电子邮件可能会损害你的设备或破坏你组织的安全系统。但是,SPF并不像一些人可能认为的那样好。这是因为它有一些非常重要的缺点。让我们来谈谈这些问题中的一些。

SPF的局限性

SPF记录不适用于发件人地址

电子邮件有多个地址来识别它们的发件人:你通常看到的发件人地址,以及隐藏的返回路径地址,需要点击一到两次才能看到。在启用SPF的情况下,接收电子邮件的服务器会查看Return Path,并检查来自该地址的域名的SPF记录。

这里的问题是,攻击者可以利用这一点,在他们的返回路径地址中使用一个假域名,而在发件人部分使用一个合法(或看起来合法)的电子邮件地址。即使接收者要检查发件人的电子邮件ID,他们也会先看到发件人地址,而通常不会去检查返回路径。事实上,大多数人甚至不知道有返回路径地址这种东西。

通过使用这种简单的技巧,SPF可以很容易地被规避,而且它甚至使有SPF保护的域名在很大程度上受到伤害。

SPF记录有一个DNS查询限制

SPF记录包含一个由域名所有者授权发送电子邮件的所有IP地址的列表。然而,它们有一个关键的缺点。接收服务器需要检查该记录,看发件人是否被授权,为了减少服务器的负荷,SPF记录有10次DNS查询的限制。

这意味着,如果你的组织使用多个第三方供应商,通过你的域名发送电子邮件,那么 SPF 记录最终会超过这个限制。除非进行适当的优化(自己做起来并不容易),否则 SPF 记录会有一个非常有限的限制。当你超过这个限制时,SPF的实现就会被认为是无效的,你的邮件就无法通过SPF。这有可能损害你的邮件发送率。

 

当电子邮件被转发时,SPF并不总是起作用

SPF还有一个关键的故障点,会损害你的邮件送达能力。当你在你的域名上实施了SPF,而有人转发你的邮件时,转发的邮件会因为你的SPF政策而被拒绝。

这是因为转发的信息改变了电子邮件的收件人,但电子邮件发件人的地址却保持不变。这就成了一个问题,因为邮件包含了原发件人的From地址,但是接收服务器看到的是一个不同的IP。转发邮件服务器的IP地址并不包括在原发件人的域名的SPF记录中。这可能导致邮件被接收服务器拒绝。

DMARC是如何解决这些问题的?

DMARC使用SPF和DKIM的组合来验证电子邮件。一封电子邮件需要通过SPF或DKIM,才能通过DMARC并被成功传递。而且,它还增加了一个关键功能,使它比单独的SPF或DKIM有效得多。报告。

通过DMARC报告,你每天都能得到关于你的电子邮件渠道状态的反馈。这包括有关你的DMARC调整的信息,认证失败的电子邮件的数据,以及潜在的欺骗企图的细节。

如果你想知道如何做才能不被欺骗,请查看我们关于避免电子邮件欺骗的5大方法的便捷指南。