Office365 SPF PermError: Слишком много поисков DNS
Похож на кого-то еще, уже ответило это, но думало, что я подавил определенный ответ для Вас.
Я использовал бы procmail и использовал бы рецепт в Вашем .procmailrc подобном этому:
#turn this off when you're finished testing :)
VERBOSE=on
LOGFILE=/home/user/procmail.log
:0 c #the c means continue on after this recipe is parsed
| /path/to/your/script
Вам также будет нужен рецепт по умолчанию внизу для направления почты в maildir.
Помимо всего, что уже было сказано, давайте сосредоточимся на следующем:
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 , чтобы порадовать мастера проверки, и потом вернули ее к реальной записи.
Ответ взят из SO здесь Автор: Swift . Адаптировано под вопрос. Кроме того, прочтите здесь по общему материалу SPF.
Мы начали с:
v=spf1 a mx include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all
Мы получили всего 10 запросов, прежде чем выдать ошибку Слишком много запросов DNS :
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. Я выделил несколько вариантов ниже, вам может потребоваться использовать более одного из них, чтобы отключить его.
Непосредственно включить некоторые из перенаправленных записей spf. Теперь, когда мы знаем, на какие серверы перенаправляются записи spf, вы можете исключить посредников и включить их напрямую. Примечание: если какая-либо из служб в конечном итоге изменит свои записи SPF, вам придется выполнить процесс обновления своих вручную.
Удалите некоторые из служб, которые вы используете. Не уверен, какой у вас вариант использования всех этих сервисов, но определенно есть некоторые совпадения, которые вы могли бы использовать. Например, SendGrid поддерживает (1) транзакционную исходящую почту, (2) информационные бюллетени / маркетинговые электронные письма и (3) входящую почту. Таким образом, может существовать некоторая сокращаемая избыточность.
Удалите запись MX, если она избыточна. В зависимости от ваших настроек поиск MX может быть избыточным.
Я вижу, что это отличная причина для создания поддоменов специально для отправки через третьи стороны:
Если у вас есть разные сторонние отправители, обрабатывающие разные вещи, на которые можно подписаться , то настройка отдельного субдомена может быть отличным способом управления им:
Имена субдоменов могут быть основаны на том, что отправляется:
- NewsLetterName.Example.com для информационного бюллетеня, отправляемого через третье лицо, может иметь spf запись, относящаяся к этой третьей стороне.
- Updates.Example.com, когда "обновления" были подписаны для.
- Support.Example.com, когда "Поддержка" предоставляется через стороннюю организацию.
Или Имена субдоменов могут быть основаны на стороннем отправителе, для которого они предназначены:
- ccMail.Example.com для писем с постоянным контактом
- mcMail.Example.com для писем Mail Chimp
- zendeskMail.Example.com для писем ZendDesk
Мне действительно нравится эта идея теперь, когда я ее обрисовал! Я сам попробую. Это потребует настройки дополнительных адресов электронной почты для этих поддоменов, но это упростит организацию электронной почты.
Вы можете просто использовать прокси-службу SPF, например spfproxy.org. Тогда вам не нужно сглаживать записи DNS в IP-адреса или даже возиться с поддоменами. Вы просто настраиваете прокси-сервер SPF, и он будет выполнять все поиски на бэкэнде. Это единственный способ элегантно решить эту проблему.