SPF-запись для почтового сервера

SPF-запись для почтового сервера входит в число тех, которые вы не просто можете, но и обязаны создать для любого отправляющего почту домена. Это не только очень просто, но и исключительно полезно для улучшения репутации домена. Тем не менее, простота внедрения SPF не должна вводить вас в заблуждение, поскольку на деле все значительно сложнее. В чем именно, как раз и поговорим в этой статье.

Спонсор этой статьи RFC 7208:)

---

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

---

SPF-запись для почтового сервера

Если у вас есть сомнения в корректности и достоверности какой-либо информации, никогда не будет лишним обратиться к первоисточнику. Точно также и с SPF – в интернете очень много любительских статей о лучших практиках создания и использования SPF, но лично меня все эти советы лишь ввели в заблуждение. Именно поэтому открываем RFC 7208 и начинаем разрушать мифы.

Рекомендую к прочтению перечень статей ниже:

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

Итак, переходим к SPF.

Назначение

Спамеры могут пытаться отправить почту от имени известных доменов с хорошей репутацией, пользуясь при этом абсолютно любыми исходящими ip-адресами. SPF в этом случае призван ограничить перечень исходящих адресов, с которых разрешена отправка почты определенного домена ¹:

Even more precisely, SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain.

Другими словами – SPF защищает нас от подделки адреса отправителя (и только адреса и ничего более), позволяет авторизовать отправляющий сервер (определить разрешено ли данному серверу отправлять почту с определенного домена или нет).

Основы протокола

Реализация протокола SPF не подразумевает необходимости развертывания какой-то дополнительной инфраструктуры для его работы. Все, что вам нужно – внимательно составить список всех ваших серверов, отправляющих почту с определенного домена, а потом создать для этого домена одну единственную TXT-запись.

Задача SPF – проверить содержится ли адрес отправляющего сервера в записи SPF домена. Если адрес содержится, значит spf=pass, в противном случае spf=fail.

При этом SPF не должен однозначно отвечать на вопрос “Блокировать принимаемое сообщение или нет?”. Это должен делать ваш антиспам сервис на основе различных оценок и критериев, среди которых результат проверки SPF является лишь одним из многих. Это подтверждается и заключениями в RFC:

SPF “fail” results can alternately be used as one input into a larger set of evaluations that might, based on a combination of SPF “fail” results with other evaluation techniques, result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means).

Поэтому рекомендуемым вариантом является использование политики softfail (директива ~all один раз в записи и только в самом конце) во всех возможных случаях, чтобы исключить отклонение валидных писем, не прошедших проверку SPF (а такое бывает). Использовать -all целесообразно для доменов, с которых почта не отправляется.

HELO/EHLO и MAIL FROM

Проверяемый домен извлекается из конвертного заголовка MAIL FROM (другие названия – Return-Path, Bounce address, Envelope from) ². Однако в некоторых случаях необходимо оставлять заголовок MAIL FROM пустым. Например это используется при отправке NDR, DSN ³:

Whenever an SMTP transaction is used to send a DSN, the MAIL FROM command MUST use a NULL return address, i.e. “MAIL FROM:<>”.

Если же MAIL FROM пустой, нужный домен будет извлекаться из ответа HELO/EHLO отправляющего сервера.

Более того, RFC рекомендует сначала выполнять проверку HELO/EHLO как наименее ресурсоемкую по сравнению с MAIL FROM. Именно поэтому одной из рекомендаций RFC является также создание SPF-записи для DNS-имени, которое сервер отправляет в приветствии HELO/EHLO.

Принцип работы SPF подсказывает ещё одну особенность этого протокола – результаты его работы абсолютно незаметны для конечного пользователя. Действительно, MAIL FROM является конвертным заголовком и юзеру не виден, при этом заголовок From самого сообщения может содержать вообще другой адрес (от подмены этого заголовка защищает совсем другой протокол – DKIM, о котором читайте в статье Технология DKIM для почтового сервера). HELO/EHLO не видны пользователю тем более, при том они ещё и маскируется в конвертных заголовках Received ⁴. А другие данные SPF не анализирует.

Ограничения SPF

Если бегло пробежаться по RFC 7208, натыкаешься на очень любопытные ограничения, которые можно запросто упустить из виду, например:

• Допускается использование только записей TXT. Любые другие типы (например SPF) как минимум считаются экспериментальными, а как максимум не поддерживаются вовсе;
• Для каждого имени должна существовать лишь одна единственная запись SPF, множественные записи не поддерживаются. При этом допускается разделение одной записи на несколько частей, если суммарное количество символов превышает 255. Все же желательно, чтобы запись была как можно короче;
• Не используйте записи PTR внутри SPF, стандарт это запрещает в явном виде:

5.5. “ptr” (do not use)
…
This mechanism SHOULD NOT be published.
…
Note: This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. If used, proper PTR records have to be in place for the domain’s hosts and the “ptr” mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, it has been concluded that it is unnecessary and more reliable alternatives should be used instead.

• Запись должна содержать как можно меньше вложений вида a, mx, include (и ptr конечно), поскольку они требуют выполнения DNS-запросов для получения ip-адреса, а реализация SPF запрещает выполнение более 10 запросов. Почитать подробнее об этом ограничении вы можете в статье 10 DNS-запросов для одной SPF-записи;
• Расположите DNS-зависимые директивы в конце записи, а ip4/ip6 – в начале;
• Помните, что SPF-запись вы внедряете для получателей ваших писем, чтобы им было проще идентифицировать вас как надежных отправителей вашего домена. Эта запись никак не влияет на объем спама, который приходит на ваш домен от сторонних отправителей.

Для получения более подробной информации обращайтесь к первоисточнику. Если совсем лень читать на английском, то могу порекомендовать замечательную статью от Mail.ru – Загадки и мифы SPF. А я перехожу к долгожданным примерам.

Примеры записей

Освоив необходимый пласт теории, можно переходить к созданию записей. В большинстве случаев SPF-запись может быть предельно проста.

• Вариант ниже подходит для доменов, почту с которых отправляют только указанные в MX-записи серверы:

• Вот этот подходит в том случае, если почта отправляется лишь с одного сервера (а можно указать несколько штук, если нужно). Этот вариант предпочтительнее, ведь он не требует выполнения дополнительных DNS-запросов для извлечения нужных адресов:

• А этот пример подходит для дочерних доменов, которым разрешено отправлять почту с тех же адресов, что и основному домену:

• Широко встречаются варианты с отдельным именем и привязанной к нему SPF-записью и редиректами со стороны записей почтовых доменов (пример mail.ru. Обратите внимание также на разбивку крупной записи на несколько кусков):

• Пример ниже иллюстрирует добавление отдельной записи для fqdn-сервера, отправляющего почту. Именно эту запись сервер вписывает в сообщение HELO/EHLO:

А вот такой странный вариант у Yahoo (тут используется и строго не рекомендуемая ptr):

В общем виде запись всегда должна начинаться с версии протокола, которых на данный момент всего одна штука – v=spf1. Далее следуют различные директивы с указанием адресов или имен, с которых возможна отправка почты данного домена (a, mx, include и др.). При этом заканчиваться запись должна либо опцией redirect, либо политикой (~all, -all или др.).

Если у вас возникают сложности с внедрением SPF или возможно вы хотите подойти к вопросу фундаментально, советую изучить лучше практики ⁵, наиболее частые ошибки ⁶ и просто почитать FAQ ⁷. А у меня на этом все. Конечно я ещё не рассказал о макросах, но встречаются они достаточно редко, да и это уже совсем другая история.