Вы регистрируете домен, конфигурируете Email Workspace, но письма не приходят. Почта проходит, но в спаме. Служба поддержки говорит: "проверьте MX-записи". Вы открываете DNS-панель и видите таблицу с приоритетами, хостнеймами, TTL. Это выглядит сложнее, чем есть на самом деле.
MX-записи — это всего лишь указатели в DNS, говорящие интернету: "здесь живёт моя почта". Когда кто-то отправляет письмо на ваш адрес, его mail server смотрит MX-запись и знает, куда маршрутировать сообщение. Без правильной MX-записи почта просто пропадает. С правильной — письма приходят надёжно, с failover и резервированием.
Как работают MX-записи: базовый принцип
Когда Алиса отправляет письмо на адрес bob@company.com:
1. Mail server Алисы берёт домен company.com
2. Отправляет DNS-запрос: "Какие MX-записи есть для company.com?"
3. Получает ответ: "mail.company.com с приоритетом 10"
4. Разрешает имя mail.company.com в IP-адрес через A-запись
5. Подключается к этому IP по SMTP и доставляет письмо
MX-запись — это middleman между доменом и mail-сервером. Она говорит: "письма для company.com отправляйте на mail.company.com, а не на web.company.com или что-то ещё".
Синтаксис MX-записи
Типичная MX-запись выглядит так:
@ MX 10 mail.company.com.
Разберём каждую часть:
@ — символ применения к корневому домену (company.com). Если вместо @ написать mail, запись применится к поддомену mail.company.com.
MX — тип записи. MX = Mail Exchange.
10 — приоритет (preference). Чем ниже число, тем выше приоритет. 10 будет попробован первым, затем 20, потом 30.
mail.company.com. — хостнейм mail-сервера (FQDN). Точка в конце обязательна (говорит: это абсолютный путь в DNS).
Приоритет и механизм failover
Приоритет — ключ к надёжной доставке почты. Правильно настроенная цепочка MX-записей выглядит так:
@ MX 10 mail1.company.com. (основной, попробуют первым)
@ MX 20 mail2.company.com. (резервный, если 10 недоступен)
@ MX 30 mail3.company.com. (третий уровень резерва)
Когда Алисин mail server отправляет письмо:
1. Пытается подключиться к mail1.company.com (приоритет 10)
2. Если mail1 не отвечает, пробует mail2.company.com (приоритет 20)
3. Если и mail2 не отвечает, пробует mail3.company.com (приоритет 30)
4. Если все недоступны, письмо становится в очередь и повторяется позже (bounce если никто так и не ответит через несколько часов)
Это гарантирует, что даже если основной mail-сервер упадёт, почта не потеряется — её перехватит резервный.
Примеры конфигураций для популярных сервисов
Google Workspace
Если вы используете Google Workspace (Gmail для доменов), Google дает вам готовые MX-записи:
@ MX 5 gmail-smtp-in.l.google.com.
@ MX 10 alt1.gmail-smtp-in.l.google.com.
@ MX 20 alt2.gmail-smtp-in.l.google.com.
@ MX 30 alt3.gmail-smtp-in.l.google.com.
@ MX 40 alt4.gmail-smtp-in.l.google.com.
Вводите точно так, как Google указал в административной консоли. Google поддерживает несколько резервных серверов, чтобы почта никогда не потерялась.
Microsoft 365
Для Microsoft 365 (Outlook для доменов) MX-запись одна, но критична:
@ MX 10 company-com.mail.protection.outlook.com.
company-com — это ваш домен, переделанный в формат хостнейма (точки замены на дефисы). Microsoft тоже имеет внутренние резервы, поэтому вам не нужно добавлять дополнительные MX-записи.
Собственный mail-сервер с резервированием
Если вы хостируете mail-сервер самостоятельно (Postfix, Sendmail):
@ MX 10 mail-primary.company.com. (основной сервер)
@ MX 20 mail-secondary.company.com. (резервный сервер в другом ЦОД)
Оба сервера должны быть настроены синхронизировать очередь почты (queue synchronization), чтобы при падении primary письма не потеряли, а переместились на secondary. Используйте разные физические локации или облачные регионы.
Как проверить MX-записи
Проверка MX-записей — первый шаг при диагностике проблем с почтой. Используйте наш бесплатный MX Lookup Tool или командную строку:
nslookup -type=MX company.com
dig MX company.com +short
host -t MX company.com
На Windows:
nslookup -type=MX company.com 8.8.8.8
Если MX-запись не видна, значит:
1. Вы не добавили MX-запись в DNS-панель (самая частая ошибка)
2. DNS-кэш не обновился (подождите, очистите кэш: ipconfig /flushdns на Windows, sudo dscacheutil -flushcache на macOS)
3. Вы используете неправильный nameserver (убедитесь, что Domain Registrar указывает на правильные nameservers)
MX, SPF, DKIM, DMARC: полный стек email-безопасности
MX-записи говорят куда маршрутировать входящую почту. Но чтобы исходящая почта не попадала в спам и не была подделана, нужны ещё три механизма:
SPF (Sender Policy Framework) — TXT-запись, которая говорит: "письма от company.com могут отправлять только эти IP-адреса или mail-сервера". Если письмо от спуфера с IP X, mail-сервер получателя проверит SPF и поймёт, что это подделка.
DKIM (DomainKeys Identified Mail) — криптографическая подпись. Когда Ваш mail-сервер отправляет письмо, он подписывает его приватным ключом. Mail-сервер получателя проверяет подпись публичным ключом (который в DNS-записи DKIM) и убеждается: это реально ваше письмо.
DMARC (Domain-based Message Authentication, Reporting and Conformance) — мета-политика. Она говорит: "если SPF или DKIM не пройдены, делай то-то (reject/quarantine)". DMARC также отправляет отчёты о том, какие письма попытались выдавать себя за вас.
Вместе эти четыре механизма обеспечивают полный контроль над почтой: MX маршрутирует, SPF/DKIM/DMARC защищают.
Частые ошибки при настройке MX-записей
Ошибка 1: MX-запись указывает на IP-адрес. WRONG: @ MX 10 192.168.1.1. RIGHT: @ MX 10 mail.company.com. DNS требует FQDN. Если вы позже переедете на другой IP, запись сломается. С именем хоста достаточно обновить A-запись.
Ошибка 2: MX-запись указывает на CNAME. WRONG: @ MX 10 mail.company.com. (где mail.company.com сам является CNAME). CNAME-цепочки в MX-записях приводят к непредсказуемому поведению. Каждый MX должен резолвиться непосредственно в A-запись.
Ошибка 3: забытая точка в конце хостнейма. @ MX 10 mail.company.com (без точки) может быть интерпретировано как mail.company.com.company.com. Всегда добавляйте точку в конце в FQDN-записях.
Ошибка 4: несуществующий хостнейм. Вы указали @ MX 10 mail.company.com., но A-записи для mail.company.com нет. Отправляющий mail-сервер не сможет разрешить имя и отклонит письмо. Проверьте A-запись для хостнейма MX-записи.
Ошибка 5: одинаковые приоритеты для failover. @ MX 10 mail1.company.com. и @ MX 10 mail2.company.com. означают, что оба сервера имеют одинаковый приоритет. Отправляющий сервер выберет один случайно (round-robin), что не гарантирует failover. Используйте разные приоритеты: 10, 20, 30.
Мониторинг доставляемости email
Правильная MX-конфигурация — основа, но этого недостаточно. Email-сервер может быть недоступен, SPF может быть сломан, DKIM может не подписывать письма. Мониторить здоровье email-инфраструктуры помогают:
TCP checks на порты 25/587/465: убеждаются, что mail-сервер слушает SMTP-порты и отвечает.
HTTP checks на endpoints /health: если ваш mail-сервер имеет встроенный health-check endpoint, мониторьте его регулярно.
DNS checks: периодически проверяйте, что MX, SPF, DKIM, DMARC-записи присутствуют и корректны. AtomPing может проверять их автоматически.
Если mail-сервер упадёт посредине ночи, вы узнаете об этом сразу благодаря мониторингу, а не когда клиенты позвонят с жалобой.
TTL: время кэширования MX-записей
Каждая DNS-запись имеет TTL (Time To Live) — время, в течение которого отвечающий DNS-сервер может кэшировать результат. По умолчанию MX-записи имеют TTL 3600 (1 час).
Высокий TTL (3600+): экономит traffic DNS-серверов, но изменения распространяются медленно (до часа и дольше).
Низкий TTL (300-600): изменения вступают в силу за 5-10 минут, но DNS-серверов нагружаются чаще.
Совет: перед большой миграцией mail-сервера снизьте TTL за сутки до 300. Это позволит быстро переключиться, если что-то пойдёт не так. После миграции верните обратно на 3600.
Резюме: чек-лист MX-конфигурации
✓ MX-записи добавлены в DNS (проверить через nslookup или MX Lookup Tool)
✓ MX указывает на FQDN, не на IP
✓ A-запись для каждого MX хостнейма существует и разрешается в правильный IP
✓ Приоритеты правильные: низкие для основного, выше для резервного
✓ SPF, DKIM, DMARC настроены (защита от спама и спуфинга)
✓ Mail-серверы мониторятся (TCP check на SMTP-порты, health check endpoint)
✓ DNS-кэш очищен, TTL распространился
Связанные материалы
- MX Lookup Tool — быстрая проверка MX-записей домена
- DNS Record Types Explained — детальное объяснение A, CNAME, TXT, MX и других DNS-записей
- IP Blacklist Guide — как избежать попадания в спам-листы
FAQ
What is an MX record and why does my email need it?
An MX record is a DNS entry that tells the internet where to deliver email for your domain. When someone sends an email to user@yourdomain.com, their mail server looks up the MX record for yourdomain.com to find out which server should receive that email. Without MX records, email can't be delivered — it's like having a mailbox with no address on it.
What does the priority value in MX records mean?
The priority (also called preference value) determines which mail server to try first. Lower numbers = higher priority. If you have MX records with priority 10 (primary) and 20 (backup), the sender will try priority 10 first. If that server is down, it tries priority 20. You can chain multiple MX records to create failover without losing mail.
Why can't I point an MX record to an IP address?
MX records must point to hostnames (FQDN), never IP addresses. This is enforced by DNS specs. If you hardcoded an IP and later moved that service to a different IP, all your MX records break. With hostnames, you just update the A record, and MX records automatically resolve to the new IP. It's a single point of change instead of many.
What's the relationship between MX, SPF, DKIM, and DMARC?
MX records route incoming mail. SPF, DKIM, and DMARC protect against spoofing. SPF says which IPs can send email from your domain. DKIM cryptographically signs messages. DMARC sets policy for what happens if SPF/DKIM fails. Together, they prevent attackers from impersonating your domain. Without all four, email deliverability suffers and security is weak.
How long does it take for MX record changes to take effect?
MX records are cached by DNS servers (TTL: Time To Live, default 3600 seconds = 1 hour). Changes propagate within minutes, but some servers may cache longer. In practice: changes usually visible within 10-30 minutes, can take up to 24 hours in worst case. Test with tools like nslookup or your registrar's DNS checker.
What happens if I have multiple MX records with the same priority?
If multiple MX records share the same priority value, the mail server picks one randomly (round-robin). This distributes load across servers. However, it breaks failover — if one server is down, mail might still be sent to it and bounce. Best practice: use different priority values (10, 20, 30) so failover is deterministic and clear.