Defaults.Exposed › 修復 › MX 記錄（郵件接收設定）

如何修復 MX 記錄（郵件接收設定）

MX 記錄是一塊路標，告訴全世界該把寄往你網域的郵件投遞到哪裡。它一旦缺失或損壞，所有發給你公司的郵件——客戶諮詢、密碼重置、發票、合約——都會原路退回給發件人。沒有 MX，就沒有收件匣。

對您業務的關鍵影響： 如果你的 MX 記錄缺失或出錯，你的網域就根本收不到郵件。給你寫信的客戶會收到報錯，以為你在無視他們、或已經倒閉。你連那些訊息都看不到——包括需要回覆的生意、發票和緊急問題。

這會讓您付出什麼代價

• 一個潛在客戶填了你的「聯絡我們」表單，或給你名片上的地址發郵件。郵件被退回。他不會再試一次——他去找了競爭對手，而你永遠不知道有過這次諮詢。
• 一個供應商發來一張逾期發票和一封最終通知，兩封都悄無聲息地被退回。你第一次知道，是某項服務被切斷，或收到一封催債函。
• 你註冊一個新工具、銀行入口或政務服務，它給你的網域發來一封驗證或密碼重置郵件。它從未抵達，於是你被擋在一件今天就要用的事情之外。
• 郵件本來好好的，後來有人在搬遷網站時動了 DNS，MX 記錄被丟掉了。接下來好幾天，發給全公司的每一封郵件都在無人察覺的情況下悄悄消失，直到有人發現收件匣怎麼突然安靜了。
• 一個想冒充你的人注意到你的網域既沒有郵件設定也沒有保護，於是開始拿它做文章——因為一個沒人盯著的網域，最好下手。

為什麼它重要。 郵件的投遞取決於一次 DNS 查詢：發件郵件伺服器問「這個網域的郵件該投到哪兒？」並從你的 MX 記錄裡讀出答案。如果沒有答案，或答案指向無處，郵件就被拒收並退回。這是郵件管道裡最基礎、孤注一擲的一環——它一旦出錯，你郵件的其餘一切都無關緊要了，因為什麼都到不了。（唯一合法的例外是一個被刻意設為完全不接收郵件的網域，它有自己正確的設定。）

MX 記錄是什麼，大白話版

當有人給你網域下的任何人發郵件時，發件郵件伺服器必須先回答一個問題：「這個網域的郵件，我該投到哪裡？」 它透過查詢你網域的 MX 記錄——是 Mail eXchange（郵件交換）的縮寫——來找到答案。MX 記錄無非是你網域設定裡的一塊路標，寫著「把這個網域的郵件送到這台郵件伺服器」。

這就是它的全部職責。MX 記錄不儲存你的郵件，不保護它，也不決定誰能以你的名義發信。它就是信封上的地址，告訴郵政系統由哪個分揀中心處理你的郵件。地址寫對了，郵件就流進來。留空，或指向錯誤的樓，郵件就被原封退回，標著無法投遞。

這是郵件設定裡最根本的一環。其他每一項郵件控制——防偽造、加密、垃圾過濾——都假定郵件首先真能抵達你。MX 記錄正是讓這一點成真的東西。

這會讓你付出什麼代價

因為一條損壞的 MX 記錄對你而言是悄無聲息地失敗的——你只是停止收信，自己這端沒有任何報錯——損害往往是事後才被發現，木已成舟。幾個現實場景：

• 從未抵達你的諮詢。 一個潛在客戶給你網站上的地址發郵件。對他而言，郵件附著投遞失敗提示被退回；對你而言，什麼都沒發生。大多數人收到退信後不會再打電話——他們以為你不感興趣，轉向名單上的下一家。你永遠不會知道這條線索存在過，所以連它的代價都無從衡量。

• 你「無視」了的發票。 一個供應商發來發票，又發來催款，再發來最終通知——全都被退回。關係惡化了，某項服務被暫停，或一筆小帳單變成了一個催收問題，全因為郵件從未送到任何人面前。

• 被擋在自己的帳戶之外。 你想重置密碼、驗證一個新的銀行或政務入口，或領取一個軟體授權。確認郵件發往你的網域後消失了。於是一件例行事務，在最糟糕的時刻變成了一場客服工單的折磨。

• 悄悄要了郵件命的網站搬遷。 一個網頁設計師把你的 DNS 遷到新服務商，把網站記錄抄了過去——卻沒抄 MX 記錄。接下來好幾天，發往你公司每一個地址的每封郵件都在無人察覺中消失，直到有人把「最近怎麼有點冷清」和「我們的郵件壞了」聯繫起來。

• 看起來像廢棄了。 一個收不到郵件的網域，對客戶和自動信任檢查而言，讀起來都像一家並未真正運營的企業。它恰恰在你最想顯得成熟可靠的時刻，侵蝕著信心。

這些都不會自己宣告。這正是缺失的 MX 記錄比聽起來更危險之處：等你注意到時，你已經丟掉了再也找不回來的郵件。

它到底是什麼

你網域的 DNS 設定裡存著好幾類記錄。MX 記錄是管進來的郵件的那一類。一套能工作的設定長成一條或多條條目，每條都指明一台郵件伺服器並帶一個優先順序數字：

• 郵件伺服器名稱（你郵件服務商的「郵件交換」主機）。
• 一個優先順序數字——數字越小越先嘗試。多條記錄讓服務商能提供後備伺服器，於是即便一台繁忙或宕機，郵件仍能進來。

