GCP國際帳號開通 GCP 域名郵局 MX 記錄與 SPF 設定教學

第一章：你在設定的其實是「郵件通行證」

很多人第一次設定 GCP 域名郵局，會把它想成「在 DNS 加幾條記錄就好」。但如果只把步驟當作操作清單，遇到錯誤時就很難判斷問題點。真正需要理解的是：郵件如何從寄件端被路由到你的收件端，DNS 又如何扮演「身份驗證與投遞指示」的角色。

在郵件世界裡，兩個概念特別關鍵：MX 記錄、SPF 記錄。

• MX（Mail Exchanger）：告訴外部郵件伺服器「你的郵件要投到哪裡」。它決定了收件路由。
• GCP國際帳號開通 SPF（Sender Policy Framework）：告訴外部郵件伺服器「哪些伺服器被允許代表你的網域寄信」。它決定了寄件身分是否可信。

你把 MX 設成對的目標、把 SPF 設成正確的授權，才能讓郵件既能到你這邊，也不容易被判定為偽冒。

第二章：先理解郵件流向，設定才不會盲做

假設你要寄信給 [email protected]。外部郵件伺服器在送信前，通常會做幾件事：

1. 查詢你的網域 MX 記錄，找到投遞目標與優先序。
2. 把信件投遞到 MX 指到的伺服器（可能是 GCP/你使用的郵件服務）。
3. 在送達或接收時，會檢查 SPF（以及其他驗證如 DKIM/DMARC，本文先聚焦 MX 與 SPF）。

如果 MX 沒設對：外部伺服器可能根本找不到投遞點，或投到錯誤的地方。結果常見是投遞延遲、退信、或進入黑洞。

如果 SPF 沒設對：即使郵件投遞到了正確的伺服器，仍可能因為「寄件身分不被授權」而被降權、標記垃圾，甚至被直接拒絕。

第三章：在 GCP 使用域名郵局前，先做三個核對

開始動手前，我建議你先把以下資訊整理好，因為它們會直接影響你 DNS 記錄怎麼填：

1. 你使用的是哪種郵件服務

GCP國際帳號開通 「GCP 域名郵局」通常意味著你把網域的郵件交給 Google Cloud 相關服務或搭配 Google Workspace/自建郵件流程。實務上不同產品會對 MX 目標與 SPF 字串有差異。

你需要的是：官方提供的 MX 主機名稱與 SPF 授權字串（或至少是允許的來源 IP/機制）。不要只憑經驗猜。

2. 你要設定的網域是根網域還是子網域

例如：

• GCP國際帳號開通 設定 yourdomain.com：通常用在主要寄件與收件。
• 設定 mail.yourdomain.com：也可以，但你需要知道郵件服務對應的是哪個網域層級。

大多數郵件服務會要求在根網域（yourdomain.com）做 MX 與 SPF。若你設定到子網域，外部可能不會用你那套規則。

GCP國際帳號開通 3. 你的 DNS 服務商是哪裡

教學的精神是「你要在 DNS 端加記錄」，GCP 只是使用端或管理端。DNS 可能在 Cloud DNS、也可能在你原本的網域商。只要你能新增 TXT 與 MX 記錄，就可以照做。

第四章：MX 記錄設定教學（逐步可操作）

MX 記錄的核心欄位一般是三個：主機名稱/Host、優先序/Priority、目標/Target。在不同 DNS 控制台，欄位命名可能不一樣，但意義一致。

步驟 1：確定 MX 記錄要放在「哪個 Host」

若你要處理整個網域的收件，通常使用：

• Host：@（代表根網域），或留空/填 yourdomain.com（依控制台習慣）。

若你設定在錯的主機上（例如只放在 mail 子網域），外部查詢不到你的根網域 MX，就會失敗。

步驟 2：建立第一條 MX 記錄

假設官方建議你使用某些目標主機（舉例概念如下，實際請使用你服務提供的值）：

• Priority：10
• Target：mx1.your-mail-service.example.com

你會建立一筆 MX：Host=@、Priority=10、Target=mx1....

