各位先進好：
我們公司的郵件架構如下圖，mail server不直接對外，由2台郵件過濾主機做HA擔任郵件收發的第一線，再搭配頻寬管理器，使用2條線路做負載平衡，這樣運作大概已經10年了。
MX紀錄使用中華電信DNS代管，abc.com.tw是我們公司，def.com.tw是關係企業，今年以來同事頻頻抱怨寄給某些客戶的郵件沒有被退，但對方都說沒收到，一查都是hinet的郵箱，因我也有hinet的郵箱，用公司郵箱發了10封mail到hinet郵箱測試，有9封都被判定垃圾郵件，但用我們的網域名稱和對外IP去幾個網站查詢，都沒有被列黑名單。
我同事逛到了DNS反向查詢的測試網站，就做了測試，發現我們經常被判定不合格，原因是我們的郵件透過郵件過濾主機經由頻寬管理器出去，是2條線路都能出去，當郵件從Svr1經由線路1出去時，對方做反查，HELO訊息是svr1.abc.com.tw，來源IP為1.1.1.1，這時會PASS沒問題，但當郵件從Svr1經由線路2出去時，對方做反查，HELO訊息還是svr1.abc.com.tw，但來源IP為2.2.2.2，這時就會被判定不合格，反之亦然。
我有google了一下，發現頻寬管理器和PTR失敗沒有什麼相關的討論，請問是我們這樣的架構已經不是主流了嗎?還是頻寬管理器和PTR這2樣是互斥，沒有討論的必要?是否有前輩可以提供方向和建議? 謝謝!
已邀請的邦友 {{ invite_list.length }}/5
頻寬管理器和反解失敗無關,真正造成別人認為您反解失敗的是頻寬管理器會用一個以上的IP連外,所以您要處理好mail server走所有Internet連外時其FQDN-IP和IP-FQDN的關係....
PS:補充一下,大部分mail server其實不會單純因為SMTP HELO name和sender domain不一致就不收信(因為太常見了),大部分不收的原因是FQDN-IP和IP-FQDN兜不起來....
頻寬管理器是否為Ascenlink
如果是這個老舊設備
應該找維護資源很難了
這樣說是因為Ascenlink有一種功能叫multi-homing
常常用來做inbound loadbalance
有可能沒設好是造成此現象的原因
建議可將MX服務運作要改成active-standby
當運作時均以某條線路來處理
線路故障時才會切至另一條線路收發信
按照問題描述應該是PTR 設定的問題，郵件過濾主機廠商應該要有能力協助處理這個問題。
如果版主公司沒有簽維護合約那就另當別論了。
iThome鐵人賽
看影片追技術