設定 DNS 讓 MX 變成其他供應商

· 約 11 分鐘閱讀
mailbox.orgCloudflareE-mailSMTP 安全

訂閱好 E-mail 服務後，就可以設定 DNS，將 MX 記錄指向新的供應商。
這樣就可以用自己的域名寄信了。

轉移供應商前置作業#

我相信大多數人買域名後，會用自己的域名收信吧？
尤其是你在 Cloudflare 買域名，就有 Email Routing 可以開。

這時就要把 Cloudflare Email Routing 關閉，因為 DNS 機制上，一個域名的 MX 只能指向一處，開著 Cloudflare Email Routing 會跟其他供應商的 MX 設定衝突。
像是我在用的 mailbox.org 就是這樣。
Fastmail 則是允許 MX 和 NS 都不指向 Fastmail（對應官方 “no NS or MX” 設定），只是會犧牲一些功能，像是無法做 loop detection、垃圾郵件過濾效果變差、網域會被標示 Inactive。
Proton Mail 官方沒有明文禁止混用，但因為 Proton 對 Proton 的信件會被強制走 E2EE 路由(不理會你設定的 MX)，這個產品設計讓混用其他供應商幾乎等於不可行。

想獲得 Fastmail 最完整的設定體驗，或者你像我一樣用 mailbox.org，可以參考以下文章。

如果你像我一樣，有設定安全性，那就需要先關閉 E-mail 相關的安全記錄，再關閉 Cloudflare Email Routing，最後才可以設定新的 MX 記錄。
這個順序不能錯，錯了修改會很麻煩，並且會影響 E-mail 收發信。

關閉 DMARC#

DMARC 記錄是用來保障寄信時，證明是自己寄信的記錄。
DMARC 會檢查 SPF 和 DKIM 是否都沒有通過與寄件網域的對齊（alignment）檢查，如果都沒對齊，收件者的 SMTP 就會依照 DMARC policy，決定拒收、標記為垃圾郵件，或者繼續送達收件者。

但因為此時我們需要更換 MX，這時會發生 MX 記錄和 DMARC、SPF 和 DKIM 記錄對不上的問題，所以要關閉 DMARC。

這裡就以 Cloudflare 為例，我們進入到 Dashboard 後，找到 DMARC Management，確認 DMARC policy 是 none，如果不是要記得降級成 none：

像我的圖片中，我的 DMARC 是 Reject (SPF 和 DKIM 等驗證對不上，就退回寄件伺服器)。

設定方式很簡單，按右上角的 View analysis (在 BIMI in use 上面)，會進入 Email security record analysis 頁面。
找到你的 DMARC，底下會有一筆記錄，點最右邊三個點 ...，有個 Edit 按鈕。
這時候就會有記錄編輯界面，記錄的右邊有個 Edit，點下去，你會看到 Content 很多東西，找到 p=reject 或 p=quarantine，把它改成 p=none，DMARC 就成功關掉了。

NOTE

如果這一步沒做，等等遷移 MX 時，MX、SPF 和 DKIM 沒設定好時，你在測試寄信時 p=reject 寄信會直接退件，p=quarantine 則會把信寄到對方的垃圾郵件。

關閉 Cloudflare Email Routing#

接下來就可以關閉 Cloudflare Email Routing 了，在 Dashboard 找到 Email Service -> Email Routing。
點進去後，上面那排找到 Settings，點進去往下拉，看到 Disable，點下去就可以關閉了。

然後 Cloudflare 會列出被刪除的記錄。
嗯？沒有 DMARC 記錄？這樣最好，如果 DNS 是 Cloudflare 代管，DMARC Report 就可以使用，不用自己處理 DMARC 接收和報告。

轉移供應商#

這時候就要把其他供應商的記錄，加入到 DNS 記錄裡面。
這裡以 mailbox.org 為例，如果你不是 mailbox.org，請參閱供應商的 Docs 或 help。

設定別名#

根據 mailbox Knowledge Base 寫的說明，首先到設定 -> 找到 Email addresses -> 第一塊 Email aliases -> 往下拉到 add external alias -> 用自己的域名設定別名位址。
這裡用 postmaster 為例。

