「我寄的報價單你們沒收到嗎？」「奇怪，客戶說有寄，但我信箱裡完全沒有。」

這種對話每天都在中小企業裡上演。更麻煩的是，多數人第一時間會怪主機商或信箱系統，實際上有很高的比例是網域的郵件驗證沒設定好——你的信在對方的伺服器眼中「看起來像偽造的」，於是被直接丟進垃圾信匣，甚至連退信通知都不會有。

這篇文章會帶你分辨問題出在哪一端，然後完整走過 SPF、DKIM、DMARC 三項設定，最後教你怎麼驗證有沒有設對。

先分辨：是「收不到」還是「被判垃圾信」

這兩件事的成因完全不同，先分清楚可以省下大量瞎忙的時間。

狀況一：你收不到別人寄來的信

問題出在你這一端。可能的原因：

• 信箱空間滿了，伺服器直接拒收（可在 cPanel 的「磁碟使用量」確認）
• 信被你自己的垃圾郵件過濾器攔下
• 網域的 MX 記錄設錯，信被送到別台伺服器
• 信箱帳號根本沒建立（例如剛搬完主機，可對照〈主機搬家後常見的 6 個問題〉的問題一）

請對方查看有沒有收到退信通知，那封退信裡的錯誤代碼通常會直接說明原因。

狀況二：你寄出去的信被對方當垃圾信

問題出在你的網域設定，這就是本文的主題。典型症狀是：寄給 Gmail 的信進了垃圾信匣、寄給某些公司信箱直接消失、或是對方回報「你的信被標示為可疑」。

快速自我檢查：用你的公司信箱寄一封信到自己的 Gmail。如果進垃圾信匣，或者信件上方出現任何警告標示，那就是驗證設定的問題。

為什麼會被判垃圾信？三道驗證關卡

電子郵件的協定設計於 1980 年代，當時沒有考慮防偽問題——任何人都可以宣稱自己是任何人。你現在就能寄一封信，把寄件人寫成任何一家公司的老闆，協定本身不會阻止你。

為了對抗這個漏洞，後來發展出三道驗證機制。收信方的伺服器會依序檢查：

• SPF——這封信是從你授權的伺服器寄出的嗎？
• DKIM——這封信的內容在傳送途中被竄改過嗎？
• DMARC——如果前兩項沒通過，你希望我怎麼處理？

三項都設定完成且通過，你的信才會被視為「可信任的寄件者」。

要注意的是，這已經不是「有做比較好」的選配項目。Gmail 與 Yahoo 從 2024 年起要求大量寄件者必須設定 SPF、DKIM 與 DMARC，未通過的郵件會被拒收或直接歸類為垃圾信。一般中小企業的寄信量雖然未必達到門檻，但驗證標準只會越來越嚴，早設定早安心。

SPF：宣告誰可以用你的網域寄信

SPF（Sender Policy Framework）是一筆 DNS 的 TXT 記錄，內容是一份白名單，列出哪些伺服器有權以你的網域名義寄信。

怎麼設定

SPF 記錄設定在網域的 DNS，不是在信箱裡。如果你的網域和主機在同一家，通常在 cPanel 的「電子郵件驗證」或「區域編輯器」就能處理；如果網域託管在別處（例如 Cloudflare 或另一家註冊商），要到那邊去設。

一筆典型的記錄長這樣：

類型：TXT
名稱：@（或你的網域）
內容：v=spf1 include:_spf.你的主機商.com ~all

其中 include: 後面的值由主機商提供，不要自己猜。如果你同時使用其他寄信服務（例如電子報平台、CRM 系統），它們的值也要一起加進同一筆記錄裡。

結尾的 ~all 和 -all 差在哪

• ~all（軟性失敗）——不在名單上的來源，標記為可疑但仍可能收下。
• -all（硬性失敗）——不在名單上的一律拒收。

建議先用 ~all。直接上 -all 的風險是：萬一你漏掉某個真的在用的寄信服務，那個管道寄出的信會全部被退，而你可能好幾天後才發現。等確認名單完整、運作正常，再考慮改成 -all。

