香港郵件送達率：SPF、DKIM 與 DMARC 實操

先說結論： 那些"莫名其妙就消失"的郵件，幾乎都是沒通過一致性校驗（alignment）的郵件。當第三方平台開始以你的域名發送訂單確認或發票時，它必須先在 SPF 裡獲得授權，並且要用與你的域名對齊的 DKIM 簽名——把工具接進收件箱，不等於把它接進了你的 DNS，而這道縫隙正是商業郵件"人間蒸發"最常見的原因。

為什麼訂單郵件突然就不來了？

設想一家香港的消費品牌——一家中型家居生活零售商，二三十到五六十名員工，通過自建官網和幾個電商平台賣貨——把客服系統換成了一套新的第三方支援平台。上線過程很順利：工單分流正常，客服團隊也喜歡新的收件箱界面，運營團隊裡沒有人把這當成一個"郵件項目"，因為在他們看來，這就是一次客服系統升級。

一週之內，投訴開始出現。有客戶打電話來問訂單確認郵件在哪裡；另一位說發票一直沒收到，已經要求重發兩次；一家物流合作方提到，發貨通知郵件進了他們的垃圾郵件箱。乍看之下這不像同一個事故，更像幾件互不相關的小麻煩，運營經理最初幾天也是這麼處理的：這邊當成過濾器抽風，那邊當成客戶手誤。

但這既不是巧合，也不是垃圾郵件過濾器的隨機行為。新平台在發送訂單確認、發票、物流通知這類事務性郵件時，發件地址用的是品牌自己的域名——因為只有這樣，郵件在客戶看來才是"正牌"的。要讓這件事站得住腳，這個平台就必須被你的域名"授權"，就像任何發件方都需要被授權一樣：要麼寫進 SPF，要麼用 DKIM 簽名，理想情況下兩者都要，而且更重要的是，這種授權必須與客戶實際看到的那個域名"對齊"（aligned）。換客服平台的時候沒有人動過 DNS，因為在大多數人眼裡，上線一個客服系統看起來根本不像是一次 DNS 變更。而這篇文章要講的，恰恰就是這道縫隙：新增了一個發件方，卻從沒有把它加進域名的身份驗證配置裡。

這篇文章寫給正對著一堆"你們的發票發了嗎"的留言、而客服平台供應商又說"我們這邊一切正常"的運營或電商經理——從平台的角度看，它確實沒問題，郵件確確實實發出去了。至於發出去之後發生了什麼，那是一個 DNS 問題，而 DNS 恰恰是沒有人認領的那部分。

三條記錄，和真正起決定作用的那個詞：對齊

幾乎所有關於 SPF、DKIM、DMARC 的介紹都停留在"這是你需要的三樣東西"，逐一解釋是什麼，卻跳過了真正決定你的訂單確認郵件能不能送達的那部分。那部分就是"對齊"（alignment）。哪怕三條記錄單獨看都配置正確，只要對齊沒做對，郵件照樣會失敗。

SPF（發件人策略框架） 是你域名下的一條 DNS TXT 記錄，列出哪些郵件服務器有權以你的名義發信。它核對的對象很具體：信封發件人（envelope sender），有時也叫 Return-Path 或 MAIL FROM 地址——這是郵件投遞過程中使用的一個技術字段。這一點值得說清楚，因為幾乎所有科普文章都會漏掉它：SPF 核對的，並不是客戶在收件箱裡看到的那個地址。 它核對的是客戶根本看不到的一個後台地址。一封郵件完全可以順利通過 SPF 校驗，而客戶看到的發件人域名，其實是 SPF 壓根沒提到過的另一個域名。

DKIM（域名密鑰識別郵件） 是附加在外發郵件上的加密簽名，用來核對的公鑰發佈在你的 DNS 裡一個特定位置——由一個"選擇器"（selector）加上你的域名組成，所以用選擇器 s1 在 yourbrand.com 上做的簽名，會去查 s1._domainkey.yourbrand.com 這條 DNS 記錄。簽名證明了郵件在傳輸過程中沒有被篡改，也證明了持有對應私鑰的一方確實發送了這封郵件。關鍵在於，DKIM 簽名"歸功"給誰——簽名裡的 d= 值——完全取決於簽名方選擇以誰的名義簽名，它同樣不需要和可見的發件人地址一致。第三方平台完全可以用自己的域名給自己發的郵件籤上一個技術上完全有效的 DKIM 簽名，這個簽名和你的品牌毫無關係。

