У записі SPF Office365 є занадто багато запитів

З надзвичайно смішних адміністративних причин у нас є розділений домен з однією поштовою скринькою на 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 - запитах , які викликають PERMERRORи зі строгими 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

але можливі проблеми, які я бачу з цим, є:

1. Нам потрібно бути в курсі будь-яких змін батьківського запису spf.protection.outlook.comта spf.messaging.microsoft.comзаписів. Якщо щось зміниться або [дай бог] додано, нам доведеться вручну оновити своє, щоб це відобразити.
2. Завдяки нашому фактичному доменному імені довжина запису становить 260 знаків, що вимагає 2 рядків для запису TXT, і я, чесно кажучи, не вірю, що всі клієнти DNS та розв'язувачі SPF там правильно приймуть запис TXT довше 255 байт .

З недавньої дати, 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, можна використовувати адреси електронної пошти в межах піддомену, а не базовий домен.