網站的訂單通知寄出去，客戶卻說沒收到；自己用網域信箱寄信給對方，信卻安靜地躺在垃圾郵件匣。這不是主機壞了，多半是寄件網域少做了幾筆 DNS 設定。自從 Google 與 Yahoo 在 2024 年針對大量寄件者公布新規範後，沒有完成寄件者身份驗證的信件，被過濾或直接退回的機率明顯升高。

要讓主機寄出的信穩定進到收件匣，關鍵落在四筆 DNS 記錄：MX、SPF、DKIM、DMARC。這篇會把每一筆的角色、設定值、設定順序講清楚，並補上多數教學略過的兩個地雷——SPF 的查詢次數上限，以及決定 DMARC 成敗的「對齊」。最後會回到 WordPress 與 WooCommerce 網站的實際情境，說明為什麼這類站台寄信特別容易掉進垃圾桶，又該怎麼補。

信件進垃圾桶的根本原因與這四筆記錄的分工

信會被當成垃圾郵件，核心原因是收件伺服器無法確認「這封信真的是這個網域授權寄出的」。電子郵件協定設計得很早，本身沒有寄件人驗證機制，任何人都能在寄件欄填上別人的網域，這也是詐騙信能偽裝成銀行、政府或你老闆的根本漏洞。

為了補上這個漏洞，業界發展出三筆負責「寄信驗證」的 DNS 記錄，再加上一筆負責「收信路由」的 MX，四者分工如下。

把它拆成兩條線會更好記：MX 管「別人怎麼把信送進來」，SPF、DKIM、DMARC 管「你寄出去的信會不會被信任」。很多人卡在垃圾桶問題，是因為只設了 MX 把信箱收信打通，卻沒處理寄信端的三筆驗證。

MX 記錄負責收信，跟寄信驗證是兩回事

MX（Mail Exchange）記錄的作用是指路。當別人寄信到 you@yourdomain.com，對方的伺服器會先查詢 yourdomain.com 的 MX 記錄，得知該把信投遞到哪一台郵件主機。沒有 MX，網域就收不到信。

MX 記錄會帶一個優先順序數字，數字越小優先級越高。設定多筆 MX 時，寄件方會先試最小數字那台，連不上才往下一台找，常用來做備援。

要特別澄清一個常見誤解：MX 設得再完整，也不會幫你寄出去的信加分。收件端判斷你寄的信可不可信，看的是 SPF、DKIM、DMARC，不是 MX。若用的是 Google Workspace 或 Microsoft 365 這類代管信箱，它們會給你一組固定的 MX 值照填即可；真正要花心思的是接下來的三筆。

SPF 記錄怎麼設定，以及最容易踩的查詢上限

SPF（Sender Policy Framework）是一筆 TXT 記錄，用途是宣告「哪些伺服器可以代表我的網域寄信」。收件伺服器收到信時，會比對寄件來源的 IP 是否落在你公告的清單裡，不在清單上的就有很高機率被標成垃圾郵件。

設定方式是在 DNS 後台新增一筆 TXT 記錄，主機名稱填網域本身（多數平台填 @），值的部分是這樣的格式。

v=spf1 include:_spf.google.com ~all

逐段拆解這筆記錄的意思：

• v=spf1：宣告這是 SPF 第一版，固定開頭。
• include:_spf.google.com：授權 Google 的寄信伺服器代你發信，換成其他服務就改成對方提供的 include 值。
• a 與 mx：分別授權網域的 A 記錄主機、MX 主機寄信，自架主機常會用到。
• ip4:123.123.123.123：直接授權某個固定 IP 或 IP 範圍寄信。
• ~all 或 -all：放在最後，處理「清單以外的來源」。~all 是軟性失敗，標示可疑但通常仍會收下；-all 是硬性拒絕，安全性較高但設錯就會把自己的信擋掉。剛上線建議先用 ~all 觀察，確認來源都列齊了再收緊成 -all。

兩個多數教學沒講、但實務上很常踩的限制要記住。

第一、一個網域只能有一筆 SPF 記錄。 若你同時用 Google Workspace 收發、又用第三方平台寄電子報，不能各開一筆 SPF，而要把來源併進同一行。

v=spf1 include:_spf.google.com include:spf.thirdparty.com ~all

第二、SPF 有「10 次 DNS 查詢」上限。 每個 include、a、mx 在驗證時都會觸發一次以上的 DNS 查詢，總數超過 10 次，SPF 會直接被判定為 permerror（永久錯誤），等於整筆失效。串接的服務一多就容易超標，所以 SPF 不是把所有 include 通通塞進去就好，要控制串接的服務數量。

SPF 設定後通常需要數小時到 24 至 48 小時讓 DNS 生效，期間可以用 MXToolbox 這類查詢工具確認是否已被外部讀到。

DKIM 數位簽章的設定流程與金鑰長度選擇