注意兩個常見細節：

• Target 要不要加尾端點「.」：有些控制台接受或自動處理；有些要求你確實包含末尾「.」。若你不確定，建議以控制台的輸入提示為準，或先用官方提供的格式。
• 不要自行修改目標格式：MX Target 通常是標準主機名，而非 IP。

步驟 3：建立第二條（與優先序）

郵件服務常會提供多組 MX 記錄，讓你在某個節點異常時仍能投遞。例如：

• Priority：20，Target：mx2.your-mail-service.example.com
• Priority：30，Target：mx3.your-mail-service.example.com

優先序越小代表越優先，但它不代表「只用第一條」。外部伺服器可能會在嘗試失敗後改用下一條。

步驟 4：TTL 與生效時間的現實

DNS TTL 是「快取多久」的規則。你改完 MX 記錄後，不一定立刻生效，因為外部伺服器與本地解析可能持有快取。

• 如果你在正式上線前改過：通常不用擔心，但要給一段時間（常見幾十分鐘到數小時，視快取而定）。
• 若你在剛改完就測試：可能看起來像「失敗」，其實是等待快取更新。

步驟 5：檢查是否存在舊的 MX 記錄

這是最常見的坑之一。你如果曾經設定過其他郵件服務（例如舊的站內郵件、或之前用過的第三方），可能還留著舊 MX。

外部查詢可能會同時看到多組 MX。這會導致：

• 信件被送到舊服務，變成「你以為寄到新服務，實際卻到了別處」。
• 或造成投遞延遲，因為外部需要多次嘗試。

建議你先確認目前 MX 列表，確保只保留你需要的目標。

第五章：SPF 設定教學（不要把 SPF 當作裝飾）

SPF 是 TXT 記錄，內容是一段字串，描述「哪些來源可以代表你寄信」。外部伺服器在檢查 SPF 時，會將寄件伺服器 IP、以及信件中的 envelope-from/HELO 對應的網域，去匹配 SPF 規則。

你要做的是在正確的 Host 上建立 TXT 記錄，並確保字串格式符合 SPF 規範。

步驟 1：選擇 SPF 放在哪裡

一般來說，SPF 會放在根網域：

• Host：@
• Record Type：TXT

若你填在錯的子網域，外部可能不會引用你那條 SPF。

步驟 2：使用「官方提供的 SPF 字串」

對 GCP/Google 相關郵件服務，SPF 通常包含一些機制（例如指向特定服務、或允許特定來源）。不要自行腦補 IP 或機制。

你要做的是：把控制台提供的 SPF 內容完整貼上，並確認沒有被截斷。

典型 SPF 會長得像：

• v=spf1 include:_spf.example.com ~all

這只是格式示意，實際要用你服務的內容。

步驟 3：避免「同一網域多條 SPF TXT」

很多人會不小心新增第二條 SPF TXT，或歷史上保留了舊 SPF。結果就是同一個 Host 出現兩條或多條 SPF。

這通常會造成 SPF 檢查行為不符合你預期，輕則標記錯誤，重則直接判定結果不可靠。

實務建議：

• 查詢目前 @ 的 TXT 記錄中是否已存在任何 v=spf1 開頭的項目。
• 若已存在，先決定要更新哪一條，而不是新增另一條。

步驟 4：理解最後的 ~all 或 -all

SPF 規則最後常見兩種尾端：

• ~all：softfail，表示未授權來源「應該」失敗，但多數情況仍可能送達，只是信譽風險變高。
• -all：hardfail，表示未授權來源「直接失敗」。

剛開始上線或你不確定所有寄件來源時，使用 ~all 通常比較保守；若你已完全掌握寄件來源且希望更嚴格，才考慮 -all。這一點要配合你實際寄件流程。

第六章：把 MX 與 SPF 配到一起，你需要一套驗證節奏

設定 DNS 並不等於立刻正確。你應該用「節奏」驗證，而不是改完就焦慮。

GCP國際帳號開通 1. 先驗證 MX

做法很簡單：查詢你的網域 MX 列表，看是否符合你新增的條目與優先序。

