10 DNS-запросов для одной SPF-записи

Интересное ограничение существует в RFC 7208 относительно протокола SPF и заключается оно в выполнении максимум 10 DNS-запросов для одной записи. Иными словами, если внутри SPF-записи присутствует много DNS-зависимых директив, по которым проверяющий сервер должен делать дополнительные запросы, то после достижения 10 запросов вы получите ошибку.

В статье ниже проверим как это ограничение работает на практике.

Если вам интересна тематика почтовых серверов, рекомендую обратиться к соответствующей рубрике на моем блоге – Mail Servers.

10 DNS-запросов для одной SPF-записи

SPF-запись защищает нас от подделки адреса отправителя, позволяя авторизовать отправляющий сервер. То есть, определить разрешено ли данному серверу отправлять почту для домена, указанного в заголовке MAIL FROM или в приветствии HELO/EHLO. С точки зрения оценки спам-рейтинга сообщения функционал очень полезный, хоть он и не рассчитан на принятие однозначного решения о блокировке по результатам проверки.

Прочитать подробнее о SPF вы можете в основной статье – SPF-запись для почтового сервера. Также рекомендую к изучению:

• Базовые DNS-записи для почтового сервера
• Технология DKIM для почтового сервера

А я перехожу к небольшой порции теории.

Теория

После получения SPF-записи для домена необходимо извлечь из неё список ip-адресов, с которых разрешена рассылка почты. Если вся запись состоит из директив ip4/ip6, то процесс на этом и заканчивается (ведь они уже содержат адреса/подсети в чистом виде). Если же внутри записи присутствуют DNS-зависимые директивы (include, a, mx, ptr, exists), то необходимо выполнить дополнительные запросы к сервису DNS.

Все бы ничего, но протокол явно ограничивает максимально допустимое количество DNS-запросов для одной записи SPF ¹:

SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS.

Разумеется это сделано во благо, но для администраторов почтовых сервисов (в особенности распределенных, со сложной топологией) это ограничение заставляет с умом подходить к процессу создания и поддержки SPF-записи.

Рекомендации

Исходя из ограничений протокола, большинство рекомендаций вполне очевидны, но есть и некоторые нюансы, которые заставляют быть более внимательными.

• Первая и главная рекомендация – поддерживайте SPF-запись настолько короткой, насколько это возможно.
• Располагайте директивы ip4/ip6 в начале записи, а остальное – в конце.
• И последняя – если включаете в запись директиву mx, то примите во внимание, что А-записи, на которые указывает MX, тоже входят в лимит 10 запросов DNS на одну SPF.

Если говорить о лимитах, то не лишним будет напомнить, что для создания TXT-записей существует ограничение в 255 символов, в которое вы можете упереться раньше, чем в 10 DNS-зависимых директив. Тем не менее, оно легко обходится ² путем создания составной записи.

Проверка

Лично мне захотелось проверить последнее ограничение на практике и я создал MX-запись, которая указывает на кучу А-записей.

MX выглядит вот так:

Из всех записей только mail.bq-srv.ru указывает на реальный сервер, а остальные вообще не существуют, но это неважно.

А это SPF:

Если попробовать отправить почту с этого сервера, то она будет успешно доставлена. Возможно попадет в спам, но принимающий сервер вероятнее всего её пропустит. Попробуем:

Почему spf=pass?!

Важно помнить, что DNS-сервер будет выдавать записи в разном порядке и именно в таком виде их будет обрабатывать проверяющий SPF-запись сервер. Если mail.bq-srv.ru окажется выше десятой позиции, то spf=pass, если ниже, то spf=fail. Повторим попытку и будем надеяться, что в этот раз “повезет”:

Вот теперь получили что ожидали – spf=permerror, как и написано в RFC:

SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return “permerror”.

Если перед записью MX внутри SPF у вас будут любые другие DNS-зависимые директивы, то на лимит в 10 записей вы нарветесь быстрее. В любом случае, если вдруг будете попадать на spf=permerror, вспомните об этом ограничении (а если попросите у принимающей стороны логи, то увидите ошибку – Mechanisms used too many DNS lookups). Успехов!