DKIM（DomainKeys Identified Mail）做的是 SPF 做不到的事——證明信件內容在傳遞過程中沒被竄改。它的原理是非對稱加密：寄件伺服器用一把「私鑰」幫每封信加上數位簽章，並把對應的「公鑰」放在你網域的 DNS。收件伺服器收到信後，用 DNS 上的公鑰去驗證簽章，對得上就代表這封信確實出自你、內容也完整。

SPF 只能證明來源 IP 合法，沒辦法保證內容沒被改；DKIM 補的正是這一塊，所以兩者要一起做，不是二選一。

DKIM 的設定流程依寄信服務略有差異，但骨架一致：

• 第一、在寄信服務的後台產生金鑰。 不論是 Google Workspace 的管理控制台、Microsoft 365，或自架的郵件伺服器，都會有一個產生 DKIM 金鑰的功能，產出一段公鑰字串與一個 selector（選擇器，例如 google 或 default）。
• 第二、把公鑰貼進 DNS。 新增一筆 TXT 記錄，主機名稱通常是 selector._domainkey（例如 google._domainkey），值就是後台給你的整段公鑰字串。有些代管服務改用 CNAME 指向服務商網域，效果相同。
• 第三、回後台啟用驗證。 DNS 生效後，回到寄信服務後台按下啟用或驗證，狀態顯示為已啟用就代表簽章開始運作。

產生金鑰時若有長度選項，選 2048 位元。較舊的郵件主機只支援 1024 位元，但 1024 安全性偏低，現行環境只要對方支援都建議用 2048。

設定完成後，可以從你的網域寄一封信到 Gmail，打開信件後點選「顯示原始郵件」，就能看到 DKIM 的驗證結果是 PASS 還是 FAIL。

DMARC 政策從 p=none 到 reject 的漸進上線步驟

DMARC（Domain-based Message Authentication, Reporting and Conformance）是整合 SPF 與 DKIM 的策略層。它做兩件事：定義「當 SPF 或 DKIM 沒通過時，收件方該怎麼處理這封信」，以及「把驗證結果定期回報給你」。

務必先把 SPF 與 DKIM 設定好、驗證通過，再來開 DMARC。順序顛倒的話，DMARC 會依據還沒設好的驗證結果去處置信件，很可能把自己的正常信擋掉。設定方式是在 DNS 新增一筆 TXT 記錄，主機名稱填 _dmarc。

DMARC 的核心是 p（policy）這個參數，它有三段，建議照下面的節奏分階段上線，而不是一步到位。

• 第一階段、p=none（觀察）。 不對任何信件採取行動，只收集報告。先用這段把所有合法的寄信來源摸清楚，確認它們都能通過驗證。一筆基本的觀察模式記錄長這樣：

v=DMARC1; p=none; rua=mailto:dmarc-report@yourdomain.com;

其中 rua 是接收彙整報告的信箱，務必填，這是你後面判斷能不能收緊政策的唯一依據。

• 第二階段、p=quarantine（隔離）。 觀察一段時間、確認沒有合法來源被誤判後，改成隔離。沒通過驗證的信會被丟進收件方的垃圾郵件匣，而不是直接消失，屬於中間地帶。
• 第三階段、p=reject（拒收）。 確認一切穩定後再升到最嚴格的拒收，未通過驗證的信會被直接退回、根本進不了收件方。這也是 Google 與 Yahoo 對大量寄件者最終期望的狀態。

跳過 none 直接上 reject 是最常見的災難——你還沒摸清自己有哪些寄信來源，就先把沒對齊的那些通通擋死，結果往往是某個第三方平台寄的正常通知信全被退回。

對齊才是 DMARC 通過與否的關鍵

這是多數教學最常略過、卻最常害人卡關的環節。SPF 通過、DKIM 也通過，DMARC 卻還是 FAIL，幾乎都是「對齊」（alignment）出問題。

DMARC 不只看 SPF 與 DKIM 有沒有過，還要求驗證所用的網域，必須跟使用者實際看到的寄件人網域「一致」。舉例來說，你的寄件人地址是 service@yourdomain.com，但第三方平台幫你寄信時用的是它自己網域的簽章，這種情況下 SPF/DKIM 各自可能都 PASS，但因為驗證網域跟寄件人網域對不起來，DMARC 仍判定 FAIL。

對齊分兩種模式，由 DMARC 記錄裡的 aspf 與 adkim 控制：

• 寬鬆對齊（r，relaxed）：只要主網域相同就算對齊，子網域之間也通過。這是預設值，相容性最好。
• 嚴格對齊（s，strict）：寄件網域必須完全一致才算對齊，子網域不算。安全性高但容易誤擋。

一筆帶寬鬆對齊的 DMARC 記錄長這樣：

v=DMARC1; p=none; rua=mailto:it@yourdomain.com; aspf=r; adkim=r;

實務上的處理原則很單純：用第三方平台寄信時，務必依該平台指示，讓寄出的信以「你自己的網域」做 DKIM 簽章（多半是設定一筆指向平台的 CNAME），而不是用平台預設的網域。這樣 DKIM 的驗證網域才會跟寄件人網域對齊，DMARC 才會真正 PASS。

