DNS-записи

Коротко: Записи в DNS-зоне домена, определяющие, среди прочего, какой сервер отвечает за домен (запись A), на какой адрес указывает псевдоним (CNAME) или какие серверы могут принимать электронную почту (MX).

Подробнее: Важные типы: A (домен → IP-адрес), CNAME (домен → другой домен), TXT (произвольный текст, например для подтверждения домена или SPF/DKIM), MX (ответственность почтового сервера). Wildcard-запись (*.domain.com) покрывает любое число поддоменов сразу — у внешних DNS-провайдеров (как OVH здесь) это нельзя решить отдельными записями A/CNAME; для этого хостинг-провайдеру пришлось бы взять на себя всё управление серверами имён.

Наш контекст: Управляется в OVH — включая записи TXT для подтверждения домена в Vercel, а также DKIM/SPF для Resend. Wildcard-запись понадобится позже для запланированной мультитенантной модели (поддомены для каждого клиента).

Подробности

SPF и DKIM подробно

SPF и DKIM (оба настраиваются записями TXT) — два разных, дополняющих друг друга механизма, с помощью которых получатели писем проверяют, что письмо действительно пришло с указанного домена и не подделано:

• SPF (Sender Policy Framework) перечисляет, каким почтовым серверам вообще разрешено отправлять от имени домена — получатель проверяет, есть ли сервер, фактически отправивший письмо, в этом списке. Типичная запись SPF выглядит как v=spf1 include:_spf.resend.com ~all — include указывает на список серверов поставщика почтовой службы, ~all помечает не указанных в списке отправителей как «soft fail» (подозрительные, но не отклоняются сразу).
• DKIM (DomainKeys Identified Mail) криптографически подписывает каждое исходящее письмо закрытым ключом; получатель проверяет подпись по открытому ключу, опубликованному как запись TXT, — подтверждая, что письмо не было изменено в пути. В отличие от SPF (который проверяет только ОТПРАВЛЯЮЩИЙ сервер), DKIM дополнительно обеспечивает целостность самого содержимого.

Третий, часто упускаемый механизм — DMARC (тоже запись TXT), определяющий, что делать с письмами, не прошедшими SPF и/или DKIM (отклонить, переместить в спам или только записать в журнал), — и при желании указывающий адрес для отчётов о неудачных проверках. Без записи DMARC каждый принимающий почтовый сервер сам решает по своему усмотрению, что делать с проваленными проверками SPF/DKIM.

Последствия отсутствия настройки

Если оба механизма настроены неправильно, исходящие письма у многих получателей (особенно Gmail, Outlook) автоматически попадают в спам или отклоняются полностью — почтовые службы вроде Resend выдают нужные значения записей TXT в своей панели, которые затем вводятся у вашего DNS-провайдера (здесь OVH). Частая преграда: изменения DNS распространяются по глобальной системе DNS не сразу — в зависимости от TTL предыдущей записи и кэширования на разных резолверах это может занять от минут до 48 часов, поэтому только что настроенный почтовый домен не работает надёжно сразу.

Сравнение типов записей

Помимо типов, упомянутых в кратком разделе, есть, среди прочего, AAAA (как A, но для адресов IPv6 вместо IPv4), NS (определяет, какие серверы имён вообще авторитетны для домена, — «метауровень» над всеми другими записями) и SRV (для служб, которым нужна конкретная комбинация хоста И порта, например некоторые протоколы VoIP или чата). У каждого типа записи свой TTL, который можно настраивать независимо от других записей того же домена, — разумно ставить его низким незадолго до запланированного изменения, чтобы оно вступило в силу быстрее.

См. также: Мультитенантная архитектура, Resend, TTL, CNAME