Генератор записей ptr и обратный поиск IP-адресов

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

Что такое PTR-запись

Если в двух словах, то PTR-запись (или, как ее иногда называют, Pointer) — противоположность A-записи для DNS. Но давайте обо всем по порядку. 

A-запись показывает взаимосвязь между адресом и названием. Указывает на то, какой IP скрывается за доменным именем. PTR-запись нужна для обратного. Она показывает доменное имя для указанного адреса. 

Как выглядит Pointer?

PTR-запись имеет следующий формат:

Название arpa идет от ARPANET. Это предок нынешнего интернета.

Так выглядит PTR-запись при попытке запустить утилиты для поиска DNS.

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Зачем она нужна?

Анти-спам фильтры

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

Исправление проблем с доставкой писем

Устранение ошибок при авторизации

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

У меня на VDS обратная зона была прописана по умолчанию. Ничего добавлять и вписывать руками не пришлось. 

Добавляем PTR-запись на примере ISPManager

Если обратная зона в панели управления Timeweb не указана, то надо:

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

Можно ли добавить несколько Pointer’ов?

Как делается обратный IP-поиск

Есть whois-сервисы, в которые можно ввести IP-адрес и получить в ответ доменное имя. Или наоборот. 

Для этого:

• Открываем сайт Who Is Hosting This?
• Вводим IP-адрес в поисковую строку на главной странице сайта.
• Нажимаем на кнопку Search.

Через несколько секунд на странице появится доменное имя ресурса.

Если Who Is Hosting This? выдаст ошибку или не покажет корректной записи, значит, Pointer настроен неправильно или не настроен вообще. Поэтому будут проблемы с отправкой писем.

Проверяем Pointer через nslookup или dig

Обратный поиск DNS можно провести через командную строку. Для этого есть специальные утилиты в Windows, Linux и macOS.

В Windows

Чтобы проверить DNS в операционной системе Microsoft:

1. Кликаем по встроенному поисковику в панели управления.
2. Вводим название программы – «Командная строка».
3. Запускаем ее от имени администратора.
4. Вводим команду nslookup с аргументами -type=PTR IP-адрес, домен которого нужно отследить.

Получится что-то в таком духе: nslookup -type=PTR 17.172.224.47

В ответ будет получена запись наподобие такой:

47.224.172.17.in-addr.arpa. 3600 IN PTR apple.com. 47.224.172.17.in-addr.arpa. 3600 IN PTR appleid.org. 47.224.172.17.in-addr.arpa. 3600 IN PTR apple.by. 47.224.172.17.in-addr.arpa. 3600 IN PTR expertapple.com. 47.224.172.17.in-addr.arpa. 3600 IN PTR developercentral.com. 47.224.172.17.in-addr.arpa. 3600 IN PTR darwincode.com. 47.224.172.17.in-addr.arpa. 3600 IN PTR carbontest.com. 47.224.172.17.in-addr.arpa. 3600 IN PTR carbondating.com. 47.224.172.17.in-addr.arpa. 3600 IN PTR carbonapi.com. 47.224.172.17.in-addr.arpa. 3600 IN PTR appleiphone.com.

Это и есть PTR-записи. В моем случае, принадлежащие компании Apple.

В macOS и Linux

Чтобы проверить DNS в операционной системе macOS:

1. Запускаем встроенный в систему поисковик, кликнув по соответствующей иконке.
2. Вводим туда название программы «Терминал» и запускаем ее.
3. Запускаем команду dig с атрибутами -x IP-адрес, домен которого нужно отследить

Команда будет выглядеть как-то так: dig -x 17.172.224.47

В ответ получим список PTR-записей. С доменами и адресами.

SPF (Sender Policy Framework) — это DNS-запись, содержащая список доверенных серверов, с которых может отправляться почта данного домена, и сведения о механизме обработки писем, отправленных с других серверов. Корректная настройка SPF позволит снизить вероятность рассылки спама злоумышленниками от вашего имени.

В панели Timeweb SPF настраивается в разделе «Домены» — «Мои домены» — «Настройки DNS» — «Добавить DNS запись» — «TXT».

Если TXT-запись с параметрами SPF уже создана, необходимо ее отредактировать. Не рекомендуется создавать несколько SPF-записей для домена, так как это может вызывать проблемы с доставкой почты. 

SPF-запись Timeweb выглядит следующим образом: 

v=spf1 include:_spf.timeweb.ru ~all

Основной синтаксис

Любая SPF-запись начинается с v=spf1, этот параметр не изменяется. Он указывает на версию записи, и в настоящее время поддерживается только spf1. 

Далее указываются параметры (механизмы). Чаще всего используются следующие: allip4ip6amxincluderedirect. Также существуют, но используются значительно реже: ptrexistsexp. Они все будут рассмотрены ниже.

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