兩個最常見的 SPF 錯誤

錯誤一：設了兩筆 SPF 記錄。這是最常見也最致命的錯誤。一個網域只能有一筆 SPF 記錄，有兩筆的話驗證會直接失敗——比完全沒設還糟。

發生原因通常是：原本已經有一筆，後來換主機或加了電子報服務，又新增一筆。正確做法是把所有 include 合併到同一筆：

v=spf1 include:_spf.主機商.com include:_spf.電子報平台.com ~all

錯誤二：DNS 查詢次數超過上限。SPF 規範限制驗證過程中最多執行 10 次 DNS 查詢，每個 include 至少算一次，而有些服務商的 include 內部還會再展開好幾層。塞了五六個服務就可能爆掉，一旦超過，整筆 SPF 直接視為失敗。

如果你真的需要授權很多個寄信來源，得靠 SPF 展平工具或改用子網域分流，這部分建議請主機商協助處理。

DKIM：幫每封信蓋上防偽印章

DKIM（DomainKeys Identified Mail）的原理是數位簽章。你的伺服器在寄出每封信時，用私鑰加上一段簽章；收信方用你公開在 DNS 上的公鑰去驗證。簽章對得上，代表這封信確實出自你的網域，而且內容在途中沒有被改過。

怎麼設定

好消息是這一項通常不用手動算。在 cPanel 的「電子郵件驗證」頁面，找到你的網域，點「安裝建議的記錄」，系統會自動產生金鑰並寫入 DNS。

如果你的 DNS 託管在別的地方（Cloudflare、網域註冊商），cPanel 會顯示一段需要手動新增的 TXT 記錄，名稱類似 default._domainkey。把它複製過去貼上即可。

常見問題

• 記錄太長被截斷——DKIM 的公鑰很長，某些 DNS 管理介面會在貼上時自動截斷或加入換行。貼完務必回頭比對是否完整。
• 用多個平台寄信——每個服務會有自己的選擇器（selector），例如 default._domainkey、google._domainkey。這些不會互相衝突，可以同時存在，跟 SPF 只能有一筆的規則不同。

DMARC：告訴對方驗證失敗時怎麼辦

SPF 和 DKIM 只負責「檢查」，但沒有規定檢查不過該怎麼處理。DMARC 就是補上這一塊——它讓你宣告處置政策，並且能收到報告，知道有誰在冒用你的網域寄信。

怎麼設定

類型：TXT
名稱：_dmarc
內容：v=DMARC1; p=none; rua=mailto:postmaster@你的網域.com.tw

如果你的網域不是在主機商這裡註冊的，要到網域註冊商的管理後台修改。網域與主機在同一家的好處就在這裡——DNS 記錄的異動不用兩邊跑，出問題也只需要找一個窗口。

三個政策的差別：

• p=none——只監控、不做處置，但會寄報告給你。
• p=quarantine——驗證失敗的信丟進垃圾信匣。
• p=reject——驗證失敗的信直接拒收。

一定要從 p=none 開始。先觀察一到兩個月，從報告裡確認所有合法的寄信來源都通過驗證了，再逐步調整成 quarantine，最後才考慮 reject。

直接上 p=reject 的後果可能很嚴重：如果你的會計系統、電子報平台或某個舊系統的設定不完整，它們寄出的信會全部被退，而且你不會馬上發現。

一個容易忽略的細節：對齊

DMARC 不只看 SPF 或 DKIM 有沒有通過，還要求驗證通過的網域和信件上顯示的寄件人網域一致。

實務上常見的狀況是：你用某個電子報平台寄信，SPF 驗證通過了，但通過的是那個平台的網域，不是你的網域——這種情況 DMARC 仍然算失敗。解法是依照平台的說明完成自訂網域設定，讓 DKIM 用你自己的網域簽章。

怎麼驗證有沒有設對

設定完成後不要憑感覺，實際測一次：

方法一：寄信給檢測服務

mail-tester.com 這類服務會給你一個臨時信箱位址，你用公司信箱寄一封過去，網站會回報 SPF、DKIM、DMARC 的通過狀況，以及其他扣分項目。這是最直接的方式。