這就是為什麼上面兩項各自都對，郵件卻依然會失敗。DMARC（基於域名的消息認證、報告和一致性） 正是用來堵上這道縫隙的記錄。DMARC 本身不引入新的驗證方式——它拿 SPF 和 DKIM 的驗證結果，再多做一步核對：真正通過驗證的那個域名（SPF 的 Return-Path 域名，或者 DKIM 的 d= 域名），是不是和客戶實際看到的發件人地址域名一致，或者足夠接近？這一步叫做標識符對齊（identifier alignment），DMARC 記錄可以用兩種方式要求它。寬鬆對齊（relaxed alignment，通常是預設值）只要求組織域名這一層級一致，所以 mail.yourbrand.com 可以和 yourbrand.com 對齊。嚴格對齊（strict alignment）則要求雙方的完整域名完全相同。只要 SPF 通過且對齊，或者 DKIM 通過且對齊，郵件就能通過 DMARC——兩者滿足其一即可，但至少要有一項是真正"對齊"的，而不只是"驗證通過"。

說得直白一點：你的品牌完全可能同時擁有教科書式的 SPF 和 DKIM 配置，兩者技術上都無懈可擊，卻依然徹底通不過 DMARC——因為真正通過每一項檢查的域名，是平台的域名，不是你的域名。這正是上面那個場景裡發生的失敗方式，也值得再強調一遍，因為幾乎所有倉促的科普都會漏掉這一點：這三條記錄本身不是目的，讓平台的發信行為對齊到客戶看見的那個域名才是目的，記錄只是手段。

新增一個第三方發件方，具體是怎麼把郵件"發丟"的？

先看看新平台上線之前的 DNS 狀態。如果 Microsoft 365 或 Google Workspace 在最初部署時配置得當，通常意味著已經有一條能正常工作的 SPF 記錄，主發信域名上啓用了 DKIM，而如果當初負責部署的人足夠細心，很可能還已經發布了 DMARC 記錄——甚至已經處於強制生效的策略下，因為這如今越來越是一種審慎的預設做法，而不是例外。日常員工郵件順利通過驗證，沒有人會再去想這件事。

接著客服平台上線，被配置成以品牌名義發送訂單確認和發票——因為一封看起來來自某個通用平台域名的郵件，轉化率和可信度都不如一封看起來直接來自品牌本身的郵件。平台的外發郵件服務器從未被加進品牌的 SPF 記錄。平台或許會給自己的郵件簽上 DKIM，但用的是自己的 d= 域名，不是品牌的域名——因為品牌從來沒有為這個平台生成並交付過一對 DKIM 密鑰供它簽名。客戶看到的發件人寫著 orders@yourbrand.com。無論是 SPF 還是 DKIM，都沒有產生一個能對齊到 yourbrand.com 的驗證結果。DMARC 失敗。

接下來發生什麼，完全取決於品牌 DNS 裡早已存在的那條 DMARC 策略——這正是為什麼一個從沒聽說過 DMARC 這個詞的運營經理，反而會成為收拾這場爛攤子的人。如果域名發佈的是 p=reject，收件服務器會直接拒收這封郵件：發件方那邊看不到任何形式的退信提示，訂單確認郵件在客戶的收件箱看來就是根本不存在。如果域名發佈的是 p=quarantine，郵件通常會被投遞到收件人的垃圾郵件或雜件箱——這就解釋了為什麼"我在垃圾箱裡找到了"和"我根本沒收到"這兩類投訴會混在一起出現：兩者是同一個底層失敗，只是落在了處理隔離策略略有不同的收件系統上。如果域名發佈的是 p=none，或者乾脆沒有 DMARC 記錄，郵件送達的概率會更高，但域名對"任何人冒充品牌發送未驗證郵件"這件事也就完全沒有防護——這是另一個問題，本文不打算展開，而是留給下面提到的另一篇文章。

