我想對所有未在我的域名的SPF記錄中明確列出的電子郵件源設置嚴格的FAIL限定符。如果父記錄比孩子更嚴格,對SPF記錄限定符的影響是否包含在另一個SPF記錄中?
這可以簡單地通過下面的記錄來完成(在-all
指定所有其它來源不應該被接受)
mydomain.com. IN TXT "v=spf1 ip4:my-ip-address/32 -all"
現在我的問題是,我除了想白名單我的電子郵件服務提供商( mailgun.com)以及谷歌應用程序,所以我創建以下記錄:
mydomain.com. IN TXT "v=spf1 include:mailgun.org include:_spf.google.com ip4:my-ip-address/32 -all"
現在的mailgun.com
SPF記錄(在谷歌的情況下,同樣的情況適用)解析爲:
mailgun.org. 3600 IN TXT "v=spf1 ip4:173.193.210.32/27 ip4:50.23.218.192/27 ip4:174.37.226.64/27 ip4:208.43.239.136/30 ip4:50.23.215.176/30 ip4:184.173.105.0/24 ip4:184.173.153.0/24 ip4:209.61.151.0/24 ip4:166.78.68.0/22 ip4:198.61.254.0/23 ip4:192.237.158.0/23 " "~all"
現在有趣的是,他們在他們的spf記錄上放了一個軟失敗限定符"~all"
。
維基百科介紹include指令如下:
如果包括(用詞不當)政策通過測試這種機制 匹配。這通常用於包含多個 ISP的策略。
我解釋這在一個未知發件人被列入紀錄認定爲SOFT FAIL
的方式,因此,通過爲SOFT FAIL
,因爲它們包含在根的紀錄。即使根記錄在所有未包含的來源上放置了FAIL
。
因此,常規記錄有效地呈現根記錄的FAIL限定符無用。所以最低限度的嚴格記錄會爲未知來源的總體限定詞取消。
我在這個假設中正確嗎?如果沒有,在給出的例子中,未知的發送者是否合格?它說:
Whether this mechanism matches, does not match, or throws an
exception depends on the result of the recursive evaluation of
check_host():
+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of: | to: |
+---------------------------------+---------------------------------+
| Pass | match |
| | |
| Fail | not match |
| | |
| SoftFail | not match |
| | |
| Neutral | not match |
| | |
| TempError | throw TempError |
| | |
| PermError | throw PermError |
| | |
| None | throw PermError |
+---------------------------------+---------------------------------+
的機制在本contects指的是「包括」的功能