Office365 SPF PermError: слишком много запросов DNS

Ответ взят из SO Вот Автор: Swift. Адаптировано под вопрос. Также прочтите Вот на общие темы SPF.

Мы начали с:

v=spf1 a mx include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

Мы получаем всего 10 запросов перед тем, как бросить Too many DNS lookups ошибка:

  2 (Initial TXT & SPF Lookups)
  2 (a & mx Lookups)
  1 (_spf.google.com)
  1 (servers.mcsv.net)
 +1 (sendgrid.net)
 -----------------
  7 Lookups

Итак, даже не следуя включенным SPF-записям, у нас есть 7 поисков.

Теперь давайте погрузимся на уровень глубже.

1. _spf.google.com

Запись Google SPF оценивается как:

v=spf1 include:_netblocks.google.com include:_netblocks6.google.com ?all

Каждый из них принимает следующие значения:

# _netblocks.google.com
v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all

# _netblocks6.google.com
v=spf1 ip6:2607:f8b0:4000::/36 ip6:2a00:1450:4000::/36 ?all

Таким образом, Google дает нам еще 2 запроса, в результате чего общее количество 9 поисков.

2. server.mcsv.net

Mailchimp немного сложен, потому что он добавляет целых 3 дополнительных поиска:

v=spf1 include:spf1.mcsv.net include:spf2.mcsv.net include:spf.mandrillapp.com ?all

Я предполагаю, что в зависимости от того, что вы отправляете через Mailchimp, вы можете удалить одну или две из этих записей (но вам придется оценить это самостоятельно).

В любом случае они сводятся к следующему:

# spf1.mcsv.net
v=spf1 ip4:207.97.237.194/31 ip4:207.97.238.88/29 ip4:207.97.240.168/29 ip4:69.20.10.80/29 ip4:69.20.41.72/27 ip4:74.205.22.1/27 ip4:69.20.90.0/26 ?all

# spf2.mcsv.net
v=spf1 ip4:204.232.163.0/24 ip4:72.26.195.64/27 ip4:74.63.47.96/27 ip4:173.231.138.192/27 ip4:173.231.139.0/24 ip4:173.231.176.0/20 ip4:205.201.128.0/24 ?all

# spf.mandrillapp.com
v=spf1 ip4:205.201.136.0/24 ip4:205.201.137.0/24 ?all

Это подводит нас к общему количеству 12 поисков (Что уже на два больше лимита).

2. sendgrid.net

SendGrid оказывается для нас наименьшим количеством дополнительных запросов.

v=spf1 ip4:208.115.214.0/24 ip4:74.63.202.0/24 ip4:75.126.200.128/27 ip4:75.126.253.0/24 ip4:67.228.50.32/27 ip4:174.36.80.208/28 ip4:174.36.92.96/27 ip4:69.162.98.0/24 ip4:74.63.194.0/24 ip4:74.63.234.0/24 ip4:74.63.235.0/24 include:sendgrid.biz ~all

Итак, единственный дополнительный поиск здесь sendgrid.biz, который оценивается как:

v=spf1 ip4:208.115.235.0/24 ip4:74.63.231.0/24 ip4:74.63.247.0/24 ip4:74.63.236.0/24 ip4:208.115.239.0/24 ip4:173.193.132.0/24 ip4:173.193.133.0/24 ip4:208.117.48.0/20 ip4:50.31.32.0/19 ip4:198.37.144.0/20 ~all

В результате получается 14 запросов.

Итак, наша общая сумма 14 запросов. Нам нужно уменьшить это число до 10. Я выделил несколько вариантов ниже, вам может потребоваться использовать более одного из них, чтобы их уменьшить.

1. Непосредственно включить некоторые перенаправленные записи SPF. Теперь, когда мы знаем, на какие серверы перенаправляются записи SPF, вы можете исключить посредника и включить их напрямую. Примечание. Если какая-либо из служб в конечном итоге изменит свои записи SPF, вам придется выполнить процесс обновления ваших вручную.

2. Удалите некоторые из используемых вами служб. Не уверен, какой у вас вариант использования всех этих сервисов, но определенно есть некоторые совпадения, которые вы могли бы использовать. Например, SendGrid поддерживает (1) транзакционную исходящую почту, (2) информационные бюллетени / маркетинговые электронные письма и (3) входящую почту. Так что может быть некоторая сокращаемая избыточность.

3. Удалите запись MX, если она избыточна. В зависимости от вашей настройки поиск MX может быть избыточным.

Помимо всего, что уже было сказано, остановимся на этом:

My question is the following: How do I work around this error? I know I can replace some  
records with their ip4 equivalent, but when doing this, the online troubleshooter of  
Office365 kept complaining that the record was not found:

Недавно я столкнулся с той же проблемой.
Хотя документально подтверждено, что он должен работать (http://community.office365.com/en-us/w/exchange/customize-an-spf-record-to-validate-outbound-email-sent-from-your-domain.aspx) мы никогда не смогли бы проверить это с помощью другой записи.
Не имело значения, было ли это a:some.host.com или ip4:127.0.0.1, он всегда жаловался на неправильную / отсутствующую запись SPF.
В итоге мы изменили запись на v=spf1 include:spf.protection.outlook.com -all чтобы осчастливить мастера проверки, и потом вернули ее обратно к реальной записи.

Вы можете просто использовать прокси-сервис SPF, например spfproxy.org. Тогда вам не нужно сглаживать записи DNS в IP-адреса или даже возиться с поддоменами. Вы просто настраиваете прокси-сервер SPF, и он будет выполнять все поиски на бэкэнде. Я нашел единственный способ элегантно решить эту проблему.

Я вижу, что это отличная причина для создания поддоменов специально для отправки через третьи стороны:

Если у вас есть разные сторонние отправители, которые обрабатывают разные вещи, на которые можно подписаться, то настройка отдельного поддомена может стать отличным способом управления этим:

Имена поддоменов могут быть основаны на том, что отправляется:

• NewsLetterName.Example.com для информационного бюллетеня, рассылаемого третьим лицом, может иметь spf-запись, относящуюся к этой третьей стороне.
• Updates.Example.com, когда были подписаны "обновления".
• Support.Example.com для случаев, когда «Поддержка» предоставляется сторонними организациями.

Или имена поддоменов могут быть основаны на стороннем отправителе, для которого они предназначены:

• ccMail.Example.com для писем постоянного контакта
• mcMail.Example.com для писем Mail Chimp
• zendeskMail.Example.com для писем ZendDesk

Мне действительно нравится эта идея теперь, когда я ее обозначил! Я сам попробую. Это будет означать настройку дополнительных адресов электронной почты для этих поддоменов, но это позволит упростить организацию электронной почты.