☰

防止您看起來像垃圾郵件發送者的最佳實踐

tag-icon • tag-icon email-server spam spf spam-filter mx-record
防止您看起來像垃圾郵件發送者的最佳實踐

我希望能夠更有信心地為我的客戶設定關於誤報的郵件。這是我所知道的：

  1. SPF 記錄很好，但並非每個垃圾郵件過濾服務/軟體 (SFSS) 都使用它們。

  2. 反向 DNS (PTR) 記錄幾乎是必需的。

  3. 開路繼電器不好。

    （這是我讀過的「其他提示」）：

  4. 郵件伺服器 IP 位址的反向查找應解析為您傳送郵件的網域。

  5. 當與其他郵件伺服器通訊時，您的伺服器應該說 HELO FQDN.of.your.mail.server.com。

  6. MX 記錄中的 A 主機記錄應該是（或解析為 IP 位址）您的 FQDN.of.your.mail.server.com

對 1 和 3 感覺很好。

2 和 4：我做了很多挖掘，這似乎是不正確的，因為大多數垃圾郵件過濾器都在尋找 PTR一般的以及不是由 ISP 一般分配的一個；您發送郵件的網域似乎與此無關（即，如果您擁有兩個用於郵件的網域，您需要從兩個 IP 位址發送郵件，每個 IP 位址都帶有 PTR？）

  1. 這是有道理的，但它關心 FQDN 解析為什麼嗎？它是否應該解析為目前發送所述 HELO 的 IP 位址？

  2. 再次，來自各種谷歌搜尋的另一個；如果您使用 Postini 作為網關服務（或任何其他智慧主機），我不知道這將如何運作。

那麼代表您無權的另一個域發送又如何呢？我有一些客戶（some.branchdomain.tld）需要以@some.corporatedomain.tld 的身份發送郵件，儘管所述公司總部不會設置中繼/智能主機供他們使用。 Corporatedomain.tld 可以建立 SPF 記錄來顯示 some.branchdomain.tld 被允許發送郵件，但這仍然會考慮“欺騙”，特別是如果所述 SFSS 不檢查 SPF 記錄的話？我應該擔心這個嗎？

答案1

我可以保證#2（反向 PTR）很重要，但#4（符合「from」的郵件伺服器網域）很重要。我們一直在設定郵件伺服器，大多數郵件主機甚至不關心#2。

主要的刺始終是 AOL，他們列出了標準你可以檢查一下。

答案2

除了前面提到的 HELO 字串和 DNS PTR 記錄之外，大部分有幫助的內容將與內容相關，而不是與發送伺服器相關。

  • 如果可以避免的話，不要發送 HTML 電子郵件。
  • 請勿包含可疑短語（「點擊取消訂閱」、「隱私很重要」等）
  • 不要使用「回覆」標頭，從您希望回覆發送到的地址發送
  • ...和更多。閱讀 SpamAssassin 規則集以取得更多優秀範例。

至於您的問題“它關心 FQDN 解析為什麼嗎？”，這完全取決於接收郵件伺服器的功能，當然它可能會有所不同，但您通常不會發現太多依賴 FQDN 的郵件伺服器FQDN 查找是一項硬性且快速的規則，因為可以在循環設定中配置多台電腦。

答案3

內容指南怎麼樣？保持電子郵件的合理性將有助於防止您在各種系統中被標記為垃圾郵件產生者。訓練您的客戶避免將「有趣的內容」轉發給聯絡人清單中的每個人，不註冊電子郵件摘要或新聞通訊，並使用明智的惡意軟體保護機制來防止成為垃圾郵件殭屍網路的一部分... …

答案4

4其實是完全錯誤的。您可能會更多地思考寄件者政策框架，其中網域的 DNS 包含一筆記錄，該記錄指出允許哪些 SMTP 伺服器傳送帶有該網域的 From: 標頭的郵件。但事實是託管網域通常具有外發郵件伺服器不是與網域相同，但寄件者的 ISP。例如，如果您有 myvanitydomain.com 和電子郵件地址[電子郵件受保護]，但如果您使用 Sprint 作為您的網際網路供應商，通常必須使用 Sprint 的外寄郵件伺服器來傳送電子郵件。有多種方法可以解決此問題（例如 Webmail 或 POP-then-SMTP 身份驗證），但這是一個很好的範例。

至於“如何讓電子郵件看起來不像垃圾郵件”，嗯……當然，你不會讓它看起來像垃圾郵件。您甚至考慮使用開放中繼的事實聽起來……很可疑。我想不出任何一個合理的理由來解釋為什麼你會這樣做想當每個 ISP 都有一個 SMTP 伺服器。如果您為發送郵件的伺服器託管付費，那麼您的 IP 位址不被各個機構列出的方法就是不發送垃圾郵件。

相關內容