公司信箱寄給客戶卻進入垃圾郵件匣，常見原因不只「郵件內容有敏感字」。Email Authentication 應先核對 SPF、DKIM、DMARC 是否正確，並檢查寄信平台、寄件網域、退信紀錄與收件者互動。三項驗證能幫收件系統辨認來源，卻不能保證每封信都進主要收件匣。
為什麼公司信箱會被判定為垃圾郵件？
收件系統會綜合判斷寄件身分、網域與 IP 信譽、郵件內容及收件者反應。SPF、DKIM、DMARC 缺漏或不一致，是企業能先自行排查的一部分；寄送名單與內容品質也同樣重要。
先分清楚是哪一類郵件：員工手動寄出的商務郵件、網站聯絡表單通知、購物網站訂單信、電子報，可能由不同系統寄送。若網站表單用主機內建郵件函式、員工用 Google Workspace，電子報再用第三方平台，三種來源都需要被納入寄信盤點。只替員工信箱加 DNS 紀錄，無法自動替網站通知信完成驗證。
Google 的寄件者指南列出驗證、DNS、TLS、郵件格式與濫發率等要求。2026 年檢查時，應以最新官方要求和實際收件平台回應為準；「有設定 SPF」不等於信譽、內容、訂閱同意與取消訂閱機制都符合規範。企業網頁設計若包含表單與系統信，交付時應列明由哪個服務發信、誰負責後續維護。
SPF、DKIM、DMARC 各自驗證什麼？
SPF 核對寄信伺服器是否在網域授權清單；DKIM 以數位簽章協助驗證郵件未被任意竄改；DMARC 檢查可見寄件者網域與通過驗證的網域是否對齊，並宣告處理政策與回報方式。
SPF 寫在網域的 DNS TXT 紀錄，內容必須列入所有合法寄件服務。若漏了網站表單或自動化平台，該來源可能驗證失敗；若保留停用的服務，又會讓授權範圍難以控管。Google 的SPF 設定文件也提醒先盤點網頁伺服器、寄信服務與第三方供應商。不要把網路上的範例 SPF 直接貼入自己的網域，因為每家企業的寄件來源不同。
DKIM 私鑰由寄信服務持有，公鑰以 DNS 紀錄供收件端驗證。不同服務可能需要不同 selector；啟用後應寄測試信查看實際郵件標頭，而不是只看到 DNS 有紀錄就視為完成。DMARC 的對齊檢查更進一步：即使某第三方服務的 SPF 或 DKIM 顯示 pass，若對應網域與使用者看到的 From 網域不對齊，DMARC 仍可能失敗。
公司信箱的 SPF 紀錄應該怎麼檢查？
先列出所有合法寄件來源，再查看網域現有的 SPF TXT 紀錄是否完整、只有一套有效政策且沒有超出查詢限制。設定前要備份原紀錄，避免一次修改造成員工與網站信件同時受影響。
- 盤點員工信箱、網站表單、訂單通知、CRM、電子報和外部服務。
- 在 DNS 管理介面查看網域的 SPF TXT 紀錄，逐一比對寄件商提供的正式設定文件。
- 檢查是否有重複的 SPF 政策、停用服務殘留與過多 DNS 查詢。
- 在測試網域或可控時段調整，寄出測試信並檢查郵件原始標頭的 SPF 結果。
- 把新增寄件服務的 DNS 檢查納入網站維護流程。
SPF 驗證的是信封寄件者或 HELO 網域，不等於收件者畫面上看見的 From 網域。轉寄也可能改變 SPF 的驗證結果，因此不能只看單一 pass/fail 就推論所有收件者都會收到。Email Authentication 的檢查不應止於 DNS；若網站通知信被退回，應一起看 SMTP 服務、退信訊息和實際 From 設定。網站表單與系統信如何納入建站規劃？可從資訊架構與交付範圍先確認責任分工。
DKIM 與 DMARC 要怎麼設定與驗證？
先讓實際寄信服務產生並啟用 DKIM，再用測試信確認簽章與寄件網域。DMARC 宜先採觀察政策收集報表，辨認全部合法來源後再逐步提高處理強度。
DKIM 設定步驟依寄信供應商而不同：有些平台提供 TXT 公鑰，有些使用 CNAME 指向供應商管理的金鑰。複製紀錄時需確認 selector、主機名稱和完整值，避免 DNS 後台自動附加網域造成重複。寄出測試信後，於收件端查看 Authentication-Results，確認 dkim=pass，並核對 d= 的網域是否能與 From 網域對齊。
DMARC TXT 紀錄設在 _dmarc 子網域，最初可使用 p=none 觀察；先確認授權來源在報表中通過對齊，再評估 quarantine 或 reject。Google 的DMARC 分階段導入建議強調先配置 SPF、DKIM，再監看報表，避免過早拒收合法郵件。若公司有多個寄信平台，設定前要向各平台確認寄件網域與簽章支援，不應直接套用「最嚴格」的網路範本。
驗證都通過了，信件仍進垃圾郵件怎麼辦？
驗證通過只表示寄件身分具備可核對訊號；投遞位置還受 IP 與網域信譽、寄送方式、名單來源和收件者互動影響。先看退信原因與收件平台資料，不要反覆修改已正確的 DNS。
先用少量、經同意的真實測試對象，對不同收件平台寄出相同類型郵件，記錄時間、郵件標頭、退信碼與投遞位置。Email Authentication 通過後，再檢查寄件者地址是否穩定、郵件是否清楚標示品牌與聯絡方式、促銷信是否提供符合平台規則的退訂方式。若是網站表單通知，避免把訪客填入的信箱直接設定為 From；較合理的做法是由網站自己的已驗證地址寄出，訪客地址放在 Reply-To，並依表單外掛與寄信服務功能實作。
垃圾郵件判定也可能因大量無效地址、突然增加寄送量、釣魚外觀、遭入侵的帳號或主機而惡化。網站設計與 SEO 不會直接修好寄信信譽，但清楚的品牌資訊、表單驗證與可維護的通知流程能減少混亂。若想檢查表單被濫用的入口，聯絡表單防垃圾訊息該如何分層設定？可與寄信驗證一起檢查。
Email Authentication 的交付清單要寫哪些項目？
交付清單應能讓網站擁有者知道每個寄件服務、DNS 紀錄、測試結果與未來變更責任。只留下「已設定完成」四個字，無法在換主機或新增平台時有效排查。
| 檢查項目 | 應留下的資料 | 驗證方式 |
|---|---|---|
| 寄件來源 | 員工信箱、網站通知、訂單信、電子報等清單 | 逐一寄測試信 |
| SPF | 現有 DNS 政策與供應商來源 | 查 DNS 及郵件標頭 |
| DKIM | 每家服務的 selector 與金鑰管理者 | 檢查 dkim=pass 與網域 |
| DMARC | 政策、報表接收者與檢討日期 | 分析報表與對齊結果 |
| 投遞品質 | 退信、濫發率、收件者回饋 | 依收件平台工具持續追蹤 |
若合作對象在高雄、台中、台北遠端協作，DNS 權限與郵件平台管理帳號仍應由企業掌握。我們可協助釐清網站表單的寄信路徑，並把可交接的紀錄納入後續維護；不需要公開金鑰、密碼或 DMARC 報表中的個資。網站上線前要如何驗收表單與通知信？可參考本站的合作流程。網頁設計案例如何檢查實際交付範圍？則協助辨認展示內容與可驗收的設定項目。
常見問題
SPF、DKIM、DMARC 都通過，就能保證郵件不進垃圾匣嗎？
不能。三項驗證幫助確認寄件身分與網域對齊，投遞仍受網域信譽、內容、寄送方式、收件者互動及平台政策影響。
網站表單寄出的通知信，也要納入 SPF 嗎？
要先確認表單實際使用哪個寄信服務，再依供應商文件配置。若服務使用自己的退信網域，還要看 DKIM 與 DMARC 是否能對齊網站的 From 網域。
DMARC 可以一開始就設為 reject 嗎？
先盤點全部合法寄件來源並核對報表較安全。若仍有網站通知或第三方平台未對齊，直接拒收可能使正常商務郵件無法送達。
新增一個電子報平台後，要做哪些維護？
核對平台提供的 SPF、DKIM 與寄件網域指引，更新 DNS 與交付清單，寄測試信並查看原始標頭；同時確認訂閱同意與退訂流程符合平台要求。
