- 首頁
- 知識庫
- Sharing AI 架站平台教學
- 公司網域信箱怎麼設定？MX、SPF、DKIM、DMARC 與寄信不進垃圾信
Sharing AI 架站平台教學
公司網域信箱怎麼設定？MX、SPF、DKIM、DMARC 與寄信不進垃圾信
作者：JamXu更新日期：2026-10-11
公司網域信箱要能穩定收發，需要在網域的 DNS 設好四種記錄：MX 決定信寄到哪個信箱服務，SPF 列出可以代表你寄信的伺服器，DKIM 替每封信加上數位簽章，DMARC 則告訴收件端驗證失敗時該怎麼處理。四種記錄都設好並寄測試信確認通過，才能符合 Gmail 等信箱的寄件者規範，減少寄出的信被歸到垃圾信。
公司網域信箱是什麼？網站與信箱其實是兩套服務
公司網域信箱，指的是用自家網域當作信箱地址的後半段，例如 [email protected]，而不是 [email protected] 這類免費信箱。客戶看到網域信箱，會直接把它和公司官網連在一起；員工離職時，帳號也留在公司手上，不會跟著個人帳號一起消失。這是多數企業在架好網站之後，緊接著要處理的事。
很多人以為網站和信箱是同一件事，其實它們通常由兩個不同的服務提供：網站放在架站平台或主機上，信箱則放在 Google Workspace、Microsoft 365 或其他郵件服務。兩者唯一的交集，是同一個網域的 DNS 設定。DNS 就像總機，訪客要開網站時，它回答網站主機在哪裡；別人要寄信給你時，它回答郵件伺服器在哪裡。
| 用途 | 常用的記錄類型 | 設定值從哪裡來 | 改錯時的影響 |
|---|---|---|---|
| 網站（網域本身與 www） | A、CNAME | 架站平台或主機商的後台 | 網站打不開或出現憑證錯誤，信箱不受影響 |
| 收信 | MX | 信箱服務的管理後台 | 外部寄來的信被退回或寄到舊信箱 |
| 寄信驗證 | TXT（SPF、DMARC）、TXT 或 CNAME（DKIM） | 信箱服務與每一個代你寄信的系統 | 寄出的信容易進垃圾信，甚至被拒收 |
這篇以最常見的分工為例：網站使用 Sharing AI 架站平台，信箱使用 Google Workspace 或 Microsoft 365。網站端怎麼把網域指向平台、SSL 憑證怎麼生效，已經在自有網域綁定與 DNS 設定教學中完整說明，這裡專心處理信箱端的四種記錄。
先選信箱服務：三種常見來源與評估重點
設定 DNS 之前，要先決定信箱放在哪裡，因為每家服務要你填的值都不一樣。企業最常見的選擇有三種：國際雲端辦公套件、網域商或主機商附帶的郵件服務，以及在地的郵件代管業者。它們都能讓你用自己的網域收發信，差別在帳號管理、容量、行動裝置體驗與技術支援。
| 來源 | 常見情境 | 優點 | 要先確認的事 |
|---|---|---|---|
| 雲端辦公套件（Google Workspace、Microsoft 365） | 需要共用文件、行事曆與視訊會議的團隊 | 管理後台完整，官方文件清楚列出每一筆 DNS 記錄 | 依人數計費，離職帳號的資料保留與移轉方式 |
| 網域商或主機商附帶的信箱 | 人數少、只需要基本收發信 | 和網域在同一個地方管理，費用通常較低 | 容量上限、是否支援 DKIM、能否匯出舊信 |
| 在地郵件代管業者 | 需要中文客服、特殊歸檔或稽核需求 | 可依產業需求客製，溝通直接 | 服務等級、備份方式、是否提供 DMARC 報告協助 |
不論選哪一種，評估時都可以問同一組問題：能不能自己管理帳號與密碼重設？是否提供 SPF、DKIM 的設定值？行動裝置與 Outlook 等軟體怎麼連線？哪天想換服務時，舊信能不能完整匯出？不提供 DKIM 的信箱服務，往後很難符合各大信箱越來越嚴格的寄件規範，這一點在選擇時就要問清楚。
設定前的準備：盤點帳號、備份 DNS、決定切換時間
信箱設定最怕的是切換當下有人收不到信，客戶的詢價信、廠商的發票通知都可能在這段期間寄來。動手前先做好以下準備。
動手前的六項準備
- 列出所有信箱地址：個人信箱、共用信箱（如 service@、sales@）與群組或別名，確認新服務上都會建立。
- 先建好帳號再改 MX：Microsoft 365 的說明特別提醒，更新 MX 前要先替所有使用者建立信箱，郵件才能不中斷。
- 備份目前的 DNS 記錄：把網域商後台的記錄整頁截圖或匯出，萬一出錯可以對照還原。
- 找出所有會寄信的系統：電子報平台、網站表單、訂單或發票系統、客服工具，後面設定 SPF 與 DKIM 時都要列進去。
- 決定舊信怎麼處理：改 MX 之後，新信會寄到新服務，但舊信會留在原本的主機，除非另外搬移。
- 挑一個來信較少的時段：例如週末或下班後，並事先通知同事切換期間可能短暫收不到信。
四種記錄一次看懂：MX、SPF、DKIM、DMARC 各管什麼
這四種記錄常被放在一起講，但它們負責的方向不同。MX 處理「收信」，決定別人寄來的信送到哪裡；SPF、DKIM、DMARC 處理「寄信」，讓收件端判斷一封自稱來自你網域的信是不是真的。只設 MX，信箱可以正常收信，但寄出的信缺少身分證明，容易被當成可疑郵件。
| 記錄 | 回答的問題 | 記錄類型與名稱 | 沒設定會怎樣 |
|---|---|---|---|
| MX | 寄給這個網域的信要送到哪台郵件伺服器？ | MX，名稱為 @（網域本身） | 外部寄來的信無法送達 |
| SPF | 哪些伺服器可以用這個網域寄信？ | TXT，名稱為 @，內容以 v=spf1 開頭 | 收件端無法確認寄件伺服器是否合法 |
| DKIM | 這封信在途中有沒有被竄改、是不是由網域擁有者簽署？ | TXT 或 CNAME，名稱含 _domainkey | 信件沒有數位簽章，可信度較低 |
| DMARC | SPF 或 DKIM 沒通過時，收件端該怎麼處理？要把報告寄給誰？ | TXT，名稱為 _dmarc | 別人冒用你的網域寄信時，收件端沒有處理依據 |
設定的順序建議是：先 MX，確認收信正常；再設 SPF 與 DKIM，等它們生效；最後才加上 DMARC。Google 的 DMARC 說明也要求先啟用 SPF 或 DKIM，並在設定後等待 48 小時，再開始設定 DMARC。
MX 記錄：決定別人寄來的信送到哪裡
MX 記錄有兩個關鍵欄位：目標（郵件伺服器的主機名稱）與優先順序。優先順序的數字越小，優先權越高；有多筆 MX 時，寄件端會先嘗試數字最小的那一台。以下整理兩大雲端信箱服務的官方設定方式。
Google Workspace 的 MX 設定值
依 Google Workspace 管理員說明，現在的設定只需要一筆 MX：名稱留白或填 @，優先順序填 1，值填 smtp.google.com，存留時間可沿用網域商的預設值。2023 年以前開通的帳戶可能使用以 ASPMX.L.GOOGLE.COM 開頭的五筆舊值，官方表示舊值仍然支援，信箱正常運作時不需要更改。
同一份說明也提醒，要移除其他舊的 MX 記錄，留著舊的或錯誤的 MX，郵件可能無法正常運作。部分網域商要求在值的最後加上一個英文句點，寫成 smtp.google.com.，填寫前先看清楚網域商的格式說明。新的 MX 最多可能需要 72 小時才會被各地的 DNS 伺服器認得。
Microsoft 365 的 MX 設定值
Microsoft 365 的 MX 值不是固定字串，而是依你的網域產生，要從 Microsoft 365 系統管理中心的「設定 → 網域 → DNS 記錄」複製。依Microsoft 365 新增 DNS 記錄的官方說明，MX 的名稱填 @，優先順序設為可用的最高優先權（通常是 0），存留時間 3600 秒；Exchange Online 只支援低於 6 小時的存留時間。
如果網域先前已經有其他信箱服務的 MX，Microsoft 提供兩種做法：刪除指向舊服務的 MX，或把舊 MX 的優先權設得比 Microsoft 365 低。Microsoft 也另外建議新增一筆名稱為 autodiscover 的 CNAME，讓 Outlook 等軟體能自動完成信箱設定。
| 欄位 | Google Workspace | Microsoft 365 |
|---|---|---|
| 名稱／主機 | 留白或 @ | @ |
| 值／目標 | smtp.google.com | 從系統管理中心複製（依網域產生） |
| 優先順序 | 1 | 可用的最高優先權，通常為 0 |
| 存留時間（TTL） | 沿用預設值 | 3600 秒，須低於 6 小時 |
| 舊 MX 的處理 | 移除其他 MX | 刪除，或把優先權設得比新 MX 低 |
| 額外建議記錄 | — | autodiscover 的 CNAME |
MX 改好之後，先從外部的免費信箱寄一封信到公司信箱，確認新服務收得到。切換初期部分信件可能還會送到舊信箱，這是 DNS 快取尚未全部更新的正常現象，所以舊信箱不要在改 MX 當天就停用，至少保留到確認不再有新信進來為止。
SPF 記錄：列出可以代表你寄信的伺服器
SPF 是一筆 TXT 記錄，內容是一份「寄件伺服器名單」。收件端收到一封寄件網域是你的信時，會查這份名單，看寄出這封信的伺服器有沒有被授權。名單之外的伺服器寄來的信，就會被視為可疑。
SPF 的基本寫法
一筆 SPF 記錄由三個部分組成：開頭固定是 v=spf1；中間用 include: 加入每一個授權的寄件服務；結尾用 ~all 或 -all 表示「名單以外的伺服器怎麼處理」。Google Workspace 的標準值是 v=spf1 include:_spf.google.com ~all；Microsoft 365 說明中的值則是 v=spf1 include:spf.protection.outlook.com -all。
| 寫法 | 意思 | 使用時機 |
|---|---|---|
| v=spf1 | 宣告這是一筆 SPF 記錄 | 每一筆 SPF 都必須以它開頭 |
| include:_spf.google.com | 授權 Google Workspace 的寄件伺服器 | 信箱使用 Google Workspace |
| include:spf.protection.outlook.com | 授權 Microsoft 365 的寄件伺服器 | 信箱使用 Microsoft 365 |
| include:（電子報或系統提供的值） | 授權第三方寄件服務 | 用電子報平台、訂單或客服系統以公司網域寄信 |
| ~all | 名單以外的伺服器：軟性失敗，收件端視為可疑 | Google 建議的寫法，適合還在盤點寄件來源的階段 |
| -all | 名單以外的伺服器：明確失敗 | 確認所有寄件來源都已列入後使用 |
最常見的錯誤：一個網域設了兩筆 SPF
一個網域只能有一筆 SPF 記錄。很常見的情況是：信箱服務請你加一筆 SPF，電子報平台又請你加一筆，結果網域上出現兩筆以 v=spf1 開頭的 TXT，兩筆反而都可能失效。正確的做法是把所有服務合併成一筆，例如同時使用 Google Workspace 與 Microsoft 365 時，寫成 v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all。Microsoft 的說明也明確表示，已經有 SPF 時不要另建新的，而是把新的值加進現有記錄。
合併時要注意 SPF 的查詢次數上限。SPF 規格限制一次驗證最多只能觸發 10 次 DNS 查詢，每個 include 都會消耗至少一次，有些服務的 include 內又包含其他 include。寄件服務一多就可能超過上限，導致驗證失敗。所以只把真的會用公司網域寄信的服務列進去，停用的服務也要記得從名單移除。
子網域要另外設定
SPF 不會自動套用到子網域。如果你用 news.yourbrand.com.tw 這類子網域寄送電子報，Google 的說明指出每個子網域都要有自己的 SPF 記錄。SPF 新增或修改後，最多可能需要 48 小時才會開始生效。
DKIM 記錄：替每一封信加上數位簽章
DKIM 的原理是一組金鑰：信箱服務用私密金鑰替每封寄出的信簽章，再把對應的公開金鑰放在你網域的 DNS。收件端收到信時，用 DNS 上的公開金鑰檢查簽章，就能確認這封信確實由網域擁有者授權寄出，而且內容在途中沒有被修改。和 SPF 不同的是，DKIM 的簽章跟著信件本身走，信件被轉寄時通常還能保留。
在 Google Workspace 設定 DKIM
- 確認 Gmail 已經啟用。依 Google 的說明，啟用 Gmail 後要等 24 到 72 小時，才能產生 DKIM 金鑰。
- 在 Google 管理控制台進入「應用程式 → Google Workspace → Gmail → 驗證電子郵件」，選擇要設定的網域，產生新記錄。
- 金鑰長度選 2048 位元；只有網域商不支援 2048 位元時才選 1024 位元。前置字元選擇器維持預設的 google。
- 複製畫面上的 TXT 記錄名稱（google._domainkey）與以 v=DKIM1 開頭的金鑰值，到網域商的 DNS 新增一筆 TXT 記錄。
- 回到管理控制台按「開始驗證」。新增金鑰後，最多可能需要 48 小時，DKIM 驗證才會開始運作。
在 Microsoft 365 設定 DKIM
Microsoft 365 的 DKIM 使用兩筆 CNAME 記錄，名稱分別是 selector1._domainkey 與 selector2._domainkey，指向的值都要從系統管理中心新增 DNS 記錄的畫面複製。在網域設定精靈中，DKIM 被放在「進階選項」，屬於選用項目，但若要符合後面提到的大量寄件規範，就應該一起設定。
每個代你寄信的服務都要各自設定
信箱服務的 DKIM 只會簽署從信箱寄出的信。電子報平台、電商訂單通知、客服系統如果以公司網域寄信，每一個服務都要依它的說明另外新增 DKIM 記錄。它們通常使用不同的選擇器名稱，所以可以和信箱的 DKIM 同時存在，不會互相衝突。
DMARC 記錄：告訴收件端驗證失敗時怎麼處理
SPF 和 DKIM 負責檢查，DMARC 負責「下決定」。它是一筆名稱為 _dmarc 的 TXT 記錄，告訴收件端：寄件網域是我的信，如果 SPF 與 DKIM 都沒有通過，請照我的政策處理，並把統計報告寄到指定的信箱。沒有 DMARC，別人冒用你的網域寄送詐騙信時，收件端只能各自判斷。
DMARC 的基本寫法
一筆最基本的 DMARC 記錄長這樣：v=DMARC1; p=none; rua=mailto:[email protected]。v=DMARC1 是固定開頭；p 是政策；rua 是接收彙整報告的信箱。依 Google 的 DMARC 說明，報告數量可能很多，建議用專用的信箱或群組接收，不要填個人主要信箱。
| 標記 | 可填的值 | 作用 |
|---|---|---|
| p | none、quarantine、reject | 驗證失敗時的處理方式：不處理只記錄、歸到垃圾信、拒收 |
| rua | mailto: 加上信箱地址 | 接收每日彙整報告的信箱 |
| pct | 1 到 100 | 政策套用在多少比例的驗證失敗信件上，用於逐步收緊 |
| adkim、aspf | r（寬鬆）或 s（嚴格） | DKIM、SPF 的網域對齊模式；寬鬆模式允許子網域相符 |
| sp | none、quarantine、reject | 子網域另外適用的政策；不設定時沿用主網域的政策 |
對齊：DMARC 真正檢查的是什麼
DMARC 不只看 SPF 或 DKIM 有沒有通過，還會檢查「對齊」：收件人在信箱看到的寄件者網域，必須和 SPF 驗證的網域，或 DKIM 簽章的網域一致。舉例來說，電子報平台用它自己的網域通過了 SPF，但信件顯示的寄件者是你的網域，兩者沒有對齊，這時就要靠你替該平台設定的 DKIM 來通過 DMARC。這也是為什麼前一節要替每個寄件服務各自設定 DKIM。
從 none 開始，逐步收緊
一開始就把政策設成 reject，很可能把自己公司的正常信件擋掉，例如漏列在 SPF 裡的發票系統。Google 建議先用 p=none 觀察報告，確認所有合法寄件來源都已通過驗證，再用 pct 從小比例開始，逐步提高到 100%。下表是一個參考的進度安排。
| 階段 | 政策設定 | 這段期間要做的事 | 進入下一階段的條件 |
|---|---|---|---|
| 觀察期 | p=none | 每週看報告，找出所有用公司網域寄信的來源 | 報告中的合法來源都已通過 SPF 或 DKIM 並對齊 |
| 小比例隔離 | p=quarantine; pct=10 起 | 觀察是否有正常信件被歸到垃圾信 | 連續數週沒有合法信件受影響 |
| 全面隔離 | p=quarantine; pct=100 | 持續檢查報告，新增寄件服務前先設好驗證 | 確認不再出現合法來源驗證失敗 |
| 拒收 | p=reject | 定期看報告，處理冒用網域的來源 | 長期維持，每次新增系統都先驗證 |
關鍵是每次收緊之前，報告裡的合法來源都已經全部通過。報告是 XML 格式，可以用報告分析工具整理成表格再閱讀。
Gmail 與 Outlook 的寄件者規範：一般公司要做到哪裡
2024 年起，Gmail 對寄信到個人 Gmail 帳戶的寄件者訂下明確規範，之後 Microsoft 也對 Outlook.com 等個人信箱提出類似要求。很多公司寄出的報價單、通知信突然開始進垃圾信，原因往往就在這裡。規範分成「所有寄件者」與「大量寄件者」兩個層級。
所有寄件者都要做到的事
依Google 的電子郵件寄件者規範，所有寄信到個人 Gmail 帳戶的寄件者，都必須為寄件網域設定 SPF 或 DKIM、寄件網域或 IP 具備有效的正向與反向 DNS 記錄、使用 TLS 連線傳送、信件格式符合 RFC 5322，而且不能在寄件者欄位假冒 Gmail。垃圾郵件比率要維持在 0.3% 以下。使用 Google Workspace 或 Microsoft 365 寄信時，反向 DNS 與 TLS 由服務商處理，公司要負責的是網域上的 SPF 與 DKIM。
大量寄件者的額外要求
Gmail 的大量寄件者，指的是 24 小時內寄給個人 Gmail 帳戶接近 5,000 封以上信件的寄件者。依 Google 的寄件者規範常見問題，同一個主網域底下所有子網域寄出的信都會合併計算，只要達到一次門檻，就會永久被視為大量寄件者。大量寄件者除了上述要求，還必須：
- 同時設定 SPF 與 DKIM，並為寄件網域設定 DMARC，政策可以是 p=none。
- 寄件者欄位的網域，要和 SPF 或 DKIM 的網域對齊。
- 行銷與訂閱郵件要支援一鍵取消訂閱，並在信件內文提供明顯的取消訂閱連結；官方建議在 48 小時內處理取消要求。
- 垃圾郵件比率最好維持在 0.1% 以下，並避免達到 0.3%。
Google 的常見問題列出執行時程：規範自 2024 年 2 月開始實施，2024 年 6 月起加強處理垃圾郵件比率過高的寄件者，2025 年 11 月起對不符規範的寄件者採取更嚴格的處置，不符規範的信件可能被限制傳送速度、歸到垃圾信或遭拒收。
Outlook.com 也有類似要求
Microsoft 在 2025 年宣布，每天寄送超過 5,000 封信到 Outlook.com、Hotmail.com、Live.com 等個人信箱的寄件網域，自 2025 年 5 月 5 日起必須通過 SPF 與 DKIM，並發布至少 p=none 的 DMARC 且與 SPF 或 DKIM 對齊；不符規範的信件會先被送到垃圾郵件匣。
只用信箱和客戶往來的公司，寄信量通常不會接近 5,000 封，但寄電子報或會員通知時就可能跨過門檻。最穩當的做法是一開始就把 SPF、DKIM、DMARC 三項都設好，不必等到被歸類為大量寄件者才補設定。
設定完怎麼驗證：寄一封測試信看三個 PASS
記錄生效之後，最直接的驗證方式是寄一封信到個人 Gmail 帳戶，看收件端的判斷結果；這比只查 DNS 更可靠，因為它檢查的是整個寄送路徑。
- 從公司信箱寄一封內容正常的信到自己的個人 Gmail 帳戶，不要只寫「測試」兩個字。
- 在電腦版 Gmail 開啟這封信，按回覆按鈕旁的「更多」，選擇「顯示原始郵件」。
- 在新開啟的頁面上方，查看 SPF、DKIM、DMARC 三列的結果，理想狀態是三項都顯示 PASS。
- 若有任何一項顯示 FAIL 或沒有出現，記下結果，對照下一節的排查表找原因。
- 電子報平台、表單通知、訂單系統等其他寄件來源，也各寄一封測試信，用同樣方法檢查。
DMARC 顯示 PASS 的條件，是 SPF 或 DKIM 至少一項通過並且和寄件者網域對齊，所以有時會看到 SPF 通過但 DMARC 失敗的情況，原因通常就是對齊問題。除了 Gmail 的原始郵件，也可以用 Google 提供的 Admin Toolbox 中的工具檢查 MX 設定，或貼上完整信件標頭分析寄送路徑。
寄信量較大的公司，可以再申請 Gmail 的郵件管理員工具（Postmaster Tools），持續觀察寄給 Gmail 使用者的垃圾郵件比率與驗證狀態，它也提供寄件者規範的法規遵循狀態資訊。
寄出的信進垃圾信？常見原因排查表
信件被歸到垃圾信，原因可能在技術設定，也可能在名單與內容。建議先排除技術問題，再檢查主旨是否誇大、名單是否經過收件人同意。下表依症狀整理常見原因與處理方式。
| 症狀 | 可能原因 | 處理方式 |
|---|---|---|
| 外部寄來的信被退回 | MX 填錯、刪錯，或還在等待生效 | 對照信箱服務提供的值檢查 MX，必要時依備份還原 |
| 部分信件還寄到舊信箱 | DNS 快取尚未更新，或舊 MX 沒有刪除 | 確認舊 MX 已刪除或優先權較低，等待生效期間保留舊信箱 |
| SPF 顯示 FAIL 或 PermError | 網域上有兩筆 SPF，或查詢次數超過上限 | 合併成一筆，移除已停用的服務 |
| SPF 通過但 DMARC 失敗 | 寄件服務用自己的網域通過 SPF，沒有和你的網域對齊 | 替該服務設定你網域的 DKIM |
| DKIM 顯示 FAIL | 金鑰複製不完整、被網域商截斷，或還沒按「開始驗證」 | 重新複製完整金鑰，確認網域商支援長字串 |
| 只有寄到 Gmail 的信進垃圾信 | 缺少 SPF 或 DKIM，或垃圾郵件比率偏高 | 補齊驗證，檢查寄送名單與取消訂閱機制 |
| 電子報退信率高 | 名單過舊、含無效地址或未經同意的收件人 | 清理名單，只寄給同意收信的對象 |
| 設定 DMARC 後正常信件被擋 | 政策太快收緊，漏列寄件來源 | 暫時調回 p=none，從報告找出來源並補上驗證 |
網站表單、電子報與系統通知：別漏了「代你寄信」的服務
公司網域上的寄件來源，往往不只有員工的信箱。網站表單的通知信、電子報、電商訂單確認信、預約提醒、發票通知，都可能用公司網域或寄到公司信箱。這些來源最容易在設定 SPF 與 DMARC 時被遺漏，結果造成「客戶說沒收到確認信」。
網站表單的通知信寄到公司信箱
在 Sharing AI 架站平台，網站表單收到的留言可以在後台的留言管理中查看，並在「收件信箱」新增要接收通知的信箱地址，也能指定每個信箱接收哪些表單的留言。建議填入公司網域的共用信箱，例如 service@，而不是某位同事的個人信箱，人員異動時才不會漏接詢問。表單欄位、感謝頁與通知的完整設定，在網站表單怎麼設計一文有逐步說明。
電子報與系統通知用子網域分開寄送
如果公司會定期寄電子報或大量通知信，可以考慮用子網域寄送，例如 news.yourbrand.com.tw，讓行銷信的寄件評價和員工日常往來的信件分開。要注意兩件事：子網域需要自己的 SPF 與 DKIM 設定；而在 Gmail 的大量寄件者計算中，同一個主網域底下的子網域寄信量會合併計算，用子網域並不能避開大量寄件規範。
- 電子報平台：依平台說明新增 SPF 的 include 與 DKIM 記錄，並開啟一鍵取消訂閱。
- 電商與訂單系統：確認訂單、出貨通知以哪個寄件地址寄出，是否需要在你的網域設定驗證。
- 客服與預約工具：以公司網域寄出的回覆與提醒，同樣要列入 SPF 並設定 DKIM。
換網站、換信箱或換網域時：不中斷的切換順序
信箱最常出問題的時間點，不是第一次設定，而是之後的各種變動：網站搬到新平台、信箱換服務商、公司換網域。每一種變動要動的記錄不同，先弄清楚自己在換什麼，就知道哪些記錄要保持不動。
| 變動 | 要調整的記錄 | 不能動的記錄 | 最容易出錯的地方 |
|---|---|---|---|
| 只換網站平台 | @ 與 www 的 A 或 CNAME | MX、SPF、DKIM、DMARC 與各種驗證用 TXT | 清理舊記錄時把 MX 或 SPF 一起刪掉 |
| 只換信箱服務 | MX、SPF 中的 include、DKIM，必要時更新 DMARC 報告信箱 | 網站的 A 或 CNAME | 舊信沒有搬移、舊信箱太早停用 |
| 換網域 | 新網域的網站與信箱記錄全部重新設定 | 舊網域的 MX 與轉寄設定，保留一段時間 | 舊網域到期失效，客戶寄到舊地址的信全部退回 |
網站搬到 Sharing AI 時
把網站搬到 Sharing AI 架站平台時，只需要調整網域本身與 www 指向網站的記錄。清理舊記錄時，MX 與寄信驗證用的 TXT 一律保持不動，它們和網站主機無關。綁定網域的四個階段與清理原則，請照自有網域怎麼綁定網站的步驟操作。
換信箱服務商時
- 在新服務建立所有帳號、共用信箱與群組，先用服務商提供的預設網址測試收發。
- 提前把要修改的 MX 記錄存留時間調短，讓切換時各地快取能較快更新。
- 修改 MX，並把 SPF 裡的舊服務 include 換成新服務的值，維持只有一筆 SPF。
- 在新服務產生 DKIM 並新增記錄，等待生效後開始驗證；舊服務的 DKIM 記錄可在確認不再使用後移除。
- 用前面的驗證清單逐項測試，並依服務商提供的工具搬移舊信、聯絡人與行事曆。
- 確認不再有新信寄到舊服務後，才停用舊服務的帳號。
公司換網域時
換網域時，新網域要從頭設定網站與信箱的所有記錄，舊網域則不能馬上放掉。客戶、廠商的通訊錄裡存的是舊地址，至少要讓舊網域的信箱繼續收信，或設定轉寄到新地址，並在信件簽名檔提醒對方更新。網站端的網址轉換與保留期限，在網站搬家怎麼做中有完整的步驟與時間表。
長期維護：續約、帳號安全與一張記錄表
信箱設定好之後平常很少再碰，出問題時常常沒人記得當初怎麼設定。以下四件事建議列入例行檢查。
- 網域續約：網域一旦過期，網站與信箱會同時停擺，所有寄到公司的信都會退回。開啟自動續約，並確認付款方式有效。
- 管理帳號安全：網域商、DNS 代管與信箱管理後台的帳號都要開啟雙重驗證，並由公司內部至少兩人知道如何登入。
- 人員異動：員工離職時，依信箱服務的流程停用帳號、移轉信件，必要時把信箱轉為共用信箱或設定轉寄，避免客戶來信石沉大海。
- 新增寄件服務前先設定驗證：導入新的電子報、訂單或客服系統時，先把 SPF 與 DKIM 設好、寄測試信確認，再正式啟用。
最後，把所有郵件相關的 DNS 記錄整理成一張表，存在公司共用的文件裡。下次換廠商、加開服務或遇到寄信問題，這張表就是第一個要打開的文件。
| 記錄 | 名稱 | 值（摘要） | 用途與備註 |
|---|---|---|---|
| MX | @ | smtp.google.com，優先順序 1 | Google Workspace 收信，勿刪 |
| TXT（SPF） | @ | v=spf1 include:_spf.google.com include:（電子報平台）~all | 唯一一筆 SPF，新增寄件服務時合併 |
| TXT（DKIM） | google._domainkey | v=DKIM1; k=rsa; p=… | Google Workspace 簽章，2048 位元 |
| CNAME 或 TXT（DKIM） | （電子報平台提供） | （電子報平台提供） | 電子報簽章，停用平台時一併移除 |
| TXT（DMARC） | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@… | 觀察期，預計檢視報告後收緊 |
表中也記下每筆記錄的設定日期與負責人。頁尾聯絡資訊是否已改成公司網域信箱等其他項目，可以搭配架站上線前的檢查清單一起確認。
下一步：先查一下網域上現在有哪些郵件記錄
整理成一句話：MX 管收信，SPF 列出誰能寄，DKIM 替信件簽章，DMARC 決定驗證失敗時怎麼處理；四項依序設定、寄測試信看三個 PASS，再依報告逐步收緊 DMARC，公司寄出的信就能穩定地被收件端信任。
建議你今天就登入網域商後台，看看網域上現在有幾筆 MX、幾筆以 v=spf1 開頭的 TXT，以及有沒有 _dmarc 記錄，再寄一封信到自己的 Gmail 看原始郵件的結果。網站的網域綁定、頁面規劃與上線檢查，可以回到 Sharing AI 架站平台教學主題頁依學習路線進行；想了解平台功能與方案，可以看 Sharing AI 架站平台介紹。如果希望由團隊協助檢查網站與網域設定，也歡迎直接與我們聯絡。