發件人策略框架 (SPF)：電子郵件基礎架構中的一層保護
已發表: 2020-03-04您是否曾經有人（開玩笑或惡意）拿走您的手機並假裝是您給某人發短信？ 感覺不是很好，是嗎？ 即使你和收件人講清了真相，他們以後也很可能對你所有的短信保持警惕。 你可能會更加小心你讓誰借你的手機。 信任已被打破。
在電子郵件世界中也可能出現類似的情況，潛在的網絡釣魚者不需要您的用戶名和密碼來冒充您的企業。 可怕，對吧？
幸運的是，我們知道一個簡單的、不那麼秘密的技巧來保護您的品牌聲譽。 它稱為發件人策略框架 (SPF)，是電子郵件信譽的救星。
當電子郵件從一台服務器發送到另一台服務器時，使用簡單郵件傳輸協議 (SMTP) 將消息從發件人發送到收件人。 作為 SMTP 服務，Twilio SendGrid 促進了這一過程。
電子郵件基礎設施中的一個安全漏洞是任何發件人或主機都能夠將自己和他們的電子郵件標識為他們想要的任何域（有點像人們如何創建大量唐納德特朗普 Twitter 帳戶）。 這使得接收者很難相信一條消息實際上來自它所說的來自誰。 這也讓發件人感到不安，因為他們知道那裡的任何人都可以從他們的域發送郵件並可能損害他們的品牌聲譽。
收件人對電子郵件的真實性失去信任，發件人是偏執的冒名頂替者，冒充他們的品牌——對任何人都不利！ 解決方案的一部分是存儲在 DNS 中的 txt 記錄中的 SPF 記錄。 在本文中，我們將探索 SPF 的所有內容——從它是什麼到發現自己的錯誤，我們將涵蓋所有內容。
什麼是 SPF 記錄？
SPF 代表發件人策略框架。 這是一種電子郵件身份驗證方法，可幫助識別允許從特定域發送電子郵件的郵件服務器。 使用此驗證協議，ISP 可以確定欺騙者和網絡釣魚者何時試圖從您的域中偽造電子郵件以向您的用戶發送惡意電子郵件。
使用 SPF，收件人可以確信他們收到的電子郵件來自他們所期望的人。 發件人可以高枕無憂，因為他們知道網絡釣魚者不會通過電子郵件欺騙或從他們的品牌中對受眾進行網絡釣魚。
從技術上講，SPF 記錄是域管理員添加到其 txt 記錄中的短行文本。 txt 記錄與它們的 A、PTR 和 MX 記錄一起存儲在 DNS（域名系統）中。 SPF 記錄如下所示：
“v=spf1 ip4:12.34.56.78 包括：example.com -all”
SPF 的工作原理
上面的文本行用於告訴接收 SMTP 服務器允許哪些主機從給定域發送郵件。
SPF 記錄通常在 SMTP 會話的早期檢查，遠在郵件正文傳輸之前。 當嘗試發送消息時，發送方和接收服務器之間會打開一個 TCP 連接。
建立連接後，會發出 HELO 命令，該命令實質上會告訴接收服務器哪個域正在嘗試向其發送郵件。 隨後是一個 MAIL FROM 命令，該命令告訴接收服務器郵件來自哪個電子郵件地址。 在 MAIL FROM（也稱為信封發件人和返迴路徑）命令中找到的域是用於 SPF 記錄檢查的域。
所以假設收到了一條消息，MAIL FROM 地址是[email protected]。 接收服務器將檢查 example.com 的公共 DNS 記錄並查找以 v=spf1 開頭的 TXT 記錄。 如果沒有以 v=spf1 開頭的 TXT 記錄，則認證通過。 如果存在多個 v=spf1 的 TXT 記錄，則可能會發生錯誤。
假設找到一個，它看起來像我們之前的示例：
“v=spf1 ip4:12.34.56.78 包括：example.com -all”
接收服務器現在將檢查嘗試發送郵件的 SMTP 客戶端的 IP 地址是否包含在 SPF 記錄中。 如果列出了 IP 地址，則消息將通過 SPF 身份驗證。
細節：分解 SPF 記錄的每一部分
SPF 記錄由各種機制組成，包括：
包括
後面總是跟一個域名。 當接收服務器遇到包含機制時，會檢查該域的 SPF 記錄。 如果發件人的 IP 出現在該記錄中，則郵件通過身份驗證並且 SPF 檢查結束。 如果未找到，則 SPF 檢查將繼續進行下一個機制。
一種
後面還有一個域名。 但是在這種情況下，SPF 只是檢查與該域關聯的 IP 地址。 如果它與發件人的 IP 匹配，則它通過，並且 SPF 檢查停止。 如果不是，它會轉到下一個機制。
MX
類似於“A”。 它後面總是跟一個域名。 如果列出的域解析為發送客戶端的 IP 地址，則身份驗證通過，並且 SPF 檢查完成。 如果不是，它會轉到下一個機制。
IP4 和 IP6
後面總是跟一個特定的 IP 地址或 CIDR 範圍。 如果發送客戶端的 IP 列在任何 IP4 或 IP6 機制之後，則身份驗證將通過並完成 SPF 檢查。 如果不是，它會轉到下一個機制。
PTR
絕不應包含在 SPF 記錄中。 由於某些技術原因，它們容易出錯，並且要花費大量的內存和帶寬來接收服務器來解決。 基於 PTR 機制的存在，某些服務器將無法通過 SPF 身份驗證。
重定向
雖然從技術上講是一種修飾符，而不是一種機制，但它允許域管理員將域指向另一個域的 SPF 記錄。 如果使用 REDIRECT 功能，則 SPF 記錄中不能包含其他機制，包括“all”機制。 重定向記錄示例：“v=spf1 redirect:example.com”
“INCLUDE”、“A”、“MX”、“PTR”、“EXISTS”和“REDIRECT”機制都需要 DNS 查找，因此不能超過 10 個。 這看起來很簡單，但這也包括嵌套的 DNS 查找，這意味著導致另一個 SPF 記錄的“包含”具有另外兩個“包含”機制將被視為三個 DNS 查找。 他們加起來很快！
Twilio SendGrid 客戶呢？
我們的大多數發件人都設置了一個 CNAME，將他們的發送域指向 sendgrid.net。 這意味著接收服務器看到指向 sendgrid.net 的 CNAME，並改為檢查該 SPF 記錄。 因此，如果您查詢的大多數 SPF 記錄都相同，請不要感到驚訝。
有關更多 Twilio SendGrid 特定問題，請查看我們的發件人策略框架文檔頁面。 它對一些常見問題和場景有額外的答案。
如何查看我的 SPF 記錄？
不是每個人都使用 SPF 身份驗證，但是基於 SPF 失敗而拒絕的接收者將拒絕交付。 一些收件人還可以隔離未通過 SPF 的郵件而不阻止它。
每條 SPF 記錄都會有所不同，但您應該檢查以確保正確無誤。 以下三個工具可以幫助驗證您的記錄：
- Scott Kitterman 的 SPF 測試工具：檢查您的域是否已經存在 SPF 記錄，檢查其有效性或測試其性能。
- OpenSPF.org ：查看一系列表單和基於電子郵件的測試人員。
- SPF 記錄檢查： SPF 記錄檢查充當 SPF 記錄查找和驗證器。 它將查找查詢域名的 SPF 記錄，並對記錄運行診斷測試，突出顯示可能影響電子郵件送達率的錯誤。
- SPF 嚮導：SPF 嚮導是一個基於瀏覽器的 SPF 記錄生成工具。 填寫表格，網站會為您生成 SPF 記錄。
將發件人政策框架作為優先事項
簡而言之，惡意電子郵件會損害您的業務並降低電子郵件渠道。 當網絡釣魚者看到您的發件人策略框架保護的域時，他們更有可能轉向更容易的目標。 雖然 SPF 無法阻止垃圾郵件，但它可以起到威懾作用，讓您不易受到攻擊。 誰不想那樣，對吧？ 這就是我們鼓勵所有電子郵件客戶端創建 SPF 記錄的原因。
結合發件人 ID、DKIM 和 DMARC，SPF 提供了額外級別的電子郵件安全性，通過幫助 ISP 正確識別您的電子郵件以及垃圾郵件發送者，將更好地支持您的用戶。