Ptr запись домена отправителя и обратного доменного имени (reverse DNS) и их место на почтовом сервере

/ Обратные доменные имена (reverse DNS) и их место в работе почтового сервера

Для чего нужно?

или
550-There’s no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.

или просто
550 Your IP has no PTR Record

Число 550 во всех трёх случаях является стандартным кодом SMTP, сообщающим о критической ошибке, которая непреодолимо препятствует дальнейшей работе в рамках данной почтовой сессии. Надо сказать, что вообще все ошибки серии 500 являются критическими и продолжение передачи почты после их появления невозможно. Текст же поясняет причину отказа более подробно и сообщает, что администратор сервера-получателя настроил его на проверку наличия у сервера-отправителя записи в обратной зоне DNS (rDNS) и в случае её отсутствия получатель обязан отказывать отправителю в соединении (SMTP-ошибки серии 5XX).

Как настроить и использовать?

Примеры хороших имён для сервера почты:

mail.domain.ru
mta.domain.ru
mx.domain.ru

Примеры плохих имён:

host-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru

и подобные. Такие имена с высокой вероятностью попадут под фильтр как назначенные клиентским компьютерам, на которых не может быть установлен почтовый сервер, следовательно с них рассылается спам.

С успехом использовать запросы к обратным зонам DNS можно и нужно сразу после запуска почтового сервера. Для этого необходимо произвести лишь небольшую настройку ПО. В разных почтовых серверах настройка проверки rDNS делается по-разному:

• так для почтового сервера Postfix необходимо включить опцию
  reject_unknown_client
• в другом популярном почтовом сервере Exim
  verify = reverse_host_lookup
• MS Exchange Server
  В оснастке Exgange Server перейти в раздел Servers далее выбрать сервер в развернутом списке, выбрать Protocols, далее протокол SMTP, в правом окне выделить SMTP сервер и по клику правой клавишей мыши выбрать из списка Properties. Далее закладка Delivery → Perform reverse DNS lookup on incoming messages

Затрудняетесь с самостоятельной настройкой почтового сервера? Поручите все заботы профессионалам — хостинг корпоративной почты с круглосуточной поддержкой.

Частые вопросы

PTR-запись для почтового сервера — какую указать?

В случае поддержки собственного почтового сервера указать PTR-запись необходимо. Если она отсутствует или автоматически создана провайдером, письма с такого сервера в лучшем случае будут попадать в спам, а в худшем вообще отклоняться mail-серверами получателей.

Как создать PTR-запись?

Как проверить PTR-запись?

Команды для запроса PTR:

• В командной строке ОС Windows ввести:
  nslookup
  и после ввести интересующий IP-адрес.
• В командной строке ОС Linux ввести:
  dig -x <IP-адрес>

Последнее время мы уделяли мало внимания почтовым системам, но вновь возросший интерес заставил нас вернуться к этой теме. Основные затруднения начинающих при работе с почтой состоят в том, что почта — это сложная система, состоящая из нескольких компонентов, взаимодействующих как между собой, так и с внешними системами. Кроме того, почта крайне чувствительная к правильной настройке DNS. Чтобы разобраться и не запутаться во всем этом мы предлагаем освежить знания по базовому устройству систем электронной почты при помощи этой статьи.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Общее устройство и принципы работы почтового сервера

Севрер электронной почты — это сложная система, состоящая из множества компонентов, которые взаимодействуют между собой. Поначалу кажется, что разобраться во всем этом многообразии довольно сложно. Но это не так, почтовый сервер содержит ряд ключевых компонентов, вокруг которых уже выстраиваются дополнительные и для понимания происходящих процессов достаточно знать основные принципы работы.

Давайте рассмотрим схему ниже, она предельно упрощена и содержит только самые важные элементы, которые лежат в основе любой почтовой системы.

Их ровно три:

• Message transfer agent (MTA) — агент передачи сообщений. Данный компонент, собственно, и является почтовым сервером в узком понимании этого термина, он работает по протоколу SMTP и его основная задача прием и передача почтовых сообщений, как для внешних получателей, так и для внутренних. Взаимодействует как с внешними серверами, так и с почтовыми клиентами. И это единственный компонент почтового сервера, который имеет связь с внешним миром. Основная задача MTA — это отправка почты внешним получателям и получение почты для внутренних.
• Message delivery agent (MDA) — агент доставки сообщений. Он обеспечивает доставку полученных от MTA сообщений к месту прочтения клиентским приложением. Проще говоря, именно с помощью MDA почтовый клиент может получить доступ к собственной почте. Работает по протоколам POP3 и IMAP, также отдельные решения могут использовать проприетарные протоколы, такие как MAPI Exchange. MDA не взаимодействует с внешними системами и не принимает участие в отправке почты, его задача — доставка уже полученных сообщений клиенту почтовой системы.
• Хранилище почтовых ящиков — третий компонент почтового сервера, отвечающий за хранение полученных и отправленных сообщений. Различные системы могут использовать разные форматы хранения, в Linux системах наиболее распространены mbox и Maildir, но на этом варианты хранилищ не исчерпываются.

Когда пользователь хочет получить свою почту, он обращается к агенту доставки сообщений (MDA), сегодня MDA несут важную дополнительную функцию — ведение базы пользователей и их аутентификацию. Проверив, что пользователь тот, за кого себя выдает MDA предоставляет ему доступ к собственному ящику в хранилище при помощи выбранного пользователем протокола. Во всех современных решениях используется протокол IMAP, который позволяет гибко управлять собственным почтовым ящиком и не требует обязательного скачивания сообщений клиентом.

Если же мы хотим отправить почту, то почтовый клиент связывается с MTA, либо с дополнительным компонентом — Message submission agent (MSA) — агентом отправки почты, он использует отдельный порт — 587 и его задача получение сообщений от почтового клиента и передача их MTA для отправки по назначению. Вне зависимости от наличия MSA клиент всегда может отправить почту непосредственно через MTA.

Мы не стали добавлять MSA на основную схему, чтобы не плодить дополнительных сущностей, но о его существовании надо знать, чтобы не удивляться наличию дополнительного порта на почтовом сервере. Его появление во многом обусловлено ограниченностью протокола SMTP, тогда как для взаимодействия с клиентами нужны были дополнительные функции, поэтому MSA работает через протокол ESMTP (Extended SMTP) и поддерживает, например, такие возможности, как аутентификацию пользователей. Чаще всего функции MTA и MSA выполняет один и тот же пакет.

Теперь, читая, скажем, про связку Postfix + Dovecot + Roundcube вы будете четко понимать, что речь идет про MTA (Postfix), MDA (Dovecot) и веб-клиента MUA (Roundcube), представлять назначение каждого компонента и не путаться во взаимодействии с ними.

Обязательные DNS-записи: MX и PTR

Итак, мы хотим отправить почту. Пользователь открывает MUA, быстро создает сообщение и нажимает кнопку Отправить. Дело сделано, но мало кто задумывается о том, что происходит после, все мы привыкли что уже через считанные секунды наше сообщение будет в почтовом ящике получателя.

На самом деле сообщению предстоит достаточно длительный путь, сопровождаемый активной работой компонентов как сервера отправителя, так и сервера получателя. Но пойдем по порядку.

Первым в дело вступает MTA, он анализирует поле адреса назначения в заголовках письма, допустим мы видим там:

To: Maria Smirnova <MSmirnova@example.org>
From: Ivanov Ivan <IIvaniov@example.com>

Если домен получателя отличается от обслуживаемого MTA домена, то он должен каким-то образом узнать, кому именно отправлять почту. Для этого он использует систему DNS, запросив специальную запись — MX. MX — Mail Exchanger — особая DNS-запись, указывающая на адрес почтового шлюза домена, таких записей может быть несколько, они отличаются приоритетом, чем больше число — тем ниже приоритет.

@ IN MX 10 srv-mx-01
srv-mx-01 IN A 203.0.113.25

Часто администраторы предпочитают использовать псевдонимы — CNAME — для указания на отдельные почтовые узлы. Это удобно, но в любом случае MX-запись должна содержать реальное имя узла, а не псевдоним, поэтому правильно будет так:

@ IN MX 10 srv-mx-01
smtp IN CNAME srv-mx-01
imap IN CNAME srv-mx-01
srv-mx-01 IN A 203.0.113.25

Принимать почту в домене могут несколько серверов, или один, но на разных каналах. Допустим у нас есть основной канал и есть резервный, тогда набор записей будет выглядеть так:

@ IN MX 10 srv-mx-01
@ IN MX 20 srv-mx-02
srv-mx-01 IN A 203.0.113.25
srv-mx-02 IN A 198.51.100.25

Если сервер-отправитель не сможет отравить почту первому MX-серверу в списке, то он переключится на второй. Обратите внимание на разный приоритет серверов: 10 и 20, таким образом пока доступен сервер с приоритетом 10 почта никогда не будет направляться серверу с приоритетом 20.

А если мы укажем несколько серверов с одинаковым приоритетом? Почта будет направляться на все из них по принципу Round-robin, т.е., чередуясь по кругу, такое решение можно использовать для балансировки нагрузки.

Для кого следует прописывать обратную запись? Для имени узла, фактически отправляющего почту, вне зависимости от того, какие домены он обслуживает. Так один почтовый сервер может обслуживать множество доменов, но PTR-запись мы должны прописать для фактического имени хоста. В классическом виде PTR-запись будет выглядеть так:

25.113.0.203 IN PTR srv-mx-01.example.com.

Обращаем внимание на то, что в PTR всегда указывается полное доменное имя FQDN и обязательно с точкой на конце. Но это знание более академическое, так как обратной зоной будет управлять ваш провайдер и прямого доступа туда у вас не будет.

Еще один интересный момент, это обратные записи для нескольких каналов одного сервера, ошибкой будет прописать:

25.113.0.203 IN PTR srv-mx-01.example.com.
25.100.51.198 IN PTR srv-mx-02.example.com.

Почему? Да потому что сервера srv-mx-02 у нас физически не существует, мы придумали его как второе имя для основного сервера srv-mx-01 и в заголовках писем в качестве отправителя будет присутствовать именно это имя. Кроме того, как мы уже говорили, MX-сервера не имеют никакого отношения к процессу отправки почты.

Поэтому правильно будет сделать PTR-записи так:

25.113.0.203 IN PTR srv-mx-01.example.com.
25.100.51.198 IN PTR srv-mx-01.example.com.

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

SPF — Sender Policy Framework

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

Чаще всего содержимое SPF сводится к стандартному:

@ IN TXT "v=spf1 +a +mx ~all"

Запись состоит из списка тегов и значений, теги в SPF-записи называются механизмами и могут иметь следующие значения:

• v — версия SPF, это обязательный механизм, сейчас доступно единственное значение v=spf1
• a — определяет узлы на основе доменного имени (A-записи), формат a:example.com, если домен не указан, то применяется текущий домен
• mx — определяет узлы на основе MX-записей домена, если домен не указан, то применяется текущий домен
• ip4/ip6 — определяет узлы на основе IPv4 или IPv6 адреса
• all — все остальные узлы
• include — включает в состав SPF-записи указанного домена, например, include:_spf.yandex.net
• redirect — использовать для домена SPF-записи указанного домена.

Для уточнения действий к механизмам применяются квалификаторы (префиксы):

• + — Аутентификация пройдена. Узлу разрешена отправка почты от имени домена.
• — — Аутентификация не пройдена. Узлу запрещена отправка почты от имени домена.
• ~ — Аутентификация с неполным отказом. Скорее всего, узлу запрещена отправка почты от имени домена.
• ? — Нейтральный квалификатор, обозначает что для узла нет явных указаний, обычно используется как ?all

Таким образом стандартная запись читается как: разрешено отправлять почту узлам перечисленным в A и MX записях домена, остальным, скорее всего запрещено. При аутентификации с неполным отказом письма от прочих узлов обычно не отвергаются получателем, а помечаются как подозрительные. Квалификатор «+» подразумевается по умолчанию и его можно не указывать. Если нам нужно указать несколько узлов, то используем несколько механизмов. Например:

@ IN TXT "v=spf1 a a:mail.example.org mx -all"

Здесь мы указали, что отправлять почту можно с узлов указанных в A и MX записях текущего домена, а также с узла mail.example.org.

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

@ IN TXT "v=spf1 -all"

Теперь немного об include и redirect, может показаться, что они делают одно и тоже, но есть тонкости. Механизм redirect просто перенаправляет вас к записям указанного в нем домена. Это удобно, если сервер обслуживает сразу несколько доменов, это позволяет иметь одну единственную запись, которую будут использовать все остальные. Также это применяется при использовании своего домена совместно c публичными почтовыми системами:

@ IN TXT "v=spf1 redirect=_spf.yandex.net"

Такая запись указывает использовать для домена записи, указанные у публичной службы.

Если же вместе с публичными сервисами вы используете собственные сервера, то вам нужно использовать механизм include, который подгрузит записи указанного домена к вашим собственным.

@ IN TXT "v=spf1 ip4:203.0.113.25 include=_spf.yandex.net ~all"

Данная запись говорит о том, что отправлять почту имеет право узел с адресом 203.0.113.25, а также все остальные, которые перечислены в записях указанного домена.

DKIM — DomainKeys Identified Mail

Если говорить коротко, то DKIM — это технология электронно-цифровой подписи, которая позволят получателю убедиться, что письмо действительно принадлежит отправителю. Для этого на каждом почтовом сервере, которые отправляют почту в нашем домене мы генерируем ключевую пару RSA. Закрытый ключ мы добавляем в конфигурацию почтового сервера и теперь он будет подписывать все исходящие письма.

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

Для того, чтобы проверить подлинность подписи мы публикуем открытый ключ и используем для этого систему DNS, сформировав специальную запись типа TXT:

m1._domainkey TXT "v=DKIM1; k=rsa; p=<публичный ключ>"

Где m1 — селектор, он выбирается произвольно и должен быть уникальным для каждого почтового сервера, также селектор указывается в конфигурации почтового сервера при настройке подписи DKIM. Он нужен для того, чтобы получатель мог получить открытый ключ именно того сервера, который отправил данное письмо.

Механизм предельно прост, при подписи письма сервер отправитель добавляет в заголовки селектор, сервер получатель извлекает селектор и ищет в DNS запись DKIM для этого селектора, после чего извлекает оттуда открытый ключ и проверяет подлинность подписи.

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

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC — это техническая спецификация, обеспечивающая единые механизмы проверки почты по SPF и DKIM, а также формирование и отправку отчетов. На первый взгляд выглядит сложно и непонятно, но на самом деле позволяет отправителю не только дать прямые указания что делать с почтой, но и получать обратную связь от получателей, что очень важно если вы только тестируете отправку почты.

В простейшем случае DMARC запись выглядит так:

_dmarc TXT "v=DMARC1; p=none; rua=mailto:report@example.com"

Запись состоит из тегов:

• v — версия DMARC, обязательный тег, в настоящее время единственное значение v=DMARC1
• p — правило для домена, указывает какое действие следует предпринять если письмо не прошло проверку, может иметь значения: none — ничего не делать, quarantine — поместить письмо в карантин, reject — отклонить письмо.
• sp — правило для субдоменов, принимает такие же значения, как и p.
• aspf и adkim — позволяют указать строгость проверки, по умолчанию используется мягкая проверка, при которой результат будет провален только при провале и SPF и DKIM, с помощью данных опций и значения s (strict) мы можем ужесточить проверку, и она будет провалена при провале только одной из указанных опций.
• pct — процент писем, подлежащих фильтрации DMARC, удобно для постепенного внедрения проверки, например, мы можем для начала указать 10% и потом по отчетам анализировать правильность настройки почтовой для отправляемых нами писем.
• rua и ruf — адреса для направления ежедневных отчетов о применении политик DMARC, при этом ruf используется для отчета только о письмах, не прошедших проверку.
• fo — определяет о каких не пройденных проверках сообщать владельцу домена, по умолчанию значение 0 — сообщать только если не пройдены проверки SPF и DKIM, 1 — если не пройдена хотя бы одна проверка, s или d — если не пройдена SPF или DKIM.

В самом простом варианте мы говорим получателям ничего не делать с не прошедшими проверку письмами и слать нам отчеты на указанный адрес.

Более сложная политика может выглядеть так:

_dmarc TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:report@example.com; ruf=mailto:admin@example.com; fo=1; pct=25"

Данная запись предписывает не прошедшие проверку письма основного домена отправлять в карантин, поддоменов — отклонять, сообщать если не пройдена даже одна из проверок и фильтровать 25% входящей почты. Отчеты присылать на указанные адреса, в нашем случае они разные. Общий отчет направляется в один почтовый ящик, отчет о не прошедших проверку письмах в другой.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

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

• SPF-запись для почтового сервера
  • Назначение
  • Основы протокола
  • Ограничения SPF
  • Примеры записей

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

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

