MX или запись выходят
У нас есть почтовый сервер (Mailenable), который мы используем, чтобы продать почтовые ящики нашим клиентам. У нас есть один клиент, который не мог послать электронное письмо определенному домену и им receieve эта ошибка от почтового сервера домена:
Причина: сообщение не могло быть передано, потому что доменное имя ourclientcompanyname.com не имеет никаких записей DNS.
Компания, которая использует нас для электронной почты, не имеет никаких записей DNS для их домена ourclientcompanyname.com
Записи MX прекрасны, но домен не имеет никаких других записей DNS. Это - возможная ошибка? Какие записи DNS должны, клиент должен добавить?
Записи MX финны, но в домене вообще нет записей DNS. Это возможная ошибка? Какую запись DNS должен добавить клиент?
Да, некоторые почтовые серверы при получении электронного письма проверяют, есть ли записи DNS в домене отправляющего пользователя, а не только на отправляющем сервере. Я думаю, что это немного глупо и не очень хорошо для проверки на спам, но это то, что есть. Вашему клиенту, скорее всего, нужно просто вставить запись A для своего верхнего домена ourclientcompanyname.com. Получите им учетную запись хостинга за 5 долларов и одностраничный информационный веб-сайт для хорошей меры, просто для удобства.
РЕДАКТИРОВАТЬ:
Похоронен в старом RFC 5321, в разделе 2.3.5 говорится:
Только разрешается, Полные доменные имена (FQDN) разрешены, когда доменные имена используются в SMTP.
Шум! Я все еще думаю, что глупо думать об этом как о средстве сдерживания спама и смешении корреляции / причинности, но, по крайней мере, это задокументированный стандарт, и следование ему имеет некоторые положительные побочные эффекты для папки спама! У кого два больших пальца, и кто только что прошел курс обучения RFC?
Для правильной работы почты требуются три записи DNS.
A Запись - сопоставление имени хоста и IP-адреса
Запись MX - Запись MX привязана к Запись A для почтового сервера
Обратный поиск - IP-адрес должен быть привязан к записи A для обратного просмотра (предотвращение спама).
Кроме того, для почты необходимо задать адрес PAT на брандмауэре сервер, чтобы общедоступный IP-адрес (исходный IP-адрес) почтового сервера соответствовал обратному поиску.
Обычно вам нужно связаться с вашим интернет-провайдером и попросить его создать обратный поиск, если им принадлежат IP-адреса, которые вы используете на общедоступной стороне .
Примечание: RFC относительно обратного DNS с прямым подтверждением отсутствует. Это просто лучшая практика.
RFC 5321 раздел 2.3.5 требует, чтобы доменные имена, используемые в электронной почте, разрешались в адреса.
Из соответствующих частей:
Только разрешаемые, полностью определенные доменные имена (FQDN) разрешены когда доменные имена используются в SMTP. Другими словами, имена, которые могут разрешены в записи MX RR или адресные (то есть A или AAAA) RR (как обсуждалось в Разделе 5) разрешены, как и записи CNAME RR, цели которых могут быть разрешено, в свою очередь, в MX или адрес RR. Местные никнеймы или НЕ ДОЛЖНЫ использоваться неквалифицированные имена. Есть два исключения из правило, требующее FQDN:
- Имя домена, указанное в команде 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-ми годами и должен был учитывать многие сети, не относящиеся к Интернету, которые больше не существуют, поэтому стандарты были гораздо менее строгими.)