在新網域上設定郵件：20 分鐘搞定 SPF、DKIM 和 DMARC 的清單（2026）

發布於 2026-07-08

資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。

一個新網域在發出第一封郵件之前需要四樣東西：一次基線掃描、一條寫明你真實服務商的 SPF 記錄、自定義網域的 DKIM 簽名，以及一條從第一天就開啟報告的 DMARC 記錄。大多數網域從未走到這一步——根據 Defaults.Exposed 普查（截至 2026-06-29），46.4%（261,086,232 個已評分網域中的 121,145,609 個）根本沒有 SPF。

把所有記錄發布完大約需要 20 分鐘：掃描拿基線、新增一條 SPF 記錄、開啟服務商的自定義網域 DKIM、發布帶報告位址的 DMARC p=none、可選加上 MTA-STS，然後重新掃描並保存報告。更花時間的是任何清單都无法催促的兩件事——DNS 傳播和發送信誉——本指南對這兩點都實話實說。

20 分鐘真的夠嗎？

對於發布記錄，夠——下面每一步都只是一條 DNS 記錄加上服務商管理控制台裡的几次點擊。有兩件事更花時間，假装不是這樣，正是新網域落進垃圾箱的原因：

傳播。 新記錄通常几分鐘內就能解析，但解析器會按 TTL 快取，一個剛完成委托的網域可能要几小時才能稳定應答。用 dig 驗證；別在快取追赶期間慌張地反復改。
預熱。 新網域的發送信誉為零，而驗證是信誉的前提條件，不是替代品。從低的、人類尺度的發送量開始，用數周時間逐步爬升。

誠實的說法是：20 分鐘買到的是正確發布的驗證。之後几周的理性發送買到的才是送達率。

20 分鐘清單

先在 defaults.exposed 執行免費掃描。 在動 DNS 之前掃描新網域。“一切未設定”的評分基線几秒鐘就能記錄下來，並讓之後的報告有意義——你會需要這對前後對比（第 6 步）。
為你實際使用的服務商發布一條 SPF 記錄。 恰好一條以 v=spf1 開头、包含你服務商 include 的 TXT 記錄——例如 Google Workspace 用 v=spf1 include:_spf.google.com ~all，Microsoft 365 用 include:spf.protection.outlook.com；如果你的 DNS 托管在註冊商面板，GoDaddy 教程覆蓋了界面上的怪癖。只能有一條：兩條 v=spf1 記錄是永久性錯誤，會讓 SPF 完全作廢——1,013,416 個網域正卡在這個狀態裡，約占嘗試設定 SPF 的網域的 138 分之一（普查截至 2026-06-29），通常是遷移殘留。不要“以防萬一”地乱加 include：SPF 把 DNS 查詢上限定為 10 次，至少已有 797,263 個網域因為爆掉這個上限而讓記錄作廢。還要清楚 SPF 實際檢查的是什麼：接收方是拿 Return-Path（RFC5321.MailFrom）網域——退信位址——來評估它的，不是收件人看到的 From 標头。
開啟自定義網域的 DKIM 簽名。 你的服務商反正都會給郵件簽名；問題在於簽名寫的是哪個網域。在你完成這一步之前，Google Workspace 用它的 gappssmtp.com 默認名義簽名，Microsoft 365 用 onmicrosoft.com——這些簽名 DKIM 能通過，却不與你的網域對齊，DMARC 照樣失敗。在管理控制台生成金鑰並發布服務商給你的內容：Google 是一條 2048 位的 TXT 記錄，Microsoft 365 是兩條 CNAME（selector1/selector2）。如果記錄塞不進你的 DNS 面板，見修復 DKIM——長金鑰被界面弄壞是經典問題。
從第一天起發布 DMARC——帶報告位址的 p=none。 在 _dmarc.yourdomain.com 新增一條 TXT 記錄：v=DMARC1; p=none; rua=mailto:[email protected]。要清楚這條記錄做什麼：p=none 目前什麼都不保護——它是監控模式。但它零成本，而且彙總報告從此覆蓋你網域從第一封郵件起的全部發送歷史。老網域要花數周的報告時間才能挖出被遗忘的發件方；你從第零天起就免費買到了這份可見性。記錄的結構详見修復 DMARC。
可選但在新網域上很便宜：MTA-STS 和 TLS-RPT。 MTA-STS 告訴發送伺服器你的網域要求入站郵件使用 TLS（一條 DNS 記錄加一個小的托管政策文件）；TLS-RPT 報告投遞加密失敗。在老網域上這兩項需要小心；在只有一家郵件服務商的新網域上沒有什麼可弄壞的，mode: testing 基本零風險。現在配上或者跳過——但要做決定，別放任漂移。
重新掃描並保存報告。 再次執行掃描——SPF、DKIM 和 DMARC 應該都顯示綠色。保存這份評分報告：網域上線時狀態的帶日期凭證，也正是保險公司或客戶問卷會要的東西。

