По совершенно нелепым административным причинам у нас есть разделенный домен с одним почтовым ящиком в Office365, что требует от нас добавления include:outlook.com к нашей записи SPF. Проблема в том, что одно только это правило требует девять Максимальное количество запросов DNS - 10.
Серьезно, это ужасно. Вы только посмотрите на это:
v=spf1
include:spf-a.outlook.com
include:spf-b.outlook.com
ip4:157.55.9.128/25
include:spfa.bigfish.com
include:spfb.bigfish.com
include:spfc.bigfish.com
include:spf-a.hotmail.com
include:_spf-ssg-b.microsoft.com
include:_spf-ssg-c.microsoft.com
~all
Учитывая, что у нас есть собственная большая почтовая система, нам нужны правила для a, mx, include:_spf1.mydomain.com, и include:_spf2.mydomain.com что дает нам 13 запросов DNS, которые вызывают PERMERRORs со строгими валидаторами SPF и совершенно ненадежной / непредсказуемой валидацией с нестрогими / плохо реализованными валидаторами.
Можно ли как-то устранить 3 из них? include: правила из раздутой записи outlook.com, но по-прежнему покрывают серверы, используемые O365?
Комментаторы отметили, что мы должны просто использовать более короткий spf.protection.outlook.com запись. Пока это является новости для меня, и это является короче, короче всего на одну запись:
spf.protection.outlook.com
include:spf-a.outlook.com
include:spf-b.outlook.com
include:spf-c.outlook.com
include:spf.messaging.microsoft.com
include:spfa.frontbridge.com
include:spfb.frontbridge.com
include:spfc.frontbridge.com
Я полагаю, мы можем технически сократить это до:
v=spf1 a mx include:_spf1.mydomain.com include:_spf2.mydomain.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com ~all
но потенциальные проблемы, которые я вижу здесь:
spf.protection.outlook.com и spf.messaging.microsoft.com записи. Если что-то будет изменено или [не дай бог] добавлено, нам придется вручную обновить наши, чтобы отразить это.В последнее время Microsoft «исправила» эту проблему, избавившись от всех подзаписей и использовав вместо них 2 или 3 записи «ptr»:
$ dig TXT spf.protection.outlook.com
spf.protection.outlook.com. IN TXT "v=spf1 ptr:protection.outlook.com ptr:o365filtering.com -all"
$ dig TXT spf.messaging.microsoft.com
spf.messaging.microsoft.com. IN TXT "v=spf1 ptr:protection.outlook.com ptr:messaging.microsoft.com ptr:o365filtering.com -all"
Вот в чем проблема: хотя это поможет клиентам Office 365 не оставаться ниже PermError «Слишком много запросов» ... он делает это, заставляя каждый почтовый сервер в мире выполнять (дорогостоящие) поиски PTR для каждого IP-адреса, который к ним подключается.
По Спецификация SPF:
По возможности следует избегать использования этого механизма в записи SPF, поскольку это приведет к большему количеству дорогостоящих поисков DNS.
Мы тоже обнаружили эту проблему. Microsoft «поощряет» вас использовать Office 365 исключительно для своей электронной почты, поскольку сейчас нет места для добавления новых элементов.
Мы обошли это двумя способами.
Во-первых, мы можем сократить количество запросов DNS, добавив другие записи как явные записи IPv4. Это позволяет нам добавить несколько явных IP-адресов, прежде чем мы include:outlook.com
Во-вторых, мы создали отдельный поддомен в нашем основном домене для материалов Office 365. Таким образом, электронные письма @ foo.company.com получат SPF для Office 365, а электронные письма @ comapny.com - наш обычный SPF. Это не идеально, но, к счастью, все места, где мы использовали Office 365, могут использовать адреса электронной почты в субдомене, а не в базовом домене.