• MX 是否正確指向服務提供的目標。
• 是否還存在舊 MX。
• 優先序是否符合預期。

2. 再驗證 SPF TXT 是否存在且格式正確

GCP國際帳號開通 確認：TXT 記錄的 Host 是正確的，且內容包含 v=spf1，並且沒有被多條 SPF 覆蓋或截斷。

另外注意字串是否含有多餘空白或錯誤字元。不同控制台在顯示時可能會自動加引號，但實際值要仍保持 SPF 字串完整。

3. 最後再做實際寄件測試

你可以：

• 用外部信箱（例如常見商用或公共服務）測試寄信給自己。
• 在寄件端觀察回執或錯誤訊息（例如 SPF fail、DNS lookups failed、或投遞失敗）。

重點是：實際測試最能反映「整體設定是否真能被外部解析」而不是僅停留在你本地看到的結果。

第七章：常見錯誤與修正方向（把坑填平）

下面這些狀況，通常佔了多數失敗案例。你可以對照檢查自己的設定。

錯誤 1：MX Target 填成 IP 或錯誤格式

MX 記錄只能填主機名（通常是 FQDN），不能用 IP。若你把目標填錯格式，解析器可能拒絕或導致投遞異常。

修正：改回官方給的 MX 目標主機名。

錯誤 2：優先序設得亂七八糟

優先序通常不是隨便的。雖然郵件服務可能仍能工作，但你可能失去備援或造成多餘嘗試。

修正：按照官方建議的優先序建立多條 MX。

錯誤 3：忘了刪掉舊 MX

你以為只新增了新 MX，但舊的還在，導致信件混投或延遲。

修正：先列出目前 MX，確認要刪除不再使用的條目。

錯誤 4：同一網域存在多條 SPF（多個 v=spf1）

這是最常見的 SPF 問題。你以為「多幾條也沒差」，但 SPF 檢查是針對解析規則執行的，錯誤的條目會讓結果不可預期。

修正：保留一條最終 SPF，將必要機制合併後集中在一條 TXT 中。

錯誤 5：把 SPF 放在錯的 Host

GCP國際帳號開通 例如你把 SPF 放在 mail 子網域，但寄件主體用的是 root 網域；外部解析時就可能找不到你設定的那條 SPF。

修正：確認寄件使用的 envelope-from 對應網域，並把 SPF 放在該網域根位置或官方要求的位置。

錯誤 6：把 ~all 改成 -all 太早

如果你的寄件來源尚未完全納入 SPF 規則，硬性失敗會直接讓寄件被拒。

修正：上線初期可先用 ~all，確認所有寄件來源都通過後再評估是否收緊。

第八章：上線策略：如何避免半夜才發現投遞問題

很多公司或個人第一次導入 GCP 郵件，都會遇到同一種心理：先設定、等個運氣。這做法在 DNS 環境很容易「晚一點才看到錯」。

GCP國際帳號開通 我建議你採用更穩的上線策略：

• 先在非高峰測試：例如白天先測一輪，確認外部接收正常。
• 設定完成後等待 TTL：再進行正式測試，避免你把 DNS 快取造成的延遲誤判成設定錯。
• 先保守再收斂：SPF 先用 softfail（~all）穩定過渡，再視需要收緊。
• 保留變更紀錄：每次改動把時間、原因與變更內容記下來，出問題時你可以快速回溯。

第九章：結語—MX 決定能不能送到，SPF 決定能不能被信任

當你把「MX 是路由、SPF 是授權」這件事想清楚，就能用理性的方式處理設定：先確認郵件要投遞到哪裡，再確認寄件身分是否被外部接受。

如果你照著本教學的節奏做：核對服務目標、正確新增 MX、正確設定單一 SPF、並按 TTL 等待與驗證，成功率會大幅提升。剩下的不是玄學，而是細節：欄位填對、不要重複、不要猜測。

你可以把這次設定當作一個起點。當之後你要加入 DKIM、DMARC 或做多網域寄件策略時，你會更快、更穩地把 DNS 變成真正可靠的郵件基礎設施。