Что такое MX-записи: гайд для cold email отправителя на 2026

MX-записи (Mail eXchange records) — DNS-записи, говорящие интернету, куда доставлять mail для данного домена. Они foundational — без корректных MX-записей никакой email не может быть доставлен в ваш домен вообще — но большинство cold email команд относится к ним как к тому, что IT настроил раз и никогда больше не смотрит. Обычно это fine, до того дня, когда MX-записи становятся причиной, по которой ваши кампании silently failing. Эта статья — что MX-записи делают, почему они matter для cold email отправителей конкретно, как inspecting их и misconfigurations, ломающие sending. Пара к гайду по доставляемости email и гайду по MX setup Google Workspace.

MX-запись — DNS-запись, listing mail-серверы, ответственные за приём email от имени домена. У каждой MX-записи есть priority value (lower = preferred) и server hostname. Когда кто-то шлёт mail на you@yourdomain.com, их сервер запрашивает DNS для MX-записей вашего домена и доставляет на highest-priority сервер, который отвечает.

Что MX-записи делают на практике

Каждый домен, принимающий email, должен иметь как минимум одну MX-запись. Формат записи выглядит так:

yourdomain.com.  IN  MX  10  smtp.google.com.
yourdomain.com.  IN  MX  20  smtp2.google.com.

Это говорит: “Mail для yourdomain.com должен идти на smtp.google.com first (priority 10), и если он unreachable, попробовать smtp2.google.com (priority 20)”.

Priority-числа создают fallback chain. Lower numbers пробуются first. Multiple MX-записи с тем же priority distribute load через серверы — sending-системы выбирают одну случайно.

Для cold email отправителей конкретно, MX-записи matter тремя способами:

Получение replies. Replies ваших prospect’ов должны landить в ваш inbox. Если ваши MX-записи misconfigured, replies bounce. Вы не заметите immediately, потому что bounce идёт к prospect’у, не к вам — они просто перестают вам отвечать, и вы думаете, что они проигнорировали reply.

Email верификация. Verification-сервисы проверяют MX-записи, чтобы определить, может ли домен принимать mail вообще. Домены без MX-записей или со сломанными MX-записями flagются как undeliverable, независимо от конкретного адреса.

Reputation signal. Receiving-системы используют MX-конфигурацию как один сигнал в domain legitimacy assessment. Домен без MX-записей, но с high outgoing volume, выглядит suspicious — легитимные домены имеют proper receiving-инфраструктуру.

Как inspecting MX-записи

Самый простой способ check MX-записи — команда dig:

dig +short MX yourdomain.com

Это возвращает MX-записи для домена. Online-тулы вроде MXToolbox, DNSChecker или What’s My DNS предоставляют ту же информацию в browser-интерфейсе плюс additional diagnostics.

Что верифицировать при inspecting:

• Существует как минимум одна MX-запись. Нет MX-записей = нет email reception.
• MX-hostname’ы resolve к actual mail-серверам. У каждого hostname должна быть A или AAAA запись, указывающая на real IP.
• Приоритеты make sense. Продакшен-setup typically имеет primary (low priority number) плюс 1–3 backup (higher priorities).
• Mail-серверы actually accept connection на port 25. Подключение через telnet mailserver.com 25 или использование тула вроде Email Tester подтверждает, что сервер отвечает.
• PTR-записи существуют для IP mail-сервера. Receiving-системы проверяют, что у MX-hostname есть matching reverse DNS entry.

Типичные MX-record misconfigurations

Нет MX-записей вообще. Домены без MX-записей не могут принимать email. Некоторые команды настраивают sending без конфигурирования receiving, assuming “нам не нужен receiving”. Но cold email нуждается в receiving — replies должны landить где-то.

MX-записи, указывающие на non-existent серверы. Leftover MX-запись, указывающая на старого mail-провайдера (после миграции), приводит к failure delivery attempts. Продакшен-команды audit’ят MX-записи после каждого infrastructure change.

Priority order misconfigured. Когда primary MX имеет high priority (high number), а backup имеет low priority, sending-системы prefer wrong server. Это usually не ломает delivery, но производит unusual routing.

Duplicate MX-записи на том же priority. Некоторые DNS-конфигурации end up с duplicate-записями — duplicate не causes error, но может confuse load distribution.

Subdomain MX-записи отсутствуют. Если вы шлёте с outreach.yourdomain.com, subdomain нуждается в собственных MX-записях (или inheriting от parent — верифицируйте на основе behavior вашего DNS-провайдера). Забывание subdomain MX-записей означает, что replies на subdomain-адреса fail.

MX-записи с CNAME aliases. RFC говорит, что MX-записи должны указывать на A/AAAA-записи, не CNAME. Некоторые DNS-провайдеры allow это, но receiving-системы могут отклонить конфигурацию. Всегда указывайте MX-записи на hostname с direct A-записями.

Когда обновлять MX-записи

Обновляйте MX-записи когда:

• Migrating email-провайдеров (например, с Gmail на Office 365 или vice versa). Migration-провайдер даст вам новые MX-значения; обновите DNS и подождите propagation.
• Добавляете новый subdomain для sending. Новые subdomain нуждаются в собственных MX-записях, если они будут принимать mail.
• Добавляете third-party mail filtering сервис (Mimecast, Proofpoint, Barracuda) — они становятся primary MX с underlying mail-провайдером как backup.
• Переключаетесь на новый транзакционный email-провайдер — обычно не требует MX-изменений (транзакционные провайдеры sending-only), но верифицируйте против документации провайдера.

Не обновляйте MX-записи:

• Для cold email тулов вроде Smartlead, Lemlist, Apollo — это sending-платформы, не receiving. Им не нужны MX-записи.
• Для “улучшения доставляемости” без конкретной причины — MX-записи влияют на receiving, не sending placement.

Паттерн: MX-записи foundational, simple и часто overlooked. Setting them up correctly — 5-минутная задача; misconfiguring them производит silent failures, которые могут run неделями до того, как кто-то notices. Продакшен-команды верифицируют MX-конфигурацию как часть каждого domain audit и any infrastructure change.