У нас есть почтовый сервер (Mailenable), который мы используем для продажи учетных записей электронной почты нашим клиентам. У нас есть один клиент, который не может отправить электронное письмо в определенный домен, и он получает эту ошибку с почтового сервера домена:
Причина: сообщение не может быть доставлено, потому что доменное имя ourclientcompanyname.com не имеет записей DNS.
Компания, которая использует нас для электронной почты, не имеет записей DNS для своего домена. ourclientcompanyname.com
Записи MX подходят, но у домена нет других записей DNS. Это возможная ошибка? Какие записи DNS следует добавить клиенту?
RFC 5321 раздел 2.3.5 требует, чтобы доменные имена, используемые в электронной почте, разрешались в адреса.
Из соответствующих частей:
Только разрешаемые, полностью определенные доменные имена (FQDN) разрешены, когда доменные имена используются в SMTP. Другими словами, разрешены имена, которые могут быть преобразованы в записи MX RR или адреса (т. Е. A или AAAA) (как описано в разделе 5), как и записи CNAME RR, цели которых могут быть преобразованы, в свою очередь, в MX или адресные RR. . НЕ ДОЛЖНЫ использоваться местные псевдонимы или неполные имена. Есть два исключения из правила, требующего полных доменных имен:
- Доменное имя, указанное в команде EHLO, ДОЛЖНО быть либо основным именем хоста (имя домена, которое разрешается в адрес RR), либо, если у хоста нет имени, литералом адреса, как описано в Разделе 4.1.3 и обсуждается далее в обсуждение EHLO раздела 4.1.4.
Это не новое требование; RFC 2821 раздел 2.3.5 (2001) был похожий язык.
Доменное имя, как описано в этом документе и в [22], представляет собой полное, полностью определенное имя (часто называемое «FQDN»). Доменное имя, которое не указано в форме FQDN, является не более чем локальным псевдонимом. Локальные псевдонимы НЕ ДОЛЖНЫ появляться в любой транзакции SMTP.
Если ваш почтовый сервер говорит EHLO company.example
и company.example не могут быть разрешены в адрес, тогда вполне допустимо отклонить это соединение. То же самое верно и для доменных имен, используемых в адресах отправителя и получателя (за исключением postmaster, которому вообще не требуется доменное имя).
(До RFC 2821 основными стандартами были RFC 821 и RFC 974, которые относятся к 1980-м годам и должны были учитывать многие сети, не относящиеся к Интернету, которые больше не существуют, поэтому стандарты были гораздо менее строгими.)
Записи MX хороши, но в домене вообще нет записи DNS. Это возможная ошибка? Какую днс-запись должен добавить клиент?
Да, некоторые почтовые серверы после получения электронного письма проверяют, что домен отправляющего пользователя, а не только отправляющий сервер, имеет записи DNS. Я думаю, что это немного глупо и не очень хорошо для проверки на спам, но это то, что есть. Вашему клиенту, скорее всего, нужно просто поставить A
запись для их верхнего домена ourclientcompanyname.com. Получите им учетную запись хостинга за 5 долларов и одностраничный информационный веб-сайт для хорошей меры, просто на всякий случай.
Похороненный в старом RFC 5321, в разделе 2.3.5 говорится:
Только разрешаемые, полностью определенные доменные имена (FQDN) разрешены, когда доменные имена используются в SMTP.
Шум! Я все еще думаю, что глупо думать об этом как о средстве сдерживания спама и смешении корреляции / причинности, но, по крайней мере, это задокументированный стандарт, и следование ему имеет некоторые положительные побочные эффекты для папки спама! Кто имеет два больших пальца и только что изучил RFC?
Для правильной работы почты требуются три записи DNS.
Запись - имя хоста для сопоставления IP-адреса
Запись MX - запись MX привязана к записи A для почтового сервера.
Обратный поиск - IP-адрес должен быть привязан к записи A для обратного просмотра (предотвращение спама)
Кроме того, для почтового сервера должен быть установлен PAT-адрес на брандмауэре, чтобы общедоступный IP-адрес (исходный IP-адрес) почтового сервера соответствовал обратному поиску.
Обычно вам нужно связаться с вашим интернет-провайдером и попросить его создать обратный поиск, если им принадлежат IP-адреса, которые вы используете на общедоступной стороне.
Примечание: RFC относительно обратного DNS с прямым подтверждением отсутствует. Это просто лучшая практика.