這時候你會看到失敗，因為域名認證失敗(不確定你是不是擁有者)。
然後他會給你 Securitycode，要你放到 DNS 記錄內，他所提供的記錄是 BIND9 風格。

如果你 DNS Server 正好 Self-host，而且還是 BIND9 ，那直接貼上即可。
如果你是第三方代管，那會需要稍微讀懂域名格式。

這裡我就用 Cloudflare 為例，他新增域名是新增子域名名稱、下拉選單選記錄類型，以及記錄內容。
記錄格式是這樣的：<hash1>.<yourdomain> IN TXT <hash2>
寫到 Cloudflare 就是把 <hash1> 寫到 Name 裡面，把 <hash2> 寫到 Content 裡面，記錄類型 Type 選 TXT。

這時候回去設定加入別名，就成功了。

NOTE

postmaster 是 RFC 2142 定義的保留信箱名稱，RFC 5321 §4.5.1 則進一步強制規定，任何支援轉發或收信的 SMTP 系統都必須支援這個地址，並盡最大努力接受寄給它的信。
這個位址存在的意義，就是為了在別人想聯絡你、而你的 E-mail 服務出問題時(比如 SPF 錯誤、TLS 憑證過期等)，提供最後的聯絡窗口。

新增 MX 記錄#

這時候就要設定 MX 記錄了，根據 Knowledge Base，可以看到 mailbox 有 4 個 MX 伺服器，每個伺服器 Priority 都是 10。

你可以看到圖表上，Domain 寫「example-domain.com」，我前面設定別名，就是用 just-passersby.net，那這裡就是填入 just-passersby.net。
看到這篇文章的其他人，記得替換成自己收發郵件的域名。

這裡一樣附上 Cloudflare 設定界面參考：

SMTP 安全設定#

好了，接下來就要設定安全設定了，這裡有 inbound 和 outbound，inbound 是 MTA-STS 和 DANE for SMTP，outbound 是 SPF、DKIM 和 DMARC。

這裡我強烈建議 outbound 這邊一定要設定完，這會直接影響你的 Domain 寄信信譽。

還原 DMARC 和其他安全記錄#

先來看看 SPF、DKIM 和 DMARC 沒設定會怎麼樣？
在 KB 的 How to improve spam reputation and avoid delivery errors 章節裡，就示範了 mailbox 沒設定這些規則，和規則不符合的情景，寄信給 Gmail 直接被退。

在 mailbox KB 的 Example DNS records 的記錄就可以直接使用。

SPF#

那我們先從最基本的 SPF 設定開始，直接照這上面打即可。

SPF 是用來驗證寄件者位址的協定，全稱是 sender policy framework，寄件者政策框架。
運作方式是檢查開頭有寫 v=spf1 的 TXT 記錄。
然後通常是添加 include 記錄就好，只有被參數指定的域名才能寄信，SMTP 伺服器看到這筆記錄，會額外檢查指定域名的 TXT 記錄。

他同樣也可以指定 ip 和 ip6，指定哪些 IP 是授權的機器。
現在指定 IP 和 mx 參數比較少用，通常直接用 include 就好。

比較重要的是 all 參數：

  • ?all 是 Neutral（中立），代表不對這封信下任何判定，等同沒有設定 SPF，之後仍可能被其他反垃圾機制擋下。
  • ~all 則是 Soft fail，如果 SPF 參數對不上，要 SPAM Filter 多多注意是不是垃圾郵件。
    一般來說，我最推薦使用 ~all，因為現代的 Email 環境比較複雜，會碰到信件轉發的問題，這個等等的 DMARC 會說到。
  • -all 的話，只要看到寄信來源不是 SPF 前面 include、ip、ip6 和 mx 授權的位置，就會直接 Reject。

DKIM#

DKIM 全稱是 DomainKeys Identified Mail，用公鑰交換來驗證 Key。
他也是 TXT 記錄，如果回去看我關閉 Cloudflare Email Routing 的確認畫面，可以看到他也是 TXT 記錄。

如果是 Self-host SMTP 伺服器，這個是要自己做公鑰生成和輪替的，但是以 Cloudflare Email Routing 為例，因為 DNS 就在 Cloudflare 上面。所以它可以幫你做設定和輪替。

