Це межа, записана у стандарті, про яку майже ніхто не знає, доки в неї не вріжеться: під час перевірки запису SPF можна зробити щонайбільше десять DNS-запитів. Не десять пунктів у записі — десять запитів, а це інша й гірша річ.
Перейшовши стелю, запис не зникає. Він повертає постійну помилку, і відтоді пошту твоєї компанії оцінюють так, ніби SPF узагалі немає. Жодного попередження, жодного повідомлення — просто доставка, яка гіршає.
Що витрачає запит
По одному запиту коштують ось ці, і саме вони накопичуються з роками:
include:— пункт, який додають щоразу, коли вповноважують зовнішній сервіс;aіmx— зручні й дорогі;ptr— його не варто використовувати й з інших причин;redirect=— рахується нарівні з рештою;exists:— трапляється рідко, але рахується.
Нічого не витрачають ip4: та ip6:, бо це вже записані адреси, і питати ні про що не треба.
Момент, який заскочує всіх зненацька: include: коштує не один. Він коштує один плюс усе, що той запис включає у собі. Запис великого поштового провайдера часто містить ще два-три, і підрахунок рекурсивний.
Чому компанії доходять до межі непомітно
Ніхто не проєктує запис SPF понад межу. До неї доходять нашаруванням, по одному сервісу, роками:
- провайдер корпоративної пошти;
- облікова система, що шле підтвердження замовлень;
- платформа розсилок;
- сервіс електронних рахунків;
- CRM, що надсилає пропозиції;
- інтернет-магазин;
- форма на сайті;
- і, нарешті, той, якого додали минулого тижня і який перекинув лічильник.
Жодне з додавань не було помилкою. Помилкою є сума, і саме тому проблема зʼявляється через місяці після останньої зміни, яку хтось памʼятає.
Як рахувати
Вручну можливо, але нудно: читаєш свій запис, розгортаєш кожен include: і рахуєш вкладені запити, рекурсивно.
На практиці користуються одним із публічних валідаторів SPF, які роблять саме це і кажуть, на скількох ти запитах. Дивитись треба не на кількість написаних include:, а на обчислену суму.
Просте правило: якщо сума дорівнює девʼяти, ти вже в халепі. Наступний сервіс хтось додасть, ні в кого не питаючи дозволу.
Чотири шляхи повернутися під межу
1. Прибрати те, що вже не шле. Це перший крок, і його часто досить. Майже в кожному записі є дозволи для платформ, якими компанія не користується роками. Якщо сервіс не слав листів дванадцять місяців, це не відправник.
2. Замінити include: на ip4: там, де це доречно. Якщо сервіс шле з фіксованих і оголошених адрес, їх можна вписати напряму: нуль запитів. А от із сервісом, що часто змінює інфраструктуру, це крихкий вибір — адреса змінилась, ти не знаєш, і пошта перестає проходити. Годиться для власного сервера, гірше для великого хмарного постачальника.
3. Прибрати a і mx, якщо вони не потрібні. Це пункти, які ставлять за звичкою. mx уповноважує твої вхідні поштові сервери надсилати листи: якщо вони не надсилають, це подарований запит.
4. Перенести відправників на піддомен. Це структурне рішення і правильне тоді, коли перших трьох не вистачило. Розсилки виходять з окремого піддомену зі своїм записом SPF і своїм незалежним лічильником, рахунки — з іншого. Основний домен знову стає легким, а репутація потоків розділяється, що корисно й поза межею як такою.
А от що не є рішенням — це розділити запис надвоє: один домен може мати рівно один запис SPF, і два записи є помилкою, яка знецінює обидва.
Деталь, що рятує пошту під час роботи
Поки лагодиш, тримай кінець запису на ~all, а не на -all. Перше каже «те, чого немає в списку, вважай підозрілим», друге — «відхиляй». Коли підрахунок ще непевний, різниця між ними — це спокійний вечір роботи або день заблокованих листів.
На -all переходять наприкінці, коли сума під межею, а звіти DMARC підтверджують, що жоден легітимний відправник не лишився за бортом. Саме тому цю роботу роблять разом із DMARC у режимі спостереження, а не окремо: без звітів ти вгадуєш, які відправники існують насправді.
Останнє, про запис, який дістався у спадок
Якщо ти щойно взяв на ведення чужий домен, подивись на лічильник SPF раніше за все інше. Це один із найнадійніших показників того, як із цією поштою поводилися роками: запис на межі розповідає історію додавань без жодного перегляду, і поруч зазвичай знаходяться ключі DKIM від давно вимкнених сервісів і DMARC, якого немає.