還有一個延伸情境要留意：同一個網域若有多個寄信來源——例如公司自己的郵件主機、第三方電子報平台、再加上網站主機的自動通知信——這幾個來源都必須各自完成 SPF 與 DKIM 並與寄件網域對齊。只要漏掉其中一個，等 DMARC 升到 quarantine 或 reject 後，那個沒對齊的來源寄出的信就會被隔離或退回。

WordPress 與 WooCommerce 網站寄信為什麼特別容易掉垃圾桶

架在主機上的 WordPress 網站有個先天問題：它預設用 PHP 的 mail() 函式，透過主機本機直接寄信。這種寄法幾乎一定通不過驗證，原因有兩個。

一是寄信來源往往是主機的共用 IP，這個 IP 不在你網域的 SPF 清單裡，SPF 直接 FAIL。二是 PHP mail() 不會做 DKIM 簽章，DKIM 也無從通過。對 WooCommerce 來說影響更直接——訂單確認信、出貨通知、會員密碼重設信全靠這條管道寄出，掉進垃圾桶等於客戶收不到訂單狀態，是會實際影響交易的問題。

要解決，方向是讓網站改用「有完成驗證的管道」寄信，而不是靠主機本機硬寄。常見做法是裝一個 SMTP 外掛，把網站寄信轉接到正規的郵件服務或交易型郵件平台，再到 DNS 把該服務的 SPF 與 DKIM 設好、對齊妥當。

挑選寄信管道時，可以從這幾點判斷：

• 能不能用自己的網域做 DKIM 簽章：能，DMARC 對齊才過得了，這是最該優先確認的。
• 是否提供現成的 SPF include 與 DKIM 設定值：有，照貼進 DNS 即可，省去手動拼湊。
• 寄送量級與信譽管理：交易型郵件服務通常會替你管理發信 IP 的信譽，比共用主機 IP 穩定得多。

對沒有專職 IT 的小型網站，有些寄信服務還提供「單一寄件人驗證」這類折衷方案：指定一個能收信的寄件地址，收到服務寄來的認證信後點擊連結完成確認。它不屬於 SPF/DKIM/DMARC 的 DNS 驗證，原理是讓寄信平台替你背書、把你的寄件人標記為已確認的合法來源，藉此提高進收件匣的機率。能完整設好三筆 DNS 驗證仍是最穩的，這類方案適合當過渡。

若網站涉及線上收款，金流串接本身有獨立的串接流程，這裡不展開；但要提醒的是，訂單與付款相關的通知信同樣走上述寄信管道，驗證沒設好一樣會掉垃圾桶，別只顧金流而忽略了通知信的送達率。

設定完成後怎麼驗證與讀懂 DMARC 報告

四筆記錄都設好後，別急著當作完工，要實際驗一遍。最快的方式是從你的網域寄一封測試信到 Gmail，打開信件點「顯示原始郵件」，畫面上會列出 SPF、DKIM、DMARC 各自是 PASS 還是 FAIL，一眼就能抓出哪一筆還沒過。

要查 DNS 記錄本身有沒有正確發布、有沒有踩到 SPF 查詢上限，可以用 MXToolbox 這類線上工具，輸入網域就能逐筆檢視。DNS 變更後通常要等數小時、最長 48 小時才會在全球完整生效，剛改完查不到屬正常，等一段時間再驗。

真正讓 DMARC 發揮長期價值的，是那個 rua 收到的彙整報告。報告是 XML 格式，會列出「有哪些 IP 用你的網域名義寄信、各通過或沒通過驗證」。讀它的重點有兩個：

• 有沒有你不認得的 IP 在用你的網域寄信：有，代表可能遭冒名，或有某個你忘記的合法來源沒設好。
• 你已知的合法來源是不是都 PASS：在把政策從 none 升到 quarantine、再升到 reject 之前，要靠這份報告確認所有正常來源都已通過，才不會升級後誤擋自己的信。

報告的 XML 直接讀並不好懂，市面上有不少 DMARC 報告解析服務會把它轉成易讀的圖表，量大時值得用。把這個觀察循環跑順，就能安心地把政策一路收緊到最嚴格的等級。

從收信到寄信，把這套驗證維持在綠燈狀態

把四筆記錄收束成一條動線：先用 MX 打通收信，再用 SPF 宣告誰能代你寄信、用 DKIM 替每封信蓋上防偽簽章，最後用 DMARC 訂下處置規則並收報告監控。順序上 SPF 與 DKIM 先行、DMARC 殿後，政策從 p=none 觀察起步，確認對齊無誤再逐步升到 reject。

接下來該做的，是現在就用 MXToolbox 查一次你網域的這四筆記錄，缺哪筆補哪筆；如果你的網站是 WordPress 或 WooCommerce，優先把寄信改接到能用自家網域簽章的 SMTP 管道，再回頭對齊 DNS。設定不是一次性的——每新增一個寄信來源，都要回來把它的 SPF 與 DKIM 補上、確認對齊，才能讓信件長期穩定停在收件匣，而不是垃圾桶。