Основным недостатком создания SPF-записи, которая фактически помогает доставляемости (ограничивая почтовые источники), является то, что вам необходимо знать и ограничивать источники, из которых может отправляться электронная почта, а это не обязательно просто.
Скажем, ваш домен - example.com, и вы хотите отправить электронное письмо с этого домена, используя вашу учетную запись gmail (хотя gmail не используется для обработки электронной почты ваших доменов); ваш SPF должен включать SPF в gmail, и это означает, что любой в gmail сможет отправлять имя вашего домена из gmail (несмотря на другие меры). Теперь представьте, что вы большая компания, и у вас есть давняя история, когда сотрудники регулярно отправляли электронные письма с адресов компаний, используя своего местного интернет-провайдера. Ваш SPF должен стать очень большим или очень тупым и включать столько источников электронной почты, что он станет неэффективным в качестве контрмеры.
Нежелание иметь дело с жалобами пользователей, когда вы говорите, что вся исходящая почта должна проходить через почтовые серверы компании (если у вас долгая история этого не требует), было бы больно для ленивой поддержки ИТ отдел. Я не сочувствую этой политике - ты пожнешь то, что посеешь.
Конечно, вы можете иметь запись SPF «только по названию», установив для нее что-то бесполезное, например +all - это даст технический «пропуск» SPF для всех источников, но во всех остальных отношениях он совершенно бесполезен, пометка мошеннических, спамовых и фишинговых сообщений так же, как и законных писем.
Любой ИТ-отдел, который преднамеренно игнорирует преимущества SPF, в конечном итоге столкнется с серьезной проблемой доставки и фишинга, поэтому вы можете обоснованно утверждать, что они не справляются со своей работой, и я бы порекомендовал сообщить об этом высшему руководству.