在設定DNS的SPF (Sender Policy Framework)設定的時候，使用include把一些電子郵件服務提供商的FQDN寫入SPF設定。通常include一個FQDN，填寫的內容是該ESP寄信的IP，但有些電子郵件服務提供商(ESP, E-mail Service Provider)會在裡面再填入include，變成nested lookup巢狀結構，這樣很容易就會突破lookup上限的10。這個時候用DNS查詢就會出現類似這種錯誤：
SPF PermError: too many DNS lookups
解決因為include太多的DNS永久錯誤，手動方法有兩個：
- SPF flattening：刪除一個include，把包含在裡面的IP直接拿出來寫
- 為每一個ESP創造一個subdomain，將相關的SPF的include都塞在裡面
通常會遇到這種問題，都是因為使用多個ESP。因此建議會是上述第2種設定方法：將每個ESP綁一個subdomain，這樣可以分離不同供應商，且DMARC與DKIM的設定也可以分開設定，才能降低管理難度。
對於SPF DNS lookup limit is 10這個限制有興趣的，可以參考RFC7208 section 4.6.2
Some mechanisms and modifiers (collectively, "terms") cause DNS queries at the time of evaluation, and some do not. The following terms cause DNS queries: the "include", "a", "mx", "ptr", and "exists" mechanisms, and the "redirect" modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".
參考資料
- SPF 洋葱：走进 SPF 混乱的世界：說明上述include的nested lookup結構叫做SPF onion。裡面有詳盡的例子說明DMARC, SPF和DKIM
- 如何设置发送者策略框架 (Sender Policy Framework, SPF): 完整教程：詳細說明SPF的語法，而且有比較include與redirect語法之間的差異
- 修复SPF的错误：克服SPF过多的DNS查询限制：說明10個DNS的查詢限制
- SPF PermError: Too Many DNS Lookups - When SPF Record Exceeds 10-DNS-Lookup Limit：裡面提到上次該SPF DNS lookup limit起因於RFC7208 section 4.6.2
- 檢查microsoft.com on SPF Record Checker@EASYDMARC：
- 檢查清华大学on SPF Record Checker@EASYDMARC：可以看到已經用到SPF上限，而且也可以知道郵件供應商主要是iCoremail，郵件伺服器放在jdcloud京东云、aliyun-cloud阿里 云、I-sdnproxy, azure-sdnproxy, do-sdnproxy, hw-sdnproxy等上游供應商
- 檢查FBI.gov on SPF Record Checker@EASYDMARC：
情報機構果然很簡潔，就是東部跟西部
_EOF_
沒有留言:
張貼留言