真正正確的修復方式，只有兩種，也只有兩種。想靠"讓平台別用我們的域名發信"來解決送達問題，等於是放棄了品牌化的發件地址，而這通常不是企業想要的結果。能在保留品牌發件地址的同時讓它順利通過驗證的兩種修復方式是：

修復第三方發件方的兩種方式，各自需要做什麼

把平台加進 SPF。 平台文檔通常會為此專門提供一個 include: 值——類似 include:mail.platformname.com。把它加進你的 SPF 記錄，就等於授權該平台的服務器可以使用你的信封域名發信。這是改動較小的一步，但它只解決了 DMARC "二選一"裡的 SPF 那一半——對 DKIM 毫無幫助，而且會讓你離 SPF 的十次查詢上限（見下文）更近一步，如果你已經接入了不少發件方，這一點尤其要注意。
讓平台用對齊到你域名的 DKIM 簽名發信。 這是更穩妥的修復方式，因為 DKIM 對齊即便郵件被轉發也依然有效，也不依賴收件服務器信任郵件走過的那條網絡路徑——而這恰恰是 SPF 的弱點。要做對這一步，通常需要為你的域名生成一對 DKIM 密鑰，把公鑰發佈到平台指定的選擇器下、掛在 _domainkey.yourbrand.com 之下，再把私鑰交給平台用來簽名——如今更常見、也更不容易出錯的做法是，平台直接給你一條 CNAME 記錄，由它自動完成簽名，而不需要你手動處理原始密鑰。

兩者都做並不是過度配置，恰恰相反，這是常態——正因為 DMARC 只需要其中一項通過，同時配置兩者意味著任何一個機制臨時出問題，都不會單獨拖垮你的郵件發送。真正不該做的，也算不上"修復"的做法，是把平台加進 SPF 之後就此打住，還以為"SPF 和 DKIM 反正差不多"。它們核對的是完全不同的東西，可以各自獨立出錯，而 DMARC 的對齊檢查也是分別針對兩者進行的。

不借助任何工具，一份 DMARC 報告到底能告訴你什麼？

DMARC 記錄裡的 rua 標籤——一個寫在你 DMARC DNS 記錄裡的郵箱地址——會要求收件郵件服務器每天給你發一份關於"聲稱來自你域名"的郵件的彙總報告：哪些通過了，哪些失敗了，來自哪裡。這些報告通常以壓縮過的 XML 附件形式送達，哪怕暫時用不上專門的監控工具，光靠手動閱讀幾份報告來排查單次事故，也是完全可行的。

在每份報告裡，最重要的字段是 source_ip，它告訴你郵件實際是從哪台服務器發出的——正是靠這個字段，你才能查出一大批失敗的郵件其實來自客服平台名下的一個 IP 段，而不是什麼可疑來源。緊挨著它的 count 字段，記錄了從這個 IP、以同樣結果發出的郵件數量，這才能把"這個平台好像時不時會出問題"變成"這個平台上週發了 4000 封郵件，其中 3850 封沒通過對齊檢查"這種具體結論。再往下是 policy_evaluated，記錄的是你域名的策略要求收件方對這封具體郵件做什麼處理——它的 disposition（正常投遞記作 none，轉入垃圾箱記作 quarantine，直接拒收記作 reject），以及這封郵件的 dkim 和 spf 評估結果。最後是 auth_results，分別針對 DKIM 和 SPF，顯示實際核對的是哪個域名、結果是否通過——正是在這裡，你能直接看到 DKIM 對 platformname.com 是通過的，而你自己域名的對齊卻失敗了，這是證明"問題出在第三方發件方而不是記錄本身寫錯了"最直接的證據。

最值得盯著看的三個數字，按順序是：某個 source_ip 的總髮信量；這批郵件裡 disposition 不是你期望結果的比例；以及那個未通過驗證的字段裡，auth_results 顯示的域名是不是你認識的發件方。如果是，你就找到了第三方發件方的問題所在。如果不是，你可能發現了別的情況——有人在冒充你的域名發送你從未發過的郵件，這是另一個更嚴重的話題。

DMARC 策略應該多"嚴"？直接設成 reject 會在哪裡出問題？