Итак, переходим к 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:

Поэтому рекомендуемым вариантом является использование политики 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 не анализирует.

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

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

• Запись должна содержать как можно меньше вложений вида 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 ⁷. А у меня на этом все. Конечно я ещё не рассказал о макросах, но встречаются они достаточно редко, да и это уже совсем другая история.

Системы электронной почты крайне чувствительны к правильной настройке DNS и этот момент часто вызывает затруднения у начинающих администраторов. Еще больше вопросов возникает если почтовая система обслуживает сразу несколько доменов. Чтобы каждый раз не отвечать одно и тоже, а также чтобы окончательно расставить все на свои места мы решили написать эту небольшую статью. Надеемся, что после ее прочтения у вас не возникнет трудности с настройкой DNS-записей для мультидоменной системы электронной почты.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Что такое мультидоменная система электронной почты? Это почтовый сервер (или группа серверов), которые осуществляют прием и отправку почты сразу для нескольких доменов, которые могут быть как связаны, так и не связаны между собой. Например, вы можете на своем сервере разместить почту соседней организации, домен которой вам не пренадлежит, все что потребуется от ваших соседей — это правильно настроить DNS.

Где нужно делать эти настройки? На сервере имен, обслуживающем DNS-зону, это могут быть сервера регистратора, хостера, публичные или собственные. Будем считать, что вы знаете где это делается и как и не будем заострять на этом внимание.

Если вы не знаете где размещена зона, то выполните команду:

nslookup -type=ns example.com

где example.com — интересующий домен, в выводе вы получите сервера имен обслуживающие зону и по ним уже сможете определить, где и у кого она расположена.

В нашем примере мы будем рассматривать следующую схему:

В которой присутствую следующие домены:

• example.com — основной домен
• example.org — дополнительный домен
• example.net — дополнительный домен

Все эти домены обслуживает единственный почтовый сервер:

• mail.example.com — полностью определенное имя домена (FQDN) почтового сервера
• 198.51.100.25 — IP адрес почтового сервера

Несколько слов про основной домен, им считается тот домен, в котором расположен почтовый сервер. Понятие это сугубо условное, и вы можете разместить почтовый сервер в том домене, который вам больше нравится, либо который уже «исторически сложился» как основной для вашего предприятия. На работу почтовой системы это никак не повлияет, но настройки DNS-зоны для основного домена будут отличаться от настроек зон дополнительных доменов.

Настройка DNS-зоны основного домена

Далее мы будем касаться только записей, напрямую касающихся электронной почты. Первым делом создадим A-запись для сервера электронной почты, если вы не сделали этого ранее:

mail IN A 198.51.100.25

Обратите внимание, что мы указали относительное имя, поэтому оно автоматически будет дополнено суффиксом из названия доменной зоны, т.е. запись будет указывать на:

mail.example.com

Абсолютное DNS-имя всегда оканчивается на точку, в противном случае оно будет считаться относительным. Распространенная ошибка:

mail.example.com IN A 198.51.100.25

Такая запись на самом деле будет указывать на узел:

mail.example.com.example.com

Поэтому не занимайтесь лишней писаниной и везде, где можно указывать относительные имена используйте их, а абсолютные всегда завершайте точкой.

Следующим шагом добавим MX-запись, которая указывает какие именно сервера в данном домене отвечают за получение почты. Обратите внимание, что MX-запись относится именно к получению почты и не имеет никакого отношения к ее отправке. MX-записей может быть несколько, они отличаются приоритетом, чем больше число — тем ниже приоритет.

@ IN MX 10 mail

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

@ IN TXT "v=spf1 +a +mx ~all"
mail._domainkey TXT "v=DKIM1; k=rsa; p=<публичный ключ example.com>"
_dmarc TXT "v=DMARC1; p=none; rua=mailto:report@example.com"

Мы не будем подробно разбирать содержание этих записей, если коротко, то:

• SPF — позволяет указать узлы, которые имеют право отправлять почту от имени нашего домена, в данном случае это A-запись, MX-запись, остальные скорее всего такого права не имеют.
• DKIM — открытый ключ позволяющий проверить подлинность электронно-цифровой подписи письма
• DMARC — набор политик, определяющий правила проверки по SPF и DKIM и позволяющий получать отчеты о таких проверках со стороны получателя.

