При использовании службы доставки почты, такой как AWS SES или SendGrid, есть ли какие-либо преимущества от включения их записей SPF для домена в заголовок RFC5322.From (header-from)?
Поскольку они работают по умолчанию, они используют свой собственный RFC5321.MailFrom (envelope-from), который должен проверять SPF в соответствии со стандартами.
Однако мне интересно, есть ли еще какое-то преимущество, например, сломанные почтовые серверы или почтовые серверы, которые в любом случае могут проверять RFC5322.From на SPF для проверки на спам. Или просто не беспокойтесь, потому что это никогда не проверяли. Любопытно, есть ли у кого-нибудь полевой опыт по этому поводу.
Например, AWS SES использует субдомен amazonses.com в RFC5321.MailFrom. В этом вопросе предполагается, что это не было изменено с помощью пользовательской настройки «ПОЧТА ОТ».
Типичная реализация проверки SPF выполняется сразу после MAIL FROM (с отклонением, возможно, выстрелил после RCPT TO чтобы сохранить больше отладочной информации в журналах). Это до того, как появится какой-либо контент (DATA), включая заголовки сообщений. В RFC 7208, 2.2 описывает, как должна выполняться проверка на соответствие RFC5321 MailFrom и HELO/EHLO. Он также явно не рекомендует проверять любые другие удостоверения (например, RFC5322.From) по записям SPF.
Без явного одобрения публикующего ADMD НЕ РЕКОМЕНДУЕТСЯ проверять другие удостоверения по записям SPF версии 1, поскольку известны случаи, когда они дают неверные результаты. Например, почти все списки рассылки переписывают
MAIL FROMличность (см. Раздел 10.3), но некоторые не изменяют никакие другие личности в сообщении. Документы, которые определяют другие личности, должны будут определять метод явного утверждения.
Политика DMARC (RFC 7489) обеспечивает такое «явное одобрение», которое дополнительно сообщает получателю, как владелец домена хочет сообщения с обе невыровненный SPF и невыровненный DKIM (RFC 6376) подпись, которую нужно обработать. Это DMARC, который защищает RFC5322.From, тогда как SPF и DKIM сами по себе вообще не распознают такое выравнивание. Если какая-то система защиты от спама наказывала невыровненные сообщения без этого явного одобрения, это проблема на их стороне и не следует пытаться и решать с нестандартными записями SPF, как вы предлагаете.
Проблема, описанная в цитировании, остается с DMARC, потому что если сообщение было переадресовано ...
MAIL FROM, он не выдержит проверки SPF.MAIL FROM, он не выдержит выравнивания DMARC.По этой причине рекомендуется использовать DKIM с DMARC, так как он лучше выдерживает пересылку. Кроме того, кто-то, желающий опубликовать p=reject (или даже p=quarantine) следует сначала приложить некоторые усилия для настройки всех возможных законных отправителей, согласованных либо с DKIM, либо с SPF - рекомендуется с обоими.
Например. с Amazon SES это означает настройка пользовательского MAIL FROM домен: добавление субдомена со своими MX и записи SPF. Это также требует расслабленный Политика DMARC, допускающая согласование, если организационная сфера совпадений, как определено в RFC 7489 3.1.