Ваша текущая запись не имеет смысла.Правила оцениваются слева направо, поэтому ваш механизм по умолчанию (all
) всегда должен быть последним.
Когда вы include
записываете внешнюю запись SPF, любое содержащееся в ней действие all
фактически игнорируется (поскольку онопереопределяется вашими последующими директивами).
Запись MailChimp тупая ( quelle Surprise );?all
эквивалентно отсутствию записи SPF, но в данном случае это не имеет значения.
Механизмы с буквальным IP являются самыми быстрыми, потому что для проверки не требуется поиск DNS, поэтому считается вежливым ставить ихfirst.
Вам не нужен +
перед механизмами, так как это квалификатор по умолчанию.
Механизм a
означает «разрешить IP, возвращенный записью A
дляэтот хозяин ".Аналогично, mx
означает «разрешить отправку с любого IP-адреса, который также является почтовым обменником (почтовым сервером) для этого домена».Если это правда, добавьте их.Я рекомендую помещать их перед любыми include
механизмами, потому что они требуют только одного поиска DNS, и они вполне могут быть кэшированы получателями в любом случае.
Вы никогда не должны использовать +all
;это активно плохо, поскольку дает всем источникам положительный результат pass
, что хуже, чем отсутствие записи SPF.?all
- это то же самое, что не иметь SPF, поэтому вы не должны его использовать.
Если вы также используете DMARC, вы должны использовать ~all
;если нет, используйте -all
.Причиной этого является то, что правила SPF оцениваются до DMARC, и -all
приведет к немедленному прекращению, прежде чем DMARC получит шанс сделать свое дело.Затем DMARC можно настроить на отклонение всего, что получает softfail
, и его механизмы отчетности могут делать то, для чего они предназначены.
Я бы порекомендовал эту запись, если вы используете DMARC, и то же самоено -all
, если вы не:
v=spf1 ip4:111.222.333.444 a mx include:_spf.google.com include:servers.mcsv.net include:mailgun.org ~all
Независимо от того, что вы в конечном итоге, проверьте его на Валидатор Скотта Киттермана .