• + — Pass, принимать почту. Прописывать этот параметр необязательно, он установлен по умолчанию (т.е. значения «+a +mx» и «a mx» — идентичны).
• — — Fail, отклонять почту.
• ~ — SoftFail, «мягко» отклонять (принимать почту, но помещать ее в «Спам»). 
• ? — нейтрально (обрабатывать как обычное письмо).

all

Параметр «all» подразумевает все серверы, не упомянутые отдельно в SPF-записи. «All» задает обработку полученных с них писем и указывается в конце записи. 

v=spf1 ip4:176.57.223.0/24 ~all

— принимать почту только из подсети 176.57.223.0/24; письма с других адресов должны быть помечены как спам.

v=spf1 a -all

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

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

В последующих примерах мы не будем дополнительно комментировать значения параметров ~all-all

ip4 / ip6

Используется для указания конкретных адресов и подсетей, из которых могут отправляться письма. Синтаксис для IPv4 и IPv6 идентичен.

v=spf1 ip4:176.57.223.0/24 ~all

— принимать почту из подсети 176.57.223.0/24.

v=spf1 ip6:2001:db8::10 ~all

— принимать почту с IPv6-адреса 2001:db8::10.

a

IP отправителя проверяется на соответствие A-записи домена. 

v=spf1 a ~all

— принимать почту с A-записи текущего домена.

v=spf1 a:sub.domain.com ~all

— принимать почту с A-записи домена sub.domain.com.

mx

v=spf1 mx mx:sub.domain.com -all

— принимать почту с MX-серверов текущего домена и домена sub.domain.com.

v=spf1 mx/24 -all

— принимать почту из подсети, в которую входят MX-серверы текущего домена.

include

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

v=spf1 a include:other-domain.com -all

— принимать почту с A-записи текущего домена и серверов, указанных в SPF-записи домена other-domain.com. 

При такой настройке проверяется SPF домена other-domain.com; если это, допустим, «v=spf1 a -all», то далее IP отправителя проверяется на соответствие A-записи домена other-domain.com.

redirect

Технически, redirect является модификатором, а не механизмом. Он выполняет одну основную функцию: сообщает, что необходимо применять настройки SPF другого домена.

— почта должна приниматься или отклоняться согласно настройкам домена other-domain.com.

Прочие механизмы

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

ptr

v=spf1 ptr:other-domain.com -all

— принимать почту со всех адресов, PTR-запись которых направлена на домен other-domain.com 

exists

v=spf1 exists:mydomain.com -all

— принимать почту, если существует A-запись домена mydomain.com. 

exp

Параметр «exp» применяется для отправки сообщения об ошибке отправителю письма. С помощью «exp» в SPF прописывается определенный поддомен, в TXT-записи которого указан текст сообщения об ошибке. Имя поддомена и текст ошибки может быть любым.

Параметр «exp» всегда указывается в конце записи (после all). 

v=spf1 mx -all exp=error-spf.mydomain.com

При этом TXT-запись домена error-spf.mydomain.com содержит: «Not authorized to send mail for this domain».

Примеры настроек

Настройка SPF для «Почты для доменов» от Mail.Ru