但如果今天 SMTP 不是 Self-host，SMTP 供應商的 DNS 也跟我們不同家，現在業界更常用的方式就是用「CNAME 別名」。
以 mailbox.org 為例，他提供了 MBO0001~0004，你要在你的域名裡新增 MBO0001._domainkey.<your_domain>，並且用 CNAME 指向對應編號的 MBO0001._domainkey.mailbox.org.。
0001 到 0004 都要新增，mailbox.org 有設定四個 DKIM Key 可以輪替，除了有四筆記錄外，MBO 也代表允許多 Key 交換。

使用 CNAME 的好處是，我們使用者不用自己維護記錄和生成金鑰。
即使 DKIM Key 由供應商生成，自己維護 TXT 記錄有可能碰到 Key 過期忘記換，或者在新增記錄時，手滑 Key 打錯、複製錯之類的。
用 CNAME 的話，使用者不需要太大負擔，只要一次新增一筆記錄就好，然後公鑰輪替由供應商操心就好，Google、微軟等大公司，通常也是用這個方式來提供 DKIM 記錄。

DKIM 做起來很複雜，所以我只解釋 DKIM 不用 TXT 而是用 CNAME 怎麼運作。
但在此之前，我也先附上我的 Cloudflare 設定，給大家參考，新增記錄時，大家自行替換自己的域名：

可以看到，橘雲我沒有開，DKIM CNAME 記錄不用開橘雲，因為不是 Cloudflare 維護。

CNAME 記錄在查詢時，他會回應另一筆記錄，說明「我這一筆記錄，跟另一筆記錄結果相同」。

我們來做個實驗，查詢記錄看會怎麼樣。
這裡我先查 DKIM MBO0003 的記錄為例子：

~
❯ dig MBO0003._domainkey.just-passersby.net.

...

;; QUESTION SECTION:
;MBO0003._domainkey.just-passersby.net. IN A

;; ANSWER SECTION:
MBO0003._domainkey.just-passersby.net. 300 IN CNAME mbo0003._domainkey.mailbox.org.

;; AUTHORITY SECTION:
mailbox.org.            900     IN      SOA     ns.jpberlin.de. root.jpberlin.de. 2014143253 40000 7200 604800 86400

這時候他會看到有 CNAME，是 mbo0003._domainkey.mailbox.org.。
因為 dig 預設查詢的是 A 記錄，所以要指定 TXT 記錄查詢，這時候來查詢 mbo0003._domainkey.mailbox.org.:

~
❯ dig TXT mbo0003._domainkey.mailbox.org.

...

;; QUESTION SECTION:
;mbo0003._domainkey.mailbox.org.        IN      TXT

;; ANSWER SECTION:
mbo0003._domainkey.mailbox.org. 768 IN  TXT     "v=DKIM1; k=ed25519; " "p=k1A30Je8LhsVpcOQrwHOnw0OUj3BP0gXh8nHOgl6t4Y="

...

那如果直接在我的域名上，直接新增 TXT 查詢參數會怎麼樣？

~
❯ dig TXT MBO0003._domainkey.just-passersby.net.

...

;; QUESTION SECTION:
;MBO0003._domainkey.just-passersby.net. IN TXT

;; ANSWER SECTION:
MBO0003._domainkey.just-passersby.net. 300 IN CNAME mbo0003._domainkey.mailbox.org.
mbo0003._domainkey.mailbox.org. 3600 IN TXT     "v=DKIM1; k=ed25519; " "p=k1A30Je8LhsVpcOQrwHOnw0OUj3BP0gXh8nHOgl6t4Y="

...

沒錯，其他 SMTP 伺服器收到信，驗證 DKIM 時，會看到 mailbox.org 維護的記錄，我們使用者不用親自維護記錄了！

DMARC#

這裡的 DMARC 其實有點難一次設定，因為要小心寄信後，出於各種原因，導致你的信被莫名當 SPAM 或甚至直接被退回來。

這也是為什麼前面建議 DMARC 要先設定成 p=none。
這樣寄信出去，即使 SPF 和 DKIM 都設定錯誤，也能先保證能寄出去。

一般來說，即使 DMARC 設定是 p=none，SPF 和 DKIM 也是會保護網域沒有被假冒。
除非你碰到有人自己建立合法的 SMTP，然後假冒你的域名，這時候就會碰到 DKIM 簽名對齊，但是信不是你寄的信，這時就是 DMARC 的發揮作用。

