根据sendgrid文档，Inbound解析器webhook对失败的响应方式是，它将在3天内重试将电子邮件发送到配置的端点，如果未送达，则会丢弃电子邮件。
解析API将解析后的电子邮件POST到您指定的URL。如果POST不成功，SendGrid会自动排队并重试任何以5XX状态响应的POST。这样可以防止错误配置网站或POST URL的客户丢失数据。
以2xx状态响应POST请求，以阻止电子邮件重试。
为了避免返回错误，您的链接在收到电子邮件时必须返回2xx HTTP代码。此响应使我们的系统知道您的链接已收到电子邮件。然后它会从我们的发送队列中删除。如果我们没有得到有效的2xx HTTP响应，我们的服务器会认为他们无法传递您的消息。3天后无法送达的邮件将被丢弃。
我想知道在删除未送达的电子邮件之前，sendgrid是否会通知发件人他们的电子邮件无法送达？
根据我运行的一些测试，SendGrid似乎永远不会向发件人发送通知，也没有任何简单的方法来确定SendGrid是否丢弃了任何入站电子邮件。
尽管文档措辞有点模糊，但我基于测试(与文档措辞一致)的理解是：
- 服务器返回2xx:电子邮件被视为已接受，不再尝试
- 服务器返回5xx：服务器有错误，在返回2xx之前进行的尝试(有关后续尝试的时间安排，请参阅下文)，或72小时后
- 服务器返回任何其他响应，或者DNS记录不存在：电子邮件被视为失败，不再尝试
我的结论是基于我在一周内进行的一些测试，从中我确定了以下内容：
案例1。解析服务器返回400或403错误
尝试一次后，将删除电子邮件
不再尝试POST电子邮件
不会向发件人或SendGrid帐户发送任何通知
(测试方法：将SendGrid配置为返回上述错误代码之一的URL。检查了1周以上的服务器日志，并注意到只进行了一次尝试。)
案例2。解析挂钩URL没有DNS记录
电子邮件可能在一次尝试后被丢弃
不会向发件人或SendGrid帐户发送任何通知
(测试方法：将挂钩URL配置为没有任何DNS记录的子域。运行DNS搜索并尝试打开挂钩URL以确认DNS记录没有指向任何位置。发送电子邮件。然后，在12小时后，将适当的记录添加到子域以指向脚本。检查服务器日志并确认没有尝试POST电子邮件。随后的电子邮件尝试成功ly张贴。)
案例3。解析服务器返回500错误
SendGrid尝试按以下间隔POST到挂钩URL：
+0+5m+10m+15m+20m
+25m+35m+50m+1h20m+2h20m
。。。然后每3小时
最后一次尝试发生+71h20m
20分钟的偏移量有点不寻常，但它取决于小时，所以这可能是因为消息排队是为了尝试在小时发布
72小时后不会再尝试POST电子邮件
不会向发件人或SendGrid帐户发送任何通知。
统计信息
文档中提到了统计信息的可用性，但我发现这些数字不准确。
例如，在我的测试过程中，我有许多电子邮件通过API，包括一些原本打算成功的电子邮件(并确实向我的服务器进行了POST)和一些原本打算失败的电子邮件(作为上述测试的一部分)，然而，返回的数字并不一致。
外卖
在以下情况下应小心：
- 服务器停机时间：这最终取决于服务器的配置方式。如果服务器返回5xx响应代码，SendGrid将继续尝试POST电子邮件。我还尝试测试了一个超时场景，然而，SendGrid似乎很有耐心(例如，我让我的脚本暂停了10分钟，SendGrid保持了10分钟的连接，但有趣的是，由于第二次尝试发生在5分钟后，电子邮件被张贴了两次)
- 服务器配置错误，返回4xx错误代码。SendGrid将丢弃电子邮件
还应该注意的是，如果电子邮件被丢弃，似乎没有任何可靠的方法来发现这一点。
SendGrid在删除电子邮件之前不会发送通知。但是，只有在收到来自Webhook URL的错误并尝试发布消息三天后，才会删除该消息。
我们从Sendgrid支持团队得到确认，在Inbound Webhook Parser功能中丢弃的电子邮件将不会有任何通知或保存在Sendgrid中。因此，我们将无法获得任何有关被丢弃的电子邮件的信息。