1

我的团队支持客户的网站，我们使用 SendGrid 代表他们发送与该网站相关的电子邮件。

我们与他们自己的电子邮件服务器没有任何关系，我目前对此一无所知。

据我所知，SendGrid 具有适当的身份验证，并且是其域的授权发件人，并且几乎 98% 的电子邮件都已成功发送。

但是，由于“550 中继被拒绝”的原因，我们遇到了一些退回邮件，所有这些都是针对我们客户域中的地址（与他们的网站和电子邮件的发件人地址相同的地址）。

大多数发送到其域的电子邮件都已成功发送。

不幸的是，我无法访问退回电子邮件的完整标题，只有原因。

我了解通常此错误可能是由以下原因引起的

  • 发件人未正确验证。我远不是这方面的专家，但据我所知，那里没有错。或者
  • 收件人电子邮件域的 DNS 或类似配置错误。我对此知之甚少，我对客户的电子邮件服务器没有访问权或责任。

我的主要问题是，与发件人地址相同的域有什么关系吗？由于电子邮件声称来自其发送到的同一个地方，这是否可能影响中继处理它的方式？

如果没有，我也很感激关于在哪里寻找问题的任何指示（或者如果问题可能来自他们的最终问题，建议客户查看什么。）我一直在尝试研究电子邮件配置问题和身份验证，但我在这方面非常新手。

提前致谢。

4

1 回答 1

1

相同的域很可能是相关的，但通常当这种情况发生时，接收服务器会拒绝所有声称来自其自身的邮件。

与 DKIM 和 SPF 不同，大多数邮件服务器认为他们独自负责来自domain.com. 因此，他们中的许多人都有反网络钓鱼过滤器，可以拒绝声称来自他们自己的“外部”邮件。这就像“你不能成为嘉莉，我是嘉莉！走开！”

它只是一些邮件的事实很有趣。错误也relay denied可能是关键，尽管这些反网络钓鱼过滤器经常使用“假”错误来不泄露游戏。
被拒绝邮件的收件人是否应用了某种内部转发？这可能是原因，在这种情况下，反弹原因是诚实的。
或者他们可能有更明确的反网络钓鱼功能，只拒绝来自或特定地址的邮件。您可以尝试测试某些组合，看看是否有任何可重复的。

然而，最终，它将归结为与接收邮件域的管理员合作，或者更新这些规则，或者将向他们发送邮件的 SendGrid IP 列入白名单。

于 2018-10-18T21:06:40.673 回答