但也因為寄信環境複雜，有時候可能是自動化表單，有時碰到奇怪的 SMTP Forwarder，會讓你的 SPF 或 DKIM 對齊失敗。
所以在提高 DMARC 安全政策之前，我建議先寄幾封信，然後收幾個 Report，mailbox KB 也是如此建議。
我這次測試總共寄了 4 封信，但 DMARC report 最後只收到 2 筆記錄，這是正常的，因為 DMARC 不是每個域名都會回報對齊情況，mail-tester 就是一個不會回報的例子。
剩下有回應的 2 筆，剛好對應到我自己寄給 Gmail，和朋友的 Cloudflare Email Routing 位址這兩種情況，來附上圖表：

當我自己寄給自己的 Gmail 時，可以看到 Sending Service 是 Heinlein-Support GmbH，這是 mailbox.org 的業者名稱。
SPF 和 DKIM 都設定正確，所以直送可以看到兩個都對齊。
點開完整郵件，可以看到 Authentication-Results 欄位，我的 SPF、DKIM 和 DMARC 全 pass:

Authentication-Results: mx.google.com; dkim=pass header.i=@just-passersby.net header.s=MBO0001 header.b=mZgVViz2; spf=pass (google.com: domain of myaddress@just-passersby.net designates 2001:67c:2050:103:465::111 as permitted sender) smtp.mailfrom=myaddress@just-passersby.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=just-passersby.netReceived: from smtp1.mailbox.org (unknown [10.196.197.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (No client certificate requested) by mout-y-111.mailbox.org (Postfix) with ESMTPS id 4h7T9z21wtzMlh6 for <mygmailaddress@gmail.com>; Sun, 26 Jul 2026 19:24:39 +0200 (CEST)

至於我寄給我朋友，用 Cloudflare Email Routing 建立的郵件位址。
你會看到，SPF 失敗了，怎麼會這樣？
來看朋友傳給我的截圖：

你會發現 mailed-by 是 youn.gg，代表他是透過 youn.gg 寄給我朋友的 Email。
怎麼會這樣？因為 Cloudflare E-mail Routing 是寄信到 Cloudflare，然後 Cloudflare 會做 SRS (Sender Rewriting Scheme)。

SRS 仍舊會通驗證，但因為已經變成 Cloudflare 寄送了，所以 SPF 會跟我們的政策對不上，真正的驗證要看 forwarder。
因此就會看到，寄信者寫 Cloudflare，SPF 對齊失敗，但是 DKIM 有對齊成功。
一般來說，看到不是你的供應商的寄件者，然後看到 SPF 0% + DKIM 100%，那代表你的目的地有經過轉發。

DMARC 報告最該警覺的是 DKIM 不是 100% 的列，所以不要因為 SPF 0% 就永遠的 p=none，而是多寄幾封信，確認沒問題再來逐步縮緊。

補充：abuse 位址設定#

這個就是比較重要的位址，同樣也是 RFC 2142 定義，abuse 是用來接收「你的域名有人濫用」用的。
通常會發生這類事情，要麼是你的自動化寄信出問題，不然就是你的網域開始到處發釣魚信之類的。
一旦對方或其他人要跟你通報，第一件事就是寄信到 abuse。
如果沒人通報，那要麼等 DMARC report，要麼就是真的爛掉了。

尤其 blocklist 營運者 (比如 Spamhaus、SpamCop)，一旦偵測到濫用行為模式就可能直接把你的網域或 IP 列入清單；這時 abuse@your.domain 是否有效可用，會直接影響之後申訴、移除列管的速度，聯絡不上會讓整個處理更困難。

小結#

到這裡，outbound 這塊（SPF、DKIM、DMARC）算是設定完整了，寄信的信譽問題基本上解決。

但寄信之外，收信同樣重要，inbound 側也有設定要做，避免對方 SMTP 傳輸時被降級成明文傳輸，或者被中間人攻擊。
outbound 這塊已經花了不少篇幅，inbound（MTA-STS、DANE）本身也是個大主題，所以留到下一篇再細講。

Reference#

留言