Более подробно все эти записи рассмотрены в нашей статье:

Настраиваем свой почтовый сервер. Что нужно знать. Ликбез

В целом вроде бы все, но есть одна тонкость, связанная с SPF, так как сервер у нас для всех доменов один, то нормальной практикой будет использовать для всех доменов один и тот-же набор SPF записей, через include или redirect, но как быть, если в основном домене появляется собственный отправитель, которого в других доменах быть не должно? Чтобы избежать таких ситуаций добавим еще одну SPF-запись, которая не будет использоваться в текущем домене, но на которую мы сможем ссылаться из доменов дополнительных:

_spf IN TXT "v=spf1 +a +mx ~all"

Теперь, если у нас, допустим появился новый узел, отправляющий почту box.example.com, то просто делаем так:

@ IN TXT "v=spf1 +a +a:box.example.com +mx ~all"
_spf IN TXT "v=spf1 +a +mx ~all"

На этом настройка DNS-зоны основного домена закончена. Если коротко, то вы должны добавить A-запись для узла почтового сервера, MX-запись, указывающую на почтовый сервер и SPF, DKIM и DMARC записи.

Настройка PTR-записи

Дочитав до конца предыдущего раздела, внимательный читатель мог воскликнуть: позвольте, как так закончена, а PTR? Так вот, PTR не имеет никакого отношения к настройке DNS-зоны основного домена. Скажем больше, технически эта запись никак не влияет на процессы отправки и получения почты, т.е. говоря проще — вообще не нужна, все будет прекрасно работать и без нее.

Обратите внимание, PTR-запись создается не для домена, а для конкретного узла-отправителя, которым в нашем случае является сервер mail.example.com и неважно сколько еще и каких доменов он обслуживает.

В общем виде PTR-запись должна выглядеть примерно так:

25.100.51.198 IN PTR mail.example.com.

Но, еще раз заостряем на это внимание, данную запись вносит ваш провайдер или хостер, не пытайтесь добавить ее самостоятельно в вашу DNS-зону, это не приведет к успеху (и является одной из самых частых ошибок).

Настройка DNS-зоны дополнительных доменов

Итак, у вас может быть сколько угодно дополнительных доменов, но настройка их DNS-зон будет идентичной. Собственного почтового сервера в этих зонах нет, поэтому мы сразу перейдем к созданию MX-записи, которая укажет какой именно узел принимает почту для этого домена:

@ IN MX 10 mail.example.com.

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

Если вы используете веб-доступ к почте и хотите, чтобы пользователи использовали адрес в собственном домене, например, mail.example.net, то добавьте еще одну запись псевдонима:

mail CNAME mail.example.com.

DKIM и DMARC записи в каждом дополнительном домене будут собственные:

mail._domainkey TXT "v=DKIM1; k=rsa; p=<публичный ключ example.net>"
_dmarc TXT "v=DMARC1; p=none; rua=mailto:report@example.net"

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

@ IN TXT "v=spf1 redirect=_spf.example.com"

Но как быть, если нужно добавить собственных отправителей? Тогда вместо перенаправления используем включение:

@ IN TXT "v=spf1 +a:shop.example.net include=_spf.example.com"

В этом случае к собственным записям будут добавлены записи из основной доменной зоны.

Больше никаких дополнительных записей в дополнительных зонах делать не нужно. Краткий итог: вы должны создать MX-запись, которая будет указывать на доменное имя реального почтового сервера, при желании CNAMЕ для используемых сервисов, наподобие веб-почты. DKIM и DMARK указываем собственные, а SPF подключаем от основного домена.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Если вы выполнили все шаги, описанные в предыдущей статье, ваш сайт на Drupal готов отправлять письма пользователям. Теперь необходимо сделать так, чтобы отправляемые сайтом уведомления и прочая корреспонденция попадали во “Входящие”, а не “Спам”. В этом материале мы рассмотрим варианты решения этой задачи. 100% результат, к сожалению, гарантировать невозможно, но уменьшить вероятность фильтрации ваших писем в нежелательную почту вполне реально.

Повысить доверие к вашим письмам и, соответственно, уменьшить шансы их попадания в “Спам”, можно с помощью:

• настройки PTR записи;
• настройки SPF записи;
• настройки DKIM.

Настройка PTR записи

PTR запись связывает IP адрес с доменом вашего сайта. DNS-серверы хранят так называемые А записи, по которым сопоставляется домен и IP адрес сервера, на котором расположен сайт. PTR запись обратна A записи: она показывает связку IP адреса и домена. Иногда PTR называют Reverse DNS.

В целях борьбы со спамом, почтовые сервисы в большинстве своём проверяют PTR у IP адреса сервера, с которого пришло письмо, а затем либо отправляют это письмо во «Входящее», либо фильтруют его в “Спам”. Соответственно, наличие этой записи и её совпадение с именем домена, который фигурирует в адресе отправителя, повышает доверие к приходящим с этого адреса письмам.

Зачем и как указывать PTR запись?

PTR запись указывается владельцем IP адреса сервера, с которого работает ваш сайт. Нужна та запись только в том случае, если вы используете VPS или выделенный сервер. На виртуальных хостингах PTR обычно есть и так, и указывает эта запись на имя сервера хостинг-провайдера.

Как посмотреть PTR запись?

Узнать PTR запись можно с помощью следующих команд:

nslookup -type=PTR ip-адрес

dig -x ip-адрес

Команды запускаются в терминале (командной строке); вместо “ip адрес” следует подставлять реальный IP.

Настройка SPF записи

SPF расшифровывается как Sender Policy Framework, что можно перевести как “инфраструктура политики отправителя”. Это расширение для протокола отправки электронной почты через SMTP, которое позволяет добавить DNS записи типа TXT к доменному имени и указать в этих записях IP адреса серверов, с которых разрешена отправка электронной почты.

SPF используется как фактор повышения доверия к исходящей от домена почте и в целях снижения вероятности попадания писем в “Спам”. Репутация домена, которую SPF позволяет защитить, также имеет не последнее значение: при рассылке спама или фишинговых писем, злоумышленники могут подставить в поле “От” любой адрес в любом домене, что может стать причиной проблем для владельца такого домена. IP адрес почтового сервера, с другой стороны, подделать невозможно, поэтому когда SPF запись для домена есть, принимающая сторона (почтовая служба) проверяет её и действует соответственно.

Как создать SPF запись?

SPF запись — текст с определённым синтаксисом. Пример SPF записи:

"v=spf1 +a +mx -all"

В записи указано, что следует принимать почту с IP адресов, которые указаны в DNS записях типа A и MX для домена, сопровождаемого этой записью. Если же адреса иные, почту лучше отклонить. Запись может быть немного короче: «v=spf1 a mx -all», её суть и функциональность от этого не меняются.

Синтаксис SPF записи

«v=spf1» — используемая версия SPF.

«+» — принимать почту. Этот знак не является обязательным.

«-« — отклонять почту.

«~» — принимать почту, но фильтровать её в “Спам”.

«?» — воспринимать письмо нейтрально, то есть применять к нему обычные правила.

«mx» — IP адреса всех серверов, указанных в DNS записях типа MX для домена.

«ip4» — здесь можно указать конкретные IPv4 адреса.

«ip6» — здесь можно указать конкретные IPv6 адреса.

«a» — IP адреса, которые указаны в DNS записях типа A для домена.

«include» — разрешает применение SPF другого домена.

«all» — устанавливает правила для всех других доменов, которых нет в SPF записи.

Пример SPF записи

Рассмотрим такую SPF запись:

"v=spf1 mx a ip4:123.45.125.94 a:example.com mx:example.com include:example.com ~all" 

mx — принимать почту со своих почтовых серверов.

a — принимать почту с серверов, которые указаны в записях типа A для своего домена.

ip4:123.45.125.94— принимать почту, отправленную с IP 123.45.125.94. Здесь можно указывать подсети в формате 123.45.125.0/24.

a:example.com — принимать почту с серверов, которые указаны в записях типа A для домена example.com. Здесь подсети можно указать в формате example.com/24.

mx:example.com — принимать почту с почтовых серверов, указанных в записях типа MX для домена example.com. Подсети можно указывать, как и в a:example.com.

include:example.com — разрешение на получение почты по правилам, указанным в SPF домена example.com.

~all — вся почта с доменов, не указанных в SPF, будет направляться в “Спам”. Если тильду заменить на минус (-all), такая корреспонденция вообще не будет приниматься.