方法二：查詢 DNS 記錄

MXToolbox 這類工具可以直接查詢你的網域有哪些 SPF、DKIM、DMARC 記錄，也會提醒常見錯誤，例如上面提到的「兩筆 SPF」。

方法三：看 Gmail 的原始郵件

用公司信箱寄一封到自己的 Gmail，開啟後點右上角選單的「顯示原始郵件」。畫面上方會直接列出 SPF、DKIM、DMARC 三項的通過狀態。這個方法不需要任何工具，而且看到的就是 Gmail 實際的判定結果。

DNS 生效需要時間

剛改完設定不會立刻生效，通常要等幾十分鐘到數小時。如果測出來還是失敗，先確認是不是還在等待期，不要急著反覆修改——來回亂改反而會讓你搞不清楚哪個設定才是對的。

驗證都通過了還是進垃圾信匣？

驗證只是門檻，不是保證。其他常見原因：

• 寄件 IP 的信譽不佳。共用主機是多個網站共用同一個對外 IP，如果同一台機器上有人大量寄垃圾信，你會被連累。這是選擇主機商時值得考慮的一點——〈台灣虛擬主機怎麼選？新手最常犯的 6 個錯誤〉有相關的判斷標準。
• 信件內容觸發過濾規則。整封信只有一張圖片、標題全形驚嘆號、大量促銷字眼、夾帶可執行檔，都會被扣分。
• 網域太新。剛註冊的網域缺乏寄信歷史，初期比較容易被懷疑，需要一段時間累積信譽。
• 對方公司的內部規則。有些企業信箱有自己的白名單機制，這種只能請對方的 IT 加入白名單。

換主機時最容易漏掉的一環

搬家時信件出問題的比例遠高於網站本身，原因是順序錯了。

正確的做法是：先在新主機把所有信箱帳號建好、舊信件轉移完成，然後才切換 DNS。反過來的話，DNS 一切過去，信就開始送到新主機，但新主機上沒有對應的信箱——那些信會直接退回或消失。

另外，SPF 記錄裡的 include 值也要跟著換成新主機商的，DKIM 金鑰則要重新產生。這兩項忘記處理的話，搬完之後所有寄出的信都會驗證失敗——而且不會有任何錯誤通知，信照樣寄得出去，只是全部進了對方的垃圾信匣。

完整的搬家前檢查項目可以參考〈更換虛擬主機前必看的 7 個檢查清單〉。搬完之後除了信件，圖片、資料庫、SSL 與排名也都可能陸續出狀況，〈主機搬家後常見的 6 個問題〉有逐項的確認方式。

常見錯誤總整理

• 設了兩筆 SPF 記錄——只能有一筆，多筆等於驗證失敗。
• SPF 直接用 -all——漏掉某個寄信服務時會全部退信。
• DMARC 直接上 p=reject——沒有觀察期就強制執行，風險極高。
• DKIM 記錄貼上時被截斷——公鑰很長，要比對完整性。
• 改完設定立刻測試——DNS 還沒生效，測出來當然是失敗。
• 換主機沒更新 SPF 與 DKIM——搬完之後全部驗證失敗。
• 只設 SPF 就以為完成了——三項是互補的，缺一項效果差很多。

結語

郵件驗證的設定本身不難，難的是設錯了不會有明顯警告——信照樣寄得出去，只是對方收不到，而你完全不知情。等到客戶抱怨才發現，可能已經漏掉好幾張訂單了。

建議的執行順序是：先用 Gmail 測出目前的狀態 → 確認 SPF 只有一筆且內容正確 → 在 cPanel 啟用 DKIM → 設定 p=none 的 DMARC 觀察一個月 → 再逐步收緊政策。

這幾項牽涉到 DNS 記錄的修改，改錯會影響整個網域的收發信。如果你不確定自己在改什麼，或是測試後仍找不出問題，歡迎與我們聯絡——這類狀況我們處理過非常多次，通常看一眼記錄就能知道問題在哪。