DMARC 的 p= 標籤有三個取值，構成的是一個有意設計的台階，而不是一個開關。p=none 要求收件方對未通過驗證的郵件不做特殊處理，但仍然給你發報告——這是觀察階段，任何域名都應該從這裡開始，哪怕這個域名已經運行多年、DMARC 策略從來沒人檢查過。p=quarantine 要求收件方把未通過驗證的郵件當作可疑郵件處理，通常投進垃圾郵件箱而不是收件箱。p=reject 要求收件方直接拒收。pct 標籤可以讓這三種處理方式只作用於一定比例的失敗郵件，而不是全部，這正是讓"分階段上線"而不是"一刀切"成為可能的機制。

一個域名如果還有未知的發件方，就絕不應該直接跳到 p=reject，原因正是本文開頭那個場景反過來發生一遍：如果客服平台（或者發票工具、營銷發件方、會發送送貨單的 ERP 系統）還沒有正確完成身份驗證，直接切到拒收並不能解決任何問題——只會讓原本存在的失敗變得徹底而且立刻發生，而且完全看不出是哪個發件方先出的問題。真正管用的順序是：先發布帶報告地址的 p=none，認真讀完一整個正常的業務週期的報告——長到足以覆蓋一次完整的月結、一次營銷發送和日常的訂單量——直到每一個合法發件方都顯示為已驗證且已對齊；然後再切到 p=quarantine，最好從較低的 pct 開始，報告持續乾淨再逐步提高；最後才切到 p=reject。跳過觀察階段，就是在把域名"保護"進一場自己造成的郵件中斷裡。

SPF、DKIM、DMARC 都配置正確之後，還有什麼會悄悄拖累送達率？

把三條記錄的對齊問題解決了，只是排除了最常見的原因，不是唯一的原因。以這類規模的企業來說，還有幾個相鄰的問題經常出現，值得單獨說清楚。

共享發信 IP——常見於一些價格較低的事務性郵件附加服務，以及部分客服平台的外發郵件——意味著你的送達率會部分取決於共享這個 IP 的其他客戶。只要其中一個客戶發的郵件導致這個 IP 被標記，你完全合規的訂單確認郵件也可能被牽連，而這與你自己的域名配置毫無關係。

SPF 查詢次數超限 是同一類問題的慢動作版本，值得專門檢查：SPF 校驗的上限是 10 次 DNS 查詢，計入 include、a、mx、ptr、exists 和 redirect 這幾種機制——一個多年下來陸續接入了營銷平台、電商平台、客服平台、財務系統、快遞通知服務的域名，SPF 記錄很容易在不知不覺中超過這個上限，一旦超限，整條 SPF 檢查就會返回永久性錯誤，實際上等於對記錄裡列出的所有發件方都失去了保護，而不只是最新加進來的那一個。

Return-Path 缺失或配置不當——這是 SPF 真正核對的那個技術地址，區別於客戶看到的發件人地址——可能導致 SPF 核對了一個完全不該核對的域名，尤其是當某個平台用它替你管理的一個子域名發信、而你的團隊從未查看過那個子域名自身的 SPF 狀態時。

以及內容本身看起來像釣魚郵件，這與身份驗證完全無關——發送模式異常、使用了不熟悉的短鏈接服務、或者措辭觸發了收件服務器的內容過濾規則——即便 SPF、DKIM、DMARC 全部順利通過，依然可能被攔截送達，因為身份驗證和內容過濾是兩套獨立的系統，各自對同一封郵件做出判斷。

這件事到底該由誰長期負責？

劃分責任最清晰、也最經得起下一次換平台考驗的方式是：DNS 歸你，平台歸它，日常監控歸負責管理你 Microsoft 365 或 Google Workspace 租戶的那一方。 平台的職責是在自己的文檔裡說清楚，它需要哪個 SPF include 值或者哪條 DKIM CNAME 記錄。而你——或者你的 IT 服務商——的職責，是真正把這條 DNS 記錄改好，確認它已經生效並且解析正確，並在把這次接入當作"完成"之前，從 DMARC 報告裡確認這個平台的郵件確實顯示為已驗證且已對齊。把"供應商說已經配置好了"當成流程的終點、而不做獨立的 DNS 核實，正是這種失敗會在每次新增發件方時反覆出現的原因。

香港品牌處理新發件方接入的三種方式