「好」長什麼樣： 至少一條有效的 MX 記錄，指向你實際所用郵件服務商的郵件伺服器——Google Workspace、Microsoft 365、你主機商的郵件服務或類似——並使用該服務商讓你用的確切伺服器名稱和優先順序。

那個重要的例外。 有些網域被刻意設為不接收郵件——比如一個只用於網站的網域，或純粹為保護品牌而持有的網域。聲明這一點的正確做法是一條空 MX 記錄：一條優先順序為 0、主機僅為一個點（.）的 MX 記錄。這是一項已發布的網際網路標準（RFC 7505），是不接收郵件的網域的正確答案——發件方會立刻收到清晰的「這個網域不接受郵件」拒收，而不是一段令人困惑的延遲。在本項檢查裡，正確發布的空 MX 以滿分通過——它是一個刻意、正確的選擇，而非過失。會失敗的是什麼都沒有，那與一個失誤無從區分。

它為什麼關乎你的評分。 這是一項計分檢查，在郵件安全類別中最高值 25 分。一個本該收郵件卻沒有 MX 記錄的網域，被標為中等嚴重度的不通過——因為實際上，它背後的企業無法透過郵件被聯繫到。一個正確接收郵件的網域，或一條正確發布的空 MX，拿滿分。

如何修復（免費，約 5 分鐘）

把這個交給你的 IT 人員或網站服務商——修復免費。 MX 記錄就在你網域的 DNS 裡，和你的網站地址設定在同一個地方。管理你網域或網站的人能在幾分鐘內零成本搞定。你只為信箱服務本身付費，而且僅當你還沒有一個時。

修復取決於你處於以下兩種情形中的哪一種。

如果你的網域「應該」收郵件卻沒有 MX 記錄

你需要把網域指向你郵件服務商的郵件伺服器。使用你服務商發布的確切記錄——下面的例子是典型值，但永遠從你服務商自己的設定頁面照抄當前的值，因為它們確實會變。

1. 登入你的 DNS 服務商——你網域設定所在的地方（例如 Cloudflare、GoDaddy、你的主機商或註冊商）。

2. 為你的郵件服務添加 MX 記錄：

   Google Workspace（當前單記錄設定）：

   • MX host：你的網域 → smtp.google.com，優先順序 1 （較舊的 Google Workspace 帳戶可能仍用以 aspmx.l.google.com 開頭、優先順序為 1 的五伺服器集，外加 alt1–alt4 伺服器、優先順序 5–10。兩者都有效——以你 Google 管理控制台顯示的為準。）

   Microsoft 365：

   • MX host：你的網域 → <你的網域用短橫線連接>.mail.protection.outlook.com，優先順序 0 （Microsoft 會在管理中心為你產生確切的主機名稱——從那裡照抄，別去猜格式。）

   其他服務商（你主機商的郵件、一個託管的 Zoho/Fastmail 等信箱）：從那家服務商的 DNS 設定說明裡逐字照抄 MX 主機名稱和優先順序。

3. 儲存，然後等待。 DNS 改動大約需 15–30 分鐘生效（偶爾更久）。給你網域下的一個地址發一封測試郵件，確認它能到。

如果你的網域「不應該」收任何郵件

發布一條空 MX，讓「這裡不收郵件」的狀態明確且正確：

1. 登入你的 DNS 服務商。
2. 添加一條 MX 記錄，優先順序為 0，主機僅為一個 .（單個點）。
3. 儲存。發件方現在會立刻收到一個符合標準的拒收，本項檢查也會通過。

如果你即將遷移 DNS 或主機

搬遷前，把你當前的 MX 記錄原樣記下來（連同你的 SPF、DKIM 及任何其他郵件記錄）。搬遷後，在新服務商處用完全一致的值和優先順序重建每一條，並在你宣布遷移完成前發一封測試郵件。搬遷時忘掉 MX 記錄，是企業意外讓自己郵件下線的頭號方式。

常見錯誤

• 把 MX 留空，而不是發布空 MX。 如果網域確實不收郵件，就用空 MX（0 .）明說。留空含糊不清，讀起來像過失；空 MX 才是正確、滿分的答案。
• 把 MX 指向錯誤的東西。 一個意外常見的錯誤，是把 MX 記錄指向你的網站伺服器，或一個你已棄用的舊服務商。郵件伺服器會盡職地往那裡投遞——然後失敗。永遠從今天實際託管你信箱的那家服務商照抄記錄。
• 在網站或 DNS 搬遷時丟掉 MX。 網站重新上線，大家鬆了口氣，郵件卻悄悄死了。把 MX（及其他郵件記錄）當作任何搬遷清單上的必查項。
• 手動改優先順序。 別去發明或「整理」優先順序數字。原樣填入你服務商指定的內容，包括所有備用伺服器，讓後備投遞持續生效。
• 以為 MX 能保護你免於偽造。 它不能。MX 只管進來的郵件。防偽造是 SPF、DKIM 和 DMARC——各自獨立的記錄，分開檢查。

一句話總結

MX 記錄是你郵件信封上的地址。它們正確時——或者對一個不接收郵件的網域正確設為空 MX——郵件就能抵達你，本項檢查也通過。它們缺失時，你的公司在郵件上無法被聯繫到，正在丟失它甚至都看不到的訊息。修復免費，幾分鐘搞定，很值得今天就交給管理你網域的人。

常見問題