到底有多少網域完成了這份清單？

非常少——而且大多數倒在第一道坎上。在 Defaults.Exposed 普查評分的 261,086,232 個網域中（截至 2026-06-29）：

清單裡程碑	普查現實（261,086,232 個已評分網域，截至 2026-06-29）
第 2 步——發布任意 SPF 記錄	46.4% 從未做過：121,145,609 個網域完全沒有 SPF
第 4 步及以後——DMARC 達到強制執行政策	10.59%（27,640,987 個網域）；89.41% 沒有強制執行的政策
完整三件套——SPF + DKIM + 強制執行的 DMARC	3.87%（10,092,481 個網域）

本頁描述的這 20 分鐘，能讓一個全新網域在完整三件套上領先互聯網上大約 96% 的網域。SPF 採用成熟度模型拆解了這架梯子的每一級。

新網域多快能達到 p=reject？

數周，而不是數月——這正是從零開始的真正优勢。讓 DMARC 強制執行在老網域上進展緩慢的是歷史包袱：被遗忘的 CRM 連線器、某人在 2019 年接上的開票工具、沒人記錄在案的郵件通讯平台。每一個都得先在報告裡被找出來並修好，政策才能收紧——所以標準的推進周期長達數月。

新網域沒有歷史發件方：每一個發送來源都是你自己本周親手設定的，第 4 步的報告會印證這一點。用兩到四周的真實發送跑 p=none，核對報告覆蓋了你實際使用的一切（郵箱、發票、回执、網站的聯繫表單），然後升到 p=quarantine，報告干淨後再升到 p=reject。分階段的操作細節——pct 爬坡、子網域政策、要盯什麼——都在從 p=none 到 p=reject裡；在新網域上你會快速走完這些階段，抵達只有 10.59% 已評分網域到達過的地方。

你正在替換的那個舊網域怎麼辦？

如果這個新網域是品牌重塑的一部分，你留下的那個舊網域現在就是你最大的郵件風險：仍然歸你所有，仍被合作方信任，却不再有人盯著。別棄之不管——明確地把它鎖死。那是另一件小活：你改名後留下的舊網域，是一扇沒關的門。

常見問題

還沒選好郵件服務商，能先發布這些記錄嗎？ DMARC 可以——帶 rua 的 p=none 與服務商无關，註冊當天就發布。SPF 需要你服務商的 include；在選定之前，先發布 v=spf1 -all（不授權任何人發送），第 2 步時再替換。這嚴格好於 121,145,609 個網域所處的无記錄狀態（占 261,086,232 個已評分網域的 46.4%，截至 2026-06-29）。

SPF 已經通過了，還需要 DKIM 嗎？ 需要。SPF 在轉發場景下按設計就會失效，而且它驗證的是 Return-Path 網域——對很多工具來說那不是你的網域——對齊的 DKIM 才是兩種情况都扛得住的那條腿。只有 3.87% 的已評分網域完成了 SPF+DKIM+強制執行 DMARC 的完整三件套（普查截至 2026-06-29）；DKIM 是半途而廢者最常跳過的一步。如果掃描標出了它，從修復 DKIM開始。

新網域該用 ~all 還是 -all？ 在老網域上，~all 是排查被遗忘發件方期間的稳妥選擇。新網域沒有可找的發件方：一旦服務商的 include 已就位、DKIM 已在簽名，-all 早得多就是安全的。想再上一道保險？先用兩周干淨的 DMARC 報告確認。

三條記錄都通過了——為什麼我的郵件還是進垃圾箱？ 因為驗證和信誉是兩碼事：記錄通過意味著接收方能驗證郵件確實出自你手，不代表他們已經信任你。新網域靠持續發送對方想要的、低量的郵件並逐步爬升來贏得信任。如果郵件是沒通過檢查而不只是落進垃圾箱，從修復 SPF開始，順著掃描結果逐項處理。

把報告發給老板

如果你是在替客戶設定這個網域，用證據收尾。第 6 步之後重新執行免費掃描，把評分報告轉發給企業負責人：SPF、DKIM 和 DMARC 全部通過，直白語言，上線當天的日期。這正是他們在網路保險續保和下一份供應商安全問卷時需要的凭證——它也證明這個網域從出生起就做到了互聯網上 96% 的網域從未做到的事。

檢查你的網域 → · 從 p=none 到 p=reject 而不丢失正常郵件 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。