У нас есть почтовый сервер (Mailenable), который мы используем для продажи аккаунтов электронной почты нашим клиентам. У нас есть один клиент, который не может отправить почту на определенный домен, и он получает эту ошибку от почтового сервера домена:
Причина: Сообщение не может быть доставлено, поскольку доменное имя ourclientcompanyname.com не имеет записей DNS.
Компания, которая использует нашу электронную почту, не имеет никаких записей DNS для своего домена.ourclientcompanyname.com
Записи MX в порядке, но у домена нет других записей DNS. Это возможная ошибка? Какие записи DNS клиент должен добавить?
решение1
Записи MX в порядке, но у домена вообще нет записи dns. Возможная ли это ошибка? Какую запись dns должен добавить клиент?
Да, некоторые почтовые серверы при получении письма проверяют, есть ли записи DNS у домена отправителя, а не только у отправляющего сервера. Я думаю, что это немного глупо и не очень хорошая проверка на спам, но что есть, то есть. Скорее всего, вашему клиенту нужно просто добавить запись Aдля своего домена ourclientcompanyname.com apex. Закажите им аккаунт хостинга за 5 долларов и одностраничный информационный веб-сайт для пущей важности, просто чтобы быть вежливым.
РЕДАКТИРОВАТЬ:
В разделе 2.3.5 старого документа RFC 5321 говорится следующее:
При использовании доменных имен в SMTP допускаются только разрешимые, полностью определенные доменные имена (FQDN).
Noice! Я все еще думаю, что глупо думать об этом как о средстве защиты от спама и что это корреляция/причинно-следственная связь, но, эй, по крайней мере, это документированный стандарт, и его соблюдение имеет некоторые положительные побочные эффекты для папки со спамом! У кого два больших пальца и кто только что выучил RFC?
решение2
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-ми годами и должны были учитывать многие неинтернет-сети, которые больше не существуют, поэтому стандарты были гораздо менее строгими.)
решение3
Для корректной работы почты необходимы три записи DNS.
Запись A — сопоставление имени хоста с IP-адресом
Запись MX — запись MX привязана к записи A для почтового сервера.
Обратный поиск — IP-адрес должен быть привязан к записи A для обратного поиска (предотвращение спама).
Кроме того, необходимо настроить PAT-адрес на брандмауэре для почтового сервера, чтобы публичный IP-адрес (исходный IP-адрес) почтового сервера соответствовал обратному поиску.
Обычно вам придется связаться со своим интернет-провайдером и попросить его создать обратный просмотр, если ему принадлежат IP-адреса, которые вы используете на публичной стороне.
Примечание: Нет RFC относительно Forward-Confirmed Reverse DNS. Это просто лучшая практика.