沒有人負責，只有出問題才會去動 DNS。 平台上線，郵件開始發送，直到客戶投訴，才第一次有人聽說 SPF 或 DMARC 是什麼。這正是把客服平台上線當成一個純客服項目、而不是一個郵件項目所帶來的預設結果，也正是本文場景裡那個品牌所處的位置。
DNS 只在上線那一刻檢查一次，之後再也沒人看過。 通常是當初搭建 Microsoft 365 租戶的那個人，把新平台的 SPF include 加進去就算完事。這能攔住最明顯的問題，卻攔不住"漂移"：某個平台更換了發信基礎設施；一份沒人讀的 DMARC 報告，本可以提前顯示出另一個不相干的發件方正在悄悄失敗；SPF 查詢次數隨著這一年陸續接入更多工具，一點點逼近上限。
DNS 變更納入管理型服務流程，DMARC 報告真的有人在讀。 每一個新發件方在正式上線前都會先完成身份驗證並對照報告核實，SPF 記錄會定期檢查是否接近查詢上限，DMARC 策略也會被有意識地逐步推進——先 none，再 quarantine，最後 reject——而不是停留在當初隨手設定的那個狀態。這是三種方式裡唯一能在客戶之前先發現第二個失敗發件方的做法。

Brocent 在這方面做什麼，這和防欺詐有什麼不同？

有必要說清楚這篇文章和另一篇密切相關的文章之間的區別，因為兩篇都在講 SPF、DKIM、DMARC，講的卻不是同一個問題。我們關於香港一家批發商險些遭遇供應商付款欺詐的文章講的是相反的方向：郵件從外部發到你這裡，看起來來自真實的供應商，要求你把款項付到一個不同的銀行帳戶。那篇文章裡對 SPF、DKIM、DMARC 的討論，說的是這些記錄能在多大程度上阻止別人冒充某個發件人向你發信、又在哪些地方無能為力。而這篇文章說的是你自己的外發郵件送不到自己客戶手裡——原因是你自己新接入的一個發件方，從來沒有被正確地做過身份驗證。同樣的三條 DNS 記錄，同樣的底層機制，方向相反，修法也不同。

Brocent 的管理型IT雲服務直接覆蓋了 Microsoft 365 這一側：部署時就把 Exchange Online 配上 SPF、DKIM、DMARC，同時通過 Microsoft Defender for Microsoft 365 啓用安全鏈接、安全附件和反垃圾郵件——標準上線流程裡的身份體系搭建這一步，從第一天起就包含為域名配置 SPF 與 DMARC，而不是等到某個第三方發件方把這個缺口暴露出來才去補。如果企業需要的是反釣魚、身份冒充檢測這一側，而不是身份驗證記錄這一側，這屬於管理型電郵安全的範疇——在 Microsoft 365 或 Google Workspace 環境前疊加反釣魚與商業郵件欺詐檢測、勒索軟件與惡意軟件攔截，以及隔離管理。這兩項服務在這裡都相關，但原因不同：雲服務這一側是從一開始就把你自己的身份驗證配對；電郵安全這一側解決的是當你開始擔心"郵件從另一個方向打過來"時的問題——那正是上面鏈接的那篇文章在講的事，而不是這篇。

不管選擇哪項服務，都無法替你自動完成某個具體第三方平台的身份驗證——總得有人真正去讀那個平台的文檔，按它的要求完成 DNS 變更，這一步永遠是針對具體發件方的，沒有哪種管理型IT外判服務能替代它。外判關係真正改變的，是事後有沒有人在持續盯著 DMARC 報告，以及 SPF 記錄會不會在悄悄逼近查詢上限之前被人發現。

常見問題

為什麼我們的郵件之前一直正常，突然就不行了？

幾乎總是因為有一個新的發件方被接入到你的域名外發流程裡——客服平台、營銷工具、開票系統——卻沒有同步修改 SPF 或 DKIM。域名原有的郵件，直接來自 Microsoft 365 或 Google Workspace 的那部分，驗證結果和以前一模一樣；只有新發件方發出的郵件會失敗，這也是為什麼問題看起來是"時好時壞"，而不是徹底不通。

我們把平台加進 SPF 記錄就夠了嗎？

