MX 決定收信路徑，SPF、DKIM 與 DMARC 處理寄件驗證；網站維護者應分開檢查收信、寄信、轉寄與退信，避免把所有問題都歸咎於 DNS。
先拆成收信與寄信兩條路
MX 紀錄告訴外部郵件伺服器「這個網域的信要送到哪裡」，主要影響收信。網站表單或客服系統能否寄信，則還取決於實際寄件服務、SMTP 驗證、SPF、DKIM、DMARC、反向 DNS 與寄件信譽。MX 設好不代表寄信一定正常，沒有 MX 也不表示第三方寄件 API 必然不能寄。
排查時先記錄問題是所有寄件者都寄不進來、只有特定服務寄不進來，還是本站寄出的信被退回或進垃圾郵件。保留退信代碼與郵件標頭，答案通常就在傳遞鏈上。
MX 常見錯誤
- MX 指向不存在、拼錯或已停用的主機名稱。
- 把 MX 直接填成 IP；標準做法是指向可解析的主機名稱。
- 同時保留舊、新供應商 MX，造成郵件被分流到未同步的信箱。
- 優先序理解反了：數字越小通常越優先。
- MX 目標落在被代理的 CDN 記錄，或 A／AAAA 指向錯誤主機。
變更前先匯出現有 DNS，確認新服務商要求的全部記錄與 TTL。切換後從不同解析器查詢，並直接測試外部寄件到客服與技術支援信箱。
SPF 只描述哪些主機可以代寄
SPF 是 TXT 紀錄，列出哪些寄件來源可代表網域送信。每個網域應只有一筆有效 SPF；多筆 v=spf1 會造成永久錯誤。過多 include 可能超過 DNS 查詢限制，舊服務移除後也要清理授權。
~all 與 -all 不是越嚴越好；在寄件來源尚未盤點完成前直接改成硬拒絕，可能讓合法帳務、表單或客服信件失敗。先用實際標頭與服務清單確認所有來源，再逐步收斂。
DKIM 保護內容完整性與寄件網域
DKIM 由寄件服務使用私鑰簽章，收件端透過 DNS 中的公開金鑰驗證。維護者要確認 selector、網域與公鑰完全對應，避免複製時換行或截斷。更換供應商時保留舊 selector 到在途郵件完成驗證，再撤除舊金鑰。
金鑰應由寄件平台安全保存並定期輪替。若平台支援 2048 位元金鑰，優先採用；但也要確認 DNS 服務能正確保存較長的 TXT 值。
DMARC 決定驗證失敗後怎麼處理
DMARC 檢查可見的 From 網域是否與 SPF 或 DKIM 的驗證網域對齊，並提供 none、quarantine、reject 等政策。建議先以 p=none 收集彙總報告，找出合法寄件來源，再逐步提高政策與套用比例。
報告信箱會收到大量 XML，應使用專用地址或分析服務，不要把它與客服信箱混在一起。轉寄與郵件群組可能使 SPF 失敗，因此穩定 DKIM 對齊尤其重要。
部署與驗證清單
- 確認
service@kaelith.tw與support@kaelith.tw都已在郵件平台建立或正確轉寄。 - 查詢公開 MX、SPF、DKIM selector 與 DMARC，確認權威 DNS 回答一致。
- 從至少兩個外部郵件服務測試收信、回覆、附件與退信。
- 檢查原始標頭中的 SPF、DKIM、DMARC 結果與對齊網域。
- 變更後持續觀察 DMARC 報告、退信率與客服漏信。
若有高機密需求，可再評估 MTA-STS 與 TLS-RPT，但要先確保 MX 與憑證長期穩定，否則嚴格傳輸政策可能把設定錯誤變成收信中斷。