我們有一個郵件伺服器（Mailenable），我們用它來向客戶出售電子郵件帳戶。我們有一個客戶端無法將電子郵件發送到特定網域，並且他們從該網域的電子郵件伺服器收到此錯誤：
原因：無法傳遞郵件，因為網域名稱 ourclientcompanyname.com 沒有任何 DNS 記錄。
使用我們發送電子郵件的公司沒有其網域的任何 DNS 記錄ourclientcompanyname.com
MX 記錄沒問題，但該網域沒有其他 DNS 記錄。這是一個可能的錯誤嗎？客戶端應新增哪些 DNS 記錄？
答案1
MX 記錄有效，但該網域根本沒有 dns 記錄。這是一個可能的錯誤嗎？客戶端應該新增什麼 dns 記錄？
是的，某些郵件伺服器在收到電子郵件後會檢查發送使用者的網域（而不僅僅是發送伺服器）是否有 DNS 記錄。我認為這有點愚蠢，並且不能很好地檢查垃圾郵件，但事實就是如此。您的客戶很可能只需要A為其 ourclientcompanyname.com 頂級網域新增一筆記錄。給他們一個 5 美元的託管帳戶和一個單頁資訊網站，以示友善。
編輯：
埋藏在古老的 RFC 5321 中，它在 2.3.5 節說：
在 SMTP 中使用網域名稱時，僅允許使用可解析的完全限定網域名稱 (FQDN)。
通知！我仍然認為將其視為垃圾郵件威懾措施並且是相關性/因果關係合併是愚蠢的，但是嘿，至少它是一個記錄在案的標準，並且遵循它會對垃圾郵件文件夾產生一些積極的副作用！誰有兩個拇指並且剛剛接受過 RFC 訓練？
答案2
RFC 5321 第 2.3.5 節要求電子郵件中使用的網域可解析為位址。
從相關部分來看：
在 SMTP 中使用網域名稱時，僅允許使用可解析的完全限定網域名稱 (FQDN)。換句話說，可以解析為 MX RR 或位址（即 A 或 AAAA）RR（如第 5 節中討論）的名稱是允許的，其目標可以依次解析為 MX 或位址 RR 的 CNAME RR 也是如此。不得使用本地暱稱或不合格的名稱。需要 FQDN 的規則有兩個例外：
- EHLO 指令中給出的網域名稱必須是主主機名稱（解析為位址RR 的網域名稱），或如果主機沒有名稱，則為位址文字，如第4.1.3 節所述，並在第4.1.3 節中進一步討論。
這並不是一個新要求；RFC 2821 第 2.3.5 節（2001）有類似的語言。
如本文檔和 [22] 所述，網域是完整的、完全限定的名稱（通常稱為「FQDN」）。非 FQDN 形式的網域名稱只不過是本地別名。本地別名不得出現在任何 SMTP 事務中。
如果您的郵件伺服器說EHLO company.examplecompany.example 無法解析為位址，那麼拒絕該連線是完全有效的。寄件者和收件者地址中使用的網域名稱也是如此（郵局管理員除外，它根本不需要網域名稱）。
（在 RFC 2821 之前，管理標準是 RFC 821 和 RFC 974，這些標準可以追溯到 20 世紀 80 年代，並且必須適應許多不再存在的非互聯網網絡，因此標準的限制性要小得多。）
答案3
為了使郵件正常運行，需要三個 DNS 記錄。
A 記錄 - 主機名稱到 IP 位址的映射
MX 記錄 - MX 記錄綁定到郵件伺服器的 A 記錄
反向查找 - IP位址需要綁定A記錄進行反向查找（SPAM預防）
此外，還需要為郵件伺服器設定防火牆處的 PAT 位址，以便郵件伺服器的公用 IP（來源 IP）與反向查找相符。
如果您的 ISP 擁有您在公共端使用的 IP 位址，您通常需要與您的 ISP 聯繫並讓他們建立反向查找。
注意：沒有關於轉送確認反向 DNS 的 RFC。這只是一個最佳實踐。