有幫助，但那只是 DMARC 檢查的一半。SPF 通過且對齊是滿足 DMARC 的一種方式，DKIM 通過且對齊是另一種。只把平台加進 SPF，意味著你完全依賴 SPF 對這個發件方持續有效——包括郵件實際經過的網絡路徑——一旦哪個環節出問題，又沒有 DKIM 簽名兜底。更穩妥的做法是兩者都配置。

DKIM 對齊具體是什麼意思？

DKIM 對齊指的是：一個有效 DKIM 簽名"歸功"給的那個域名——也就是簽名頭裡的 d= 值——和客戶看到的發件人地址所在的域名一致，或者在寬鬆對齊的規則下，至少屬於同一個組織域名。一個平台完全可以整天用自己的域名給自己的郵件簽上技術上有效的 DKIM 簽名；除非它是以你的域名簽名，否則這些簽名沒有一個對你來說是"對齊"的。

這類 DNS 變更真的需要多久才能生效？

DNS 記錄本身通常在幾分鐘到幾個小時內就會生效，具體取決於被替換那條記錄原來設定的 TTL（生存時間）。出於規劃考慮，更穩妥的做法是預留 24 到 48 小時再判斷變更是否成功，並且直接用 DNS 查詢工具核實這條記錄，而不是隻靠"客戶是不是還在投訴"來判斷。

我們應該把 DMARC 策略設成 p=reject 嗎？

最終應該達到這一步，前提是能安全地走到那裡——但不應該作為第一步動作，也不應該在還有發件方尚未完成身份驗證的情況下這麼做。安全的順序是先 none，再 quarantine，最後 reject，只有在 DMARC 報告顯示每一個合法發件方都通過驗證且已對齊之後，才進入下一階段。在還有未核實發件方的域名上直接跳到 reject，很可能會悄無聲息地攔下你本來最想保護的那部分郵件。

我們需要專門的 DMARC 監控服務嗎，還是自己看報告就行？

如果只是排查單次事故，像上文那樣手動讀幾份彙總 XML 報告完全可行。但如果域名長期接入多個第三方發件方，並且打算逐步走向 p=reject，一個監控服務，或者一個真的會按計劃審閱報告的管理型IT服務商，能比不定期的人工檢查更早發現"漂移"——比如後來新加的發件方，或者某個平台悄悄更換了發信基礎設施。

這只是 Microsoft 365 才有的問題嗎，其他平台會不會也這樣？

不管你的主力郵箱平台是什麼，機制都完全一樣——SPF、DKIM、DMARC 是互聯網標準，不是 Microsoft 或 Google 的專屬功能。本文描述的場景，在 Google Workspace 上或者任何其他郵件平台上，只要接入了一個沒有同步做 DNS 配置的第三方發件方，都會以完全相同的方式發生。

企業內部到底應該由誰來負責我們的 DNS 和這套配置？

責任應該落在日常管理 Microsoft 365 或 Google Workspace 租戶的那一方——內部 IT，或者一家管理型IT外判服務商——而不是營銷部門、電商運營部門，或者恰好是簽下那個觸發問題的平台的那個部門。平台供應商能告訴你它需要什麼；但只有真正掌控域名 DNS 的那一方，才能核實變更做對了，並且在未來不斷接入新發件方的過程中持續保持正確。

在下一次換平台之前，先把責任劃清楚

本文場景裡的這個品牌，既沒有安全問題，也沒有平台問題——客服平台的表現完全符合設計預期。它出的是一個責任缺口：一次本該伴隨產品上線同步進行的 DNS 變更，卻沒有人把這兩件事聯繫在一起、意識到需要去做。修復眼前這次失敗，只需要一次 DNS 變更加上幾天讀報告的工夫。修復這個模式本身，則需要一次性地定下來：以後每接入一個新發件方，由誰負責檢查身份驗證和對齊——趕在下一個客服平台、營銷工具或開票系統悄悄重演同一個失敗之前。

如果你的團隊正在處理最近換了平台或供應商之後開始消失的郵件，或者希望在下次改動之前先把 DNS 和 DMARC 報告認真核查一遍，歡迎聯繫我們的團隊。如果你想先了解這如何融入一套管理型 Microsoft 365 方案、成本大概是多少，我們的定價頁面和按用戶計費的管理型IT外判方案說明了具體模式。