(подробнее о настройке DNS для Mail.ru см.

Если вы отправляете почту только с серверов Mail.Ru: 

v=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.mail.ru ~all

Настройка SPF для Яндекс.Почты

(подробнее о настройке DNS для Яндекса см.

При использовании только серверов Яндекса:

v=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.yandex.net ~all

Настройка SPF для Google

(подробнее о настройке DNS для Google см.

При использовании только серверов Google:

v=spf1 include:_spf.google.com ~all

v=spf1 ip4:IP1 ip4:IP2 include:_spf.google.com ~all

Другие примеры

v=spf1 a ip4:176.57.223.12 include:domain2.com -all

v=spf1 mx/24 a:domain2.com/24 ~all

— принимать почту из подсети, в которую входят MX-серверы текущего домена, и из подсети, в которую входят A-записи домена domain2.com; прочие письма помещать в спам.

Видеоинструкция

• 00:00​ | Зачем нужна SPF-запись?
• 00:50​ | Что происходит с письмом после отправки?
• 2:44​ | Настраиваем бесплатный домен и почту
• 5:18​ | Где редактировать почтовые записи. Виды записей
• 6:50​ | Проверяем письмо на подозрительность
• 8:06​ | Как уберечь свою почту от спама?

Я расскажу, какими способами можно проверить каждый тип DNS-записи.

Типы DNS-записей

Функции ресурсных записей – это не только хранение, передача информации и привязка к IP адресу. Они также помогают настроить обработку запросов, перенаправляют их на другие серверы. Вот несколько наиболее важных типов DNS-записей:

2. AAAA – аналогична предыдущей, только действительна на основе интернет-протокола IPv6.
3. CNAME – данный тип записи указывает на каноническое имя для псевдонима. С ее помощью к одному поддомену привязываются все ресурсные записи домена первого уровня.
4. DKIM-подпись – подтверждает подлинность отправителя электронного письма. Именно эта ресурсная запись добавляет в сообщение цифровую подпись. Тем самым снижается вероятность попадания письма в папку «Спам».
5. MX – регистрирует почтовые серверы, используя при этом протокол SMTP. Отвечает за доставку электронного письма на указанный сервер.
6. NS – указывает на DNS-серверы, которые обслуживают домен. Чуть ли не одна из самых важных записей, без которой функционирование домена дало бы сбой.
8. SOA – используется для указания на новую зону и авторитетность указанной в ней информации.
9. SPF – защищает домен от подделки, показывает список доверенных серверов, с которых отправляются электронные письма. Это нужно для того, чтобы предотвратить рассылку спама от вашего доменного имени.
10. SRV – хранит данные о местоположении серверов, обеспечивающих работу тех или иных служб.
11. TXT – содержит общую вспомогательную информацию о домене, используется для указания SPF-записей, подтверждения прав собственности, обеспечения безопасности электронной почты и так далее. 

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Способы проверки DNS-записей домена

А зачем проверять DNS-записи? Ошибки, допущенные в ресурсных записях, приводят к нарушению работоспособности сайта. Даже после внесения всех правок полноценный доступ к сайту появится не сразу, так как изменения, внесенные в ресурсные записи, вступают в силу в течение 72 часов.

Есть множество способов, позволяющих проверить DNS-записи. Можно воспользоваться как специальными командами в системе, так и онлайн-сервисами.

Встроенные в систему службы

nslookup -type=тип_записи site.com

• host. Эта утилита используется в ОС Linux. Она есть в стандартном пакете командной строки «Терминал». С ее помощью можно проверить все виды запросов к DNS-серверу. Вводится команда вот таким образом:

host site.com

Можно перед доменным именем добавить опцию -t и указать тип записи для получения более подробного поиска. Выглядеть это будет примерно вот так:

host -t A site.comhost -t MX site.com

Проверка DNS-записей с помощью сторонних сервисов

Еще можно воспользоваться бесплатными онлайн-сервисами для проверки DNS записей.

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

•  – здесь тоже очень удобно проверять настройки DNS-записей самых различных типов. Сервис дает полную информацию, а еще предоставляет PHP документацию на разных языках.

•  – сервис поможет определить, попадет ли письмо, отправленное с вашего сервера, в «Спам». Еще здесь можно определить ошибки в ссылках и проверить качество форматирования писем.

• xseo.in/dns – на данном ресурсе есть раздел для проверки самых разных DNS записей. 

Заключение

Каждая из предложенных утилит имеет свою особенность. К примеру, некоторые проверяют не все записи, другие же предоставляют более полную информацию о каждом типе. Выбор остается за вами.

apt-get install python-ipaddr python-dnspython bind9utils

Set your forward and reverse zones. All zonefiles have to exist already,
this script does not (yet) create reverse zonefiles from scratch, it only
updates them. -c [file] Configuration file location (default: ./dnsrev.conf). -h This help info. -n Dry run. -d Show diffs of changes. -s Do not update SOA serial number.
The configuration file should define two lists of tuples like this:
FWD_ZONES = [("db.example.net", "example.net"), ...]
REV_ZONES = [("db.example.net.rev4", "192.0.32.0/24"), ("db.example.net.rev6", "2620:0:2d0:200::/64"), ...]
The first column is the name of the zonefile. The second column is the
domain name in FWD_ZONES, and the ASCII-formatted subnet (including
netmask) in REV_ZONES.
You can list as many forward and reverse zones as you want. There doesn't
have to be any kind of 1:1 relationship between any of them.

Необходимые настройки для беспроблемной доставки доменной почты

25 января 2020

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

Для нормальной доставки доменной почты необходимо корректно настроить:

• PTR
• SPF
• Заголовок Return-Path

Также для защиты от несанкционированного использования Вашего домена можно настроить:

• DKIM
• ADSP
• DMARC

Что это за непонятные штуковины и как их настроить, опишу ниже.

PTR (обратная dns запись)

У любого домена в dns есть A записи, которые связывают домен с IP сервера, на котором находится сам сайт. А PTR запись делает то же самое, но наоборот, связывает IP сервера с доменом.

PTR запись очень важна для почтовиков. Когда на почтовый сервер приходит письмо, он берет IP, откуда пришло письмо, затем смотрит значение этой записи. Если значение этой записи совпадает с именем сервера, откуда пришло письмо, то почтовик пропускает письмо. Если не совпадает, то в большинстве случаев кидает в спам или вообще не пропускает. Также высока вероятность бана IP сервера Gmail’ом, если записи нет или она некорректно настроена (даже при корректной настройке остальных параметров).

Где настроить PTR запись?

На нормальных обычных хостингах PTR уже настроен, ничего делать не нужно. Если же у Вас виртуальный или физический сервер, то, как правило, нужно самому прописывать эту запись в панели управления сервером. Название поля для PTR может быть разным — ptr, reverse dns, имя сервера и т.д. Также в имени сервера (в самой ОС) должен быть указан этот домен (Linux — /etc/hostname, FreeBSD- /etc/rc.conf).

Что указывать в PTR записи, если на сервере несколько доменов?

Если на сервере хостится несколько доменов, то нужно взять один из них и прописать его в имени сервера и в PTR записи.

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

PTR можно проверить на соответствующих сервисах, например, тут. Также можно проверить консольными утилитами, например, dig:

 dig -x 123.123.123.123 +short

Команда выше выведет значение PTR записи.

SPF

SPF (Sender Policy Framework) — это ещё одна важная запись. Необходима для того, чтобы указать почтовым серверам, с каких ресурсов будут приходить письма, т.е. верификация источника. Сама запись практически никак не влияет на несанкционированное использование домена, она больше нужна как требование большинства принимающих почтовых серверов. Также, если если нет этой записи или она некорректно настроена, то отправляемые письма скорее всего попадут в спам или будут отмечены как поддельные:

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

SPF запись прописывается в dns записях домена и представляет собой TXT запись в DNS, например:

В начале записи должна быть указана версия SPF записи v=spf1. Рекомендуется использовать только эту версию.

Затем через пробел идут источники. Они могут быть следующими:

• Обычные IP адреса / подсети адресов с префиксами ip4: (для IPv4 адресов) и ip6: (для IPv6 адресов). Например, ip4:123.123.123.123. Могут использоваться в записи несколько раз. Это предпочтительный тип источника, и они не создают дополнительные DNS запросы;
• Ссылки на другие записи в DNS домена / других доменов. Например, a, mx. Такой тип не рекомендуется, т.к. значения неявные, и создаются дополнительные запросы к DNS;
• Подключение внешних валидных SPF записей через include:. Например, include:somedomain.com. Обычно такой тип используется, чтобы подключить в основную запись записи удаленного почтового сервиса или сервиса рассылки. Каждое такое подключение создает от одного дополнительного запроса в DNS, в зависимости от того, сколько подключений идет внутри. Поэтому не стоит этим злоупотреблять.

Также возможны еще более сложные вариации источников, но не буду их описывать, т.к. в большинстве случаев они не требуются. Подробнее можно узнать в RFC 7208.

Обратите внимание на то, что в SPF допускается до 10 дополнительных запросов в DNS. Если будет больше, то запись будет невалидной. Проверить вложенность и колличество DNS запросов в SPF записи можно здесь.

В конце записи указывается политика для неуказанных в записи источников и может быть:

• -all (hardfail) — отклонять (не рекомендуется, т.к. в некоторых случаях может только навредить доставке писем);
• ~all (softfail) — не следует отклонять, но обратить внимание (рекомендуется);
• ?all — относиться нейтрально (не рекомендуется);
• all или +all — принимать (не рекомендуется).

Иногда возможны случаи, когда нужно полностью взять всю SPF запись с другого домена. Для этого существует redirect=. Например, redirect=domain.com. В этом случае больше никакие записи не указываются, в т.ч. и all.

Еще обратите внимание на то, что, если сервер и MTA (exim4, sendmail и т.д.) умеют работать по IPv6 и указан только IPv4, то IPv6 тоже нужно указать в SPF записи, т.к. на некоторые почтовые сервера письма будут уходить через IPv6.

Давайте приведу простой пример. У нас есть сайт на сервере с IP 123.123.123.123, подключена доменная почта на том же сервере, плюс ко всему используем сервис рассылки responder.com, с которого идет рассылка от Вашей доменной почты. Такие сервисы обычно предоставляют адрес, который нужно добавить в SPF запись. Например это будет spf.responder.com. SPF запись получится такой:

v=spf1 ip4:123.123.123.123 include:spf.responder.com ~all

SPF запись для одного домена должна быть только одна и она не распространяется на поддомены. Для поддоменов должна быть отдельная SPF запись.

Как проверить SPF?

SPF можно проверить в заголовках исходника письма. Заголовки письма можно посмотреть на большинстве почтовых программ и веб-версий почтовиков.

Пример удачной проверки:

Authentication-Results: mxfront10o.mail.yandex.net; spf=pass (mxfront10o.mail.yandex.net: domain of domain.com designates 123.123.123.123 as permitted sender, rule=[ip4:123.123.123.123]) smtp.mail=info@domain.com

Пример неудачной проверки:

Authentication-Results: mxfront12g.mail.yandex.net; spf=softfail (mxfront12g.mail.yandex.net: transitioning domain of domain.com does not designate 123.123.123.123 as permitted sender, rule=[~all])

Валидность SPF записи можно проверить вот здесь.

DKIM

DKIM (DomainKeys Identified Mail) — это цифровая подпись писем. Она гарантирует, что письмо отправлено именно от того домена, который указан в email отправителя.

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

Как настроить DKIM?

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

Если же у Вас виртуальный или физический сервер, то DKIM необходимо настраивать самостоятельно. На стороне сервера Вам необходим приватный ключ для подписи писем и публичный ключ для DNS. Эти ключи генерируются самостоятельно, либо выдаются почтовыми сервисами или сервисами рассылки. Также нужно включить подпись писем в MTA (отправщике писем) на сервере.

После того, как подписывание писем на стороне сервера настроено, необходимо создать TXT запись в DNS вида:

В поле хоста должен быть указан селектор и ._domainkey на конце. Например, mail._domainkey.

Важно: селектор в DNS записи должен соответствовать селектору DKIM подписи.

В значении записи указываем через точку с запятой:

• v — версия DKIM (всегда v=DKIM1);
• k — алгоритм шифрования (всегда k=rsa);
• p — публичный ключ (p=публичный_ключ).

• t=y — режим тестирования;
• t=s — использование записи только для домена, для поддоменов запись использоваться не будет;
• h — предпочитаемый hash-алгоритм, может быть h=sha1 и h=sha256;
• s — тип сервиса, использующего DKIM, может быть s=email (электронная почта) и s=* (все сервисы, по умолчанию).

Как проверить DKIM?

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

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=domain.com; h=date :from:to:message-id:subject:mime-version:content-type; s= dc-smart1; bh=sM8mwMa+DhlFNAT/Q85vxxnJ9PAemdLfkhxQbVXajbs=; b=NG MBJ9qrrJSyCqQ9p8nFkBBDK+86d/QKOYAsQbL3V6fVdwqtJwyKAq2LNlmSagSQwp 1yBEeS88rtA6aVSoRg4pyJ/vwFYaP8LYqD8DfL5dXSzUFyEqPAgmI08qmBafPFrC jhDVyKDbJrpCIo2i6HJ8to3gcArB2GGxdXTMM/th0=

Корректность связки подписи и публичного ключа можно можно так же увидеть в заголовках письма:

Authentication-Results: mx.google.com; ... ; dkim=pass header.i=@domain.com

Если проверка DKIM не пройдет, то увидим dkim=fail.

Как прописать в DNS несколько DKIM ключей?

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

ADSP

ADSP (Author Domain Signing Practices) — политика, которая позволяет сообщать принимающим почтовым серверам, что делать с письмом пришедшим с нашего домена, но не имеющее подписи. Если этой записи нет, то принимающий почтовый сервер следует своим политикам обработки писем. Эту запись нужно указывать после настройки DKIM.

ADSP запись признана устаревшей и не нужна при использовании DMARC.

Как прописать ADSP запись?

ADSP запись прописывается в TXT записи в DNS записях домена:

• all — все письма должны быть подписаны (рекомендуется);
• discardable — отклонять все неподписанные письма (не рекомендуется, т.к. в некоторых случаях может навредить);
• unknown — аналогично отсутствию записи (бесполезное значение).

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) — ещё одна политика обработки писем для почтовых серверов. Она задает политику проверки приходящей доменной почты и указывает, что делать, если письма не проходят проверку SPF или DKIM. Для этой записи необходимо предварительно настроить SPF и DKIM. Если DMARC записи нет, то принимающий почтовый сервер следует своим политикам обработки писем.

Как настроить DMARC?

DMARC — это обычная TXT запись. Прописывается в DNS домена:

Основные параметры записи:

v — версия записи, должно быть DMARC1 (наличие обязательно).

p (policy) — политика домена, может быть:

• none — не принимать никаких особых действий, всё на усмотрение почтовика;
• quarantine — отправить в спам;
• reject — не принимать письмо.

sp (subdomain policy) — политика поддоменов, может принимать те же значения, что и p (policy).

pct (percentage) — процент писем, которые подвергаются политикам. Например, при политике v=DMARC1; p=quarantine; pct=50; половина писем не прошедших аутентификацию пойдет в спам. По умолчанию pct=100.

Остальные параметры можно посмотреть в RFC 7489.

Что же указать в DMARC?

Если же Вы на 100% уверены, что все Ваши письма проходят проверку DKIM и SPF, то можете использовать quarantine или reject, при этом поднимая процент обрабатываемых писем через параметр pct.

Заголовок Return-Path

По сути этот заголовок нужен для указании адреса, куда будут отсылаться сообщения об ошибках доставки. Но этот заголовок так же важен для отправляемых писем, т.к., если он не передан или в нем передана почта с другим доменом, то отправляемые письма скорее всего попадут в спам или будут отмечены как поддельные (аналогично некорректной SPF записи):

Сам заголовок должен быть передан сайтом/приложением и содержать в адресе тот же домен, что и в заголовке From.

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

• В первую очередь проверьте/настройте PTR запись, пропишите корректную SPF запись и проверьте наличие корректного заголовка Return-Path в отправляемых письмах. Этого будет достаточно для нормальной отправки писем.
• Не помешает еще проверить наличие IP адреса сервера, откуда идет почта, в спамлистах, например, здесь. Если же Вы обнаружили, что IP в спамлистах, то желательно его сменить. Обычно на хостингах это решается покупкой выделенного IP, на виртуальных серверах пересозданием сервера, на физических серверах сменой сервера или покупкой дополнительного IP адреса.
• Для дополнительной защиты от несанкционированного использования Вашего домена корректно настройте DKIM, ADSP и DMARC.
• Не отправляйте слишком большие письма. Заголовки письма тоже учитаваются. Можно упереться в лимит размера.
• Не отправляйте письмо большому количеству получателей. Можно так же упереться в лимиты.
• В письме не должно быть очень длинных строк. Можно упереться в лимиты длины строки (да, такое тоже бывает).
• Следите за контентом самих писем, чтобы у получателей не было желания, отправить их в спам.
• Не занимайтесь рассылкой писем с Вашего хостинга/сервера. Для этого существуют грамотно настроенные сервисы рассылки.
• Если Вы не занимаетесь рассылкой, но частота отправки писем очень большая, то шлите почту через сервисы рассылки. Иначе принимающие почтовые серверы могут временно ограничить прием писем от Вашей доменной почты.

Полезные ссылки

• mxtoolbox.com — сервис проверки различных параметров настройки почты. На этом сервисе можно добавить свой домен для мониторинга параметров, на почту будут регулярно приходить отчеты;
• easydmarc.com — еще один сервис с утилитами для проверки;
• mail-tester.com — сервис проверки качества писем и корректности параметров. Отправляете на указанный адрес письмо — получаете развернутую информацию о письме.

27 февраля 2020

• Что такое DNS
  

• Принцип работы DNS
  

• Структура DNS записей
  

• Основные типы DNS записей
  

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

Что такое DNS

Во времена зарождения интернета к различным ресурсам обращались по IP адресу. Внедрение доменных имен позволило обращаться к ресурсам по удобному и запоминающемуся имени. Именно это стало возможно благодаря DNS.

DNS (Domain Name System) — система для получения информации о доменах. Чаще всего DNS используется для получения IP адреса по имени домена, чтобы указать на какой сервер ссылаться при обращении к домену.

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

Принцип работы DNS

Базу данных DNS можно сравнить с контактами на мобильнике. Только вместо имен там прописаны домены сайтов, а вместо номеров — IP адреса.

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

Аналогичным образом идут запросы любой другой информации о доменах.

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

Структура DNS записей

DNS записи могут состоять из следующих полей:

• Хост, к которому относится запись. Это может быть сам домен (site.com.) либо поддомен (subdomain.site.com.). Адрес должен быть с точкой на конце. В большинстве DNS редакторов для упрощения вместо домена указывается @, а вместо поддомена только имя поддомена (subdomain). Также можно использовать звездочку (*) для указания значения для всех поддоменов домена. Если имеется такая запись и такого же типа конкретно для отдельного поддомена, то приоритет будет у записи для конкретного поддомена. Например, если Вы хотите, чтобы все поддомены ссылались на один IP адрес, а конкретно какой-то домен на другой IP адрес.
• Тип записи — A / TXT / CNAME и т.д.
• Приоритет (MX preference) — приоритет MX записи.
• Значение записи.
• TTL (Time To Live) — время жизни кэша записи в секундах.

Основные типы DNS записей

Ниже опишу основные типы частоиспользуемых записей DNS. Остальные типы записей можно посмотреть на странице в Википедии. В примерах буду использовать упрощенную запись поля хоста.

Важно: если для поддомена создана отдельная зона DNS, то записи для этого поддомена в зоне основного домена будут проигнорированы.

NS-запись (Authoritative name server) необходима для указания DNS-сервера / DNS-серверов, которые будут отвечать за доменную зону (делегирование домена). Именно эта запись необходима для функционирования механизма DNS. Обычно у регистраторов и хостингов она находится отдельно от остальных записей домена.

Чаще всего хостинги и DNS-провайдеры предоставляется несколько равнозначных серверов DNS-серверов, чтобы записи были актуальны при выходе из строя одного из них. Желательно прописать их все.

A-запись (Address) необходима, чтобы прописать IP адрес сервера, к которому нужно привязать домен или поддомен.

У нас есть домен domain.com и место на хостинге с IP адресом 123.123.123.123. Нам нужно привязать наш домен к этому IP адресу. Для этого в зоне DNS домена domain.com добавляем запись с таким содержимым:

• хост — @;
• тип записи — A;
• значение записи — 123.123.123.123.

У нас есть домен domain.com, поддомен sub.domain.com и место на хостинге с IP адресом 123.123.123.123. Нам нужно привязать поддомен sub.domain.com к этому IP адресу. Для этого в зоне DNS домена domain.com добавляем запись с таким содержимым:

• хост — subdomain;
• тип записи — A;
• значение записи — 123.123.123.123.

У нас есть домен domain.com, поддомены sub1.domain.com, sub2.domain.com, sub3.domain.com, место на хостинге с IP адресом 123.123.123.123 и место на на другом хостинге с другим IP адресом 111.222.111.222 для третьего поддомена. Нам нужно привязать первые два поддомена к первому IP адресу, а третий поддомен ко второму IP адресу. При этом планируется добавление дополнительных поддоменов и привязка их к первому IP адресу, но добавлять каждый поддомен в DNS не хочется. Для этого в зоне DNS домена domain.com прописываем 2 записи:

• хост — *;
• тип записи — A;
• значение записи — 123.123.123.123.

• хост — subdomain3;
• тип записи — A;
• значение записи — 111.222.111.222.

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

Запись состоит из двух частей:

• адрес почтового сервера;
• приоритет (MX preference). Чем меньше число, тем запись выше в приоритете. Если указана только одна запись, то любое произвольное число (по-умолчанию — 10).

Нам нужно, чтобы доменной почтой основного домена управлял почтовый сервер mx.mail.com. Добавляем следующую запись в зону нашего домена:

• хост — @;
• тип записи — MX;
• значение записи — mx.mail.com;
• приоритет — 10.

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

TXT-запись (Text string) — это универсальная запись для указания различной текстовой информации, для которых нет отдельных типов DNS записей. Например, SPF, DKIM, подтверждение владением домена на различных ресурсах и т.д.

Подробнее о настройке текстовых записей SPF, DKIM, DMARC, ADSP можно прочитать в соседней статье.

CNAME-запись (Canonical name) позволяет сделать для поддомена ссылку на любой другой домен. Запись полезна, когда Вы хотите, чтобы для определенного поддомена были актуальны все записи от основного, либо чтобы при переходе на поддомен отображалось содержимое другого ресурса (например, интерфейс стороннего почтового сервиса на поддомене mail Вашего домена).

Важно: в значении записи точка на конце адреса обязательна, но некоторые панели ставят ее автоматически.

У нас есть основной домен domain.com и поддомен ru.domain.com. Нам необходимо, чтобы все записи основного домена были актуальны для поддомена. Создаем запись в зоне домена domain.com со следующими параметрами:

• хост — ru;
• тип записи — CNAME;
• значение записи — domain.com. (точка на конце обязательна).

У нас есть домен mydomain.com. Нам необходимо на поддомене mail.mydomain.com открывать веб-интерфейс почтового сервиса нашей доменной почты mydomain.mail.com. Создаем запись в зоне домена mydomain.com со следующими параметрами:

• хост — mail;
• тип записи — CNAME;
• значение записи — mydomain.mail.com. (точка на конце обязательна).

Важно: если для поддомена задана CNAME запись, то больше никаких записей не должно быть для этого поддомена.

PTR-запись (pointer) предназначена для обратного преобразования IP в доменное имя. Сама запись прописывается не в DNS домена, а на той стороне, кто выдает Вам IP адрес (хостинг). Подробнее о записи и ее настройке можно почитать в этом посте.

TTL

TTL (Time To Live) в DNS — время жизни кэша записи в секундах на каждом промежуточном DNS-сервере. Например, если значение TTL составляет 3600 секунд (1 час), а цепочка DNS-серверов до Вас состоит из 5 звеньев, полное распространение изменений должно занять не более 18 000 секунд (5 часов).

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

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

Какое значение указать в TTL

В современном мире рекомендую ставить TTL от 10 до 3600 секунд (1 час). В идеале считаю нормальными значения от 300 (5 минут) до 600 секунд (10 минут). Такие значения не создадут сильную нагрузку на промежуточные DNS-сервера и позволят сократить время обновления DNS в экстренных случаях. С другой стороны большие значения TTL теоретически будут полезны при временном отказе промежуточных серверов или при их DDOS’е. Большие значения актуальны только для тех записей, значения которых точно никогда не изменятся.

При добавлении новых записей в DNS домена лучше устанавливать низкое значение TTL. Если все ок, то можно повысить. Либо сразу ставить нормальное значение, если Вы на 100% уверены, что запись корректная.

Если планируются какие-то изменения в DNS, например, переезд сайта на другой сервер/хостинг, то TTL необходимых записей желательно уменьшить до минимальных значений за несколько дней. А после смены и нормальной работы можно будет увеличить обратно.

Делегирование домена

Делегирование домена — это передача прав на управление записями домена (доменной зоной).

Делегирование домена доступно сразу после покупки домена у регистратора. Большинство регистраторов помимо делегирования поддерживают управление DNS записями домена. Часть из них предоставляют это как отдельную услугу, а некоторые предоставляют это только при использовании их услуг, например, хостинга. Изначально домен делегирован на DNS-сервера регистратора и припаркован к их стандартной странице.

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

Как делегировать домен

Рассмотрим простой пример. Вы купили домен, но хотите управлять записями домена на хостинге hosting.com. Для этого необходимо узнать у хостинга адреса их DNS-серверов. Обычно эти адреса указаны в панели хостинга или в документации хостинга. К примеру, адреса могут быть такими:

• ns1.hosting.com.
• ns2.hosting.com.

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

Куда лучше делегировать домен

Часто слышу этот вопрос, но четкого ответа на него нет. Все зависит от Ваших предпочтений, удобства панелей, функционала редактора DNS записей, количества регистраторов и хостингов. Если у Вас хостинг является и регистратором, то ответ очевиден. Никуда делегировать не нужно. Если же у Вас много хостингов и доменов, зарегистрированных у разных регистраторов, то логичнее их все делегировать в одно место, чтобы не запутаться и чтобы было удобнее управлять ими и редактировать в одном месте (например, Яндекс.Коннект).

В общем, делегируйте туда, где Вам удобнее управлять DNS записями, но не забывайте, что излишнее переделегирование может потом встать боком, если какое-то звено из этой цепочки выпадет, а информация о домене уйдет в никуда. Часто встречался с таким, что домен изначально был делегирован на один хостинг. Затем сайт переехал на другой. При этом делегирование было сделано со старого хостинга на новый. При истечении баланса на старом хостинге или при закрытии учетки услуга управления DNS закрывалась, а все DNS записи удалялись, в том числе и NS, где были прописаны NS записи нового хостинга. Результат — простой сайта, поиск причины и ожидание смены DNS. А еще будет печальнее, если домен был куплен лет на 10, потеряли все доступы, забыли, кто регистратор, и регистратор еще реселлер другого реселлера.

Инструмент обратной проверки DNS запрашивает указанный IP-адрес для преобразования в имя хоста. Имя хоста может быть чем-то вроде обычного домена или поддомена, например google-public-dns-a.google.com. Это имя хоста является именем хоста Google по IP 8.8.8.8, который является общедоступным IP-адресом DNS Google. Принимая во внимание, что если вы введете свой IP-адрес, он может указывать на имя хоста вашего интернет-провайдера, или если вы запросите IP-адрес вашего сервера, он может показать вам ваше доменное имя, на котором он разрешается.

Запись DNS PTR

Это противоположность как записи A для адреса IPv4, так и записи AAAA для адреса IPv6, называемой записями «прямой DNS».

Как хранятся записи DNS PTR?

Структура записи PTR такая же, как и у других типов записей DNS. Различные фрагменты информации располагаются в записи в соответствующих полях.

• : Он заполняется IP-адресом.
• : Пришло время жить. Это время в секундах, в течение которого запись действительна. По истечении срока его необходимо активировать снова.
• : Он содержит аббревиатуру используемого класса записей DNS.
• : Он имеет тип записи. т. е. PTR.
• : Он содержит данные ресурса, домен или имя хоста.

Например, запись PTR IPv4-адреса 8.8.4.4 для домена dns.google будет храниться под именем 4.4.8.8.in-addr.arpa.

В приведенном выше примере

• 4.4.8.8.in-addr.arpa. представляет собой идентификатор записи. Это запись PTR для записи A 8.8.4.4.
• PTR – это тип записи DNS.
• dns.google – это значение записи. Это домен или имя хоста, связанное с IP-адресом.
• 3600 – это TTL (время жизни).

Адреса IPv6 составлены иначе, чем адреса IPv4, и записи PTR IPv6 существуют в своем отдельном пространстве имен в .arpa. Записи PTR для IPv6 хранятся под адресом IPv6, переворачиваются и преобразуются в четырехбитные разделы (в отличие от 8-битных разделов, как в IPv4) плюс .ip6.arpa.

Например, запись PTR IPv6-адреса 2001:4860:4860::8844 для домена dns.google будет храниться под именем 4.4.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4. 0.6.8.4.1.0.0.2.ip6.arpa.

В приведенном выше примере

• 4.4.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. представляет собой идентификатор записи. Это запись PTR для записи A 2001:4860:4860::8844.
• PTR – это тип записи DNS.
• dns.google – это значение записи. Это домен или имя хоста, связанное с IP-адресом.
• 3600 – это TTL (время жизни).

Основное использование записей PTR.

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

Нужны ли мне записи PTR?

Простой ответ — да. Электронная почта — неотъемлемая часть бизнеса, и Google рекомендует использовать записи PTR.

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

Могу ли я иметь несколько записей PTR?

Для записей PTR, таких как записи MX, такая функция недоступна для определения приоритетов.

Сколько времени требуется для распространения записи PTR?

Обычно это зависит от того, как часто хостинговая компания обновляет файлы зоны. Даже если вы обновите записи PTR с панели инструментов панели хостинга, а хостинговая компания сразу же обновит свои файлы зон после этих обновлений. Тем не менее, это требует времени из-за DNS TTL.