為什麼管理員大多在 SPF 記錄中使用+a「side」 ？+mx這是例子：
@ 10800 IN TXT "v=spf1 +a +mx -all"
僅使用參數還不夠嗎+mx，例如：
@ 10800 IN TXT "v=spf1 +mx -all"
我認為MX記錄的任務是發送電子郵件而不是A記錄的任務。誰能解釋+a為什麼有人會使用這個場景？
答案1
坦白說，因為他們從一些教程或範例配置中複製了配置，而不了解 SPF 的基本原理。有時需要例如網頁伺服器a和傳入的網路伺服器郵件交換 mx也用於發送郵件，但並非總是如此。
最好採用額外 DNS 查詢較少的機制：ip4/ip6一遍a又a一遍mx（RFC 7208，10.1.1）即使，為了更容易管理（10.1.2），a選擇機制，並不總是a mx或a，而是例如a:relay.example.com。
答案2
記錄中列出的主機的任務MX是收到電子郵件，不一定是遞送電子郵件。
處理入站和出站電子郵件的主機不相同的非對稱設定是完全有效的（而且很常見，特別是對於較大的操作）。
也就是說，不能保證SPF 中的mx(aka +mx) 或a(aka +a) 與指定哪些主機預期相關遞送電子郵件。
舉個例子，如果您不運行自己的郵件伺服器，也許類似的東西v=spf1 include:spf.majoremailserviceprovider.example -all會更相關。
為了直接解決為什麼該a mx組合在 SPF 記錄中出現過多的問題，我的猜測是，這種情況歸結為太多管理員添加 SPF 記錄，而沒有充分了解 SPF 概念，無法判斷在其策略中添加哪些內容，而只是複製貼上一些任意構造的範例。
答案3
我同意其他答案，這+a +mx可能是貨物崇拜的反習語。
關於您何時使用+a，RFC 文件在中回答了這個問題第10.1.2節：
發佈各個主機的 SPF 記錄也是最佳實務。主機名稱通常是 5321.HELO/.EHLO 指令中使用的識別。對於具有空 5321.MailFrom 的郵件，除了在基於 5321.HELO/.EHLO 的 SPF 檢查中使用之外，它還用作 5321.MailFrom SPF 檢查的網域。參與郵件處理的單一主機的標準 SPF 記錄是：
relay.example.com. IN TXT "v=spf1 a -all"
例如，我為我的郵件伺服器發布了這樣的記錄mail.mydomain.org，以方便首先驗證 HELO 身份的驗證者。 （當然，我也在v=spf1 mx -all郵件網域mydomain.org本身發布了習慣記錄。）
答案4
可能是長度上的優勢——儘管這不太可能是真正的動機。
請考慮 TXT 記錄的大小可能會超出單一 UDP 封包的大小。因此，請求在 TCP 中再次發送，回覆是多個 TCP 封包和相關的握手建立時間。
透過仔細使用 A 和 MX 請求，可以獲得 SPF 記錄的兩個約 1500 位元組的 UDP 回复，一個用於 A，一個用於 MX，以及所有 TXT 記錄的剩餘約 1400 位元組。
這假設您的 SPF 記錄中有足夠的授權“事物”，超過 3000 位元組。 Includes 也可以解決長度限制，但我不清楚它們是否都是單獨的 UDP 請求或單一 TCP 請求會話。