DANE 設定與說明

2026年9月15日· 約 6 分鐘閱讀

原本想寫在一起，但是寫完 DANE 後發現會太長，所以拆分。

確認是否支援 DANE#

一般來說，供應商會在官網寫說自己支援哪些安全性協定。
像是 Fastmail 不只支援 MTA-STS，甚至提供 DNS、MTA-STS 代管。
而 mailbox 則是在 Security 頁，說明自己支援除了 TLS 以外的協定，還對自家域名開啟了 DNSSEC，並且支援 HSTS、DANE、MTA-STS 等現代安全協定。

那假如你找不到官方是否支援，或者是你不相信官方說辭，你可以試試看查詢 TLSA 記錄。
如果官方明說不支援，或者你懶得部署，那就只好先說掰掰。

那如果你不知道怎麼查，請往下看——

(我不要我不要——看理論好麻煩，我只想實作，點這裡！)

原理說明#

在 RFC 7671 中，有說明 DANE 有怎麼設定。
而 DANE for SMTP 也有專門一篇，是 RFC 7672。

在 RFC 7671 中，Part 6 說明了 TLSA 記錄如何設定，對於客戶端域名 (Customer Domain)，設定一筆 CNAME 指向服務供應商。
並且還說明了——

如果是 MX、SRV 或相似記錄等，這類可重新導向的記錄，TLSA 記錄驗證會基於重新導向的域名，而不是來源域名。
以 SMTP 為例，如果 E-mail 服務由服務供應商提供，將 MX 記錄指向服務供應商的 SMTP 伺服器。
當客戶端域名完成簽署(開啟 DNSSEC)，MX 主機名稱即可安全地¹當做 TLSA base domain²，TLSA 記錄則由服務供應商發佈和維護。

RFC 7672 則提供了整個 DANE for SMTP 怎麼設定的說明，但主要是給架設 Mail Server 的供應商指引，DNS 記錄怎麼設。
在 Part 3.1 中，IETF 建議使用「DANE-EE(3) SPKI(1) SHA2-256(1)」，次選是「DANE-TA(2) Cert(0) SHA2-256(1)」。
所以你只要查詢 MX 的 DANE，你看到 TLSA 記錄後面是 3 1 1 或 2 0 1，代表供應商有做最佳實踐。

NOTE

補充：Part 3.1.3 有提到，若使用 PKIX-TA(0) 或 PKIX-EE(1) 類型的憑證，也就是依賴額外 CA 驗證，DANE for SMTP 可能會失效。

主要原因是 SMTP 伺服器間，不一定共同信任相同 CA，從而無法驗證伺服器，以及透過 DANE 避免 STARTTLS 降級。
也由於 PKIX CA 不提供額外保護，所以一旦 DNSSEC 被攻破，攻擊者可以自由更替掉非 PKIX 的非 TLSA 記錄。

記錄檢測#

以 mailbox.org 為例，我在上一篇提到，它有 4 個 MX Server，所以要查 4 個記錄，SMTP 的 TLSA base domain 是 _25._tcp。
mailbox.org 的 MX 則是 mxext1 到 mxext4.mailbox.org.，所以就是要查 _25._tcp.mxext1~4.mailbox.org.。
為了避免輸出太長，我用 dig 的 short 輸出。

bash / zsh:

for i in {1..4}
do
    dig +short TLSA _25._tcp.mxext$i.mailbox.org.
done

fish:

for i in (seq 4)
  dig +short TLSA _25._tcp.mxext$i.mailbox.org.
end

輸出如下：

╰─ for i in {1..4}
for> do
for> dig +short TLSA _25._tcp.mxext$i\.mailbox.org.
for> done
3 1 1 996AD31D65E03F038B8EC950F6F26611529DA03E3A283E4400CBA2ED D04B8A88
3 1 1 E41CC7633029AFDBA53744D7E5FC31EF507E592DE9DFB33557BF3B9A 79239446
3 1 1 4758AF6F02DFB5DC8795FA402E77A8A0486AF5E85D2CA60C294476AA DC40B220
3 1 1 4758AF6F02DFB5DC8795FA402E77A8A0486AF5E85D2CA60C294476AA DC40B220
3 1 1 996AD31D65E03F038B8EC950F6F26611529DA03E3A283E4400CBA2ED D04B8A88
3 1 1 E41CC7633029AFDBA53744D7E5FC31EF507E592DE9DFB33557BF3B9A 79239446
3 1 1 E41CC7633029AFDBA53744D7E5FC31EF507E592DE9DFB33557BF3B9A 79239446
3 1 1 996AD31D65E03F038B8EC950F6F26611529DA03E3A283E4400CBA2ED D04B8A88
3 1 1 4758AF6F02DFB5DC8795FA402E77A8A0486AF5E85D2CA60C294476AA DC40B220
3 1 1 E41CC7633029AFDBA53744D7E5FC31EF507E592DE9DFB33557BF3B9A 79239446
3 1 1 4758AF6F02DFB5DC8795FA402E77A8A0486AF5E85D2CA60C294476AA DC40B220
3 1 1 996AD31D65E03F038B8EC950F6F26611529DA03E3A283E4400CBA2ED D04B8A88

可以看到 mailbox.org 替每個 MX 設定了 3 個 TLSA 記錄，有 4 台 MX，正好就是 12 筆記錄。
每台都是 3 1 1，是最佳實踐。

這裡隨便挑一台，證明一台 MX 有 3 個記錄。

$ dig +short TLSA _25._tcp.mxext3.mailbox.org.
3 1 1 996AD31D65E03F038B8EC950F6F26611529DA03E3A283E4400CBA2ED D04B8A88
3 1 1 4758AF6F02DFB5DC8795FA402E77A8A0486AF5E85D2CA60C294476AA DC40B220
3 1 1 E41CC7633029AFDBA53744D7E5FC31EF507E592DE9DFB33557BF3B9A 79239446

但倘若你並不是很熟悉 Shell、迴圈，或者討厭 nslookup 又不想裝 dig (Windows 的部分)，也有專門檢查 DANE 的工具。
這裡我用同樣來自德國的 DANE SMTP 驗證器，我們把 mailbox.org. 輸入進去，你就會看到檢測結果。

上一篇說過，mailbox kb 讓我們設定的 MX 是 mxext1~4.mailbox.org.，所以多出來的 50 mx-n.mailbox.org 可以不用看。

好了，現在你知道，服務供應商有沒有做最佳實踐，但你是不是還不知道，為什麼你也要設定 DNSSEC？

原因是，DANE 依賴 DNSSEC 驗證記錄，到了客戶端，如果客戶端沒有設定 DNSSEC，就會變成客戶端的記錄，可以被偽造。

那假如很不幸的，你的供應商沒有設定 TLSA 記錄、第一個數子是 0 或 1 (比如 1 0 1、0 1 1 等)，不然就是壓根沒 DNSSEC，那底下的內容你也可以不用看了。
真的有興趣，或者等你換了供應商再回來看！
不然你開了 DNSSEC 並不能享受到 DANE 的保護，還要承受 DNSSEC 的風險，DANE 驗證器也會驗不過。

Cloudflare DNSSEC 設定#

這裡我以 Cloudflare 舉例，如果不是用 Cloudflare，或者你有多個平臺的 NS，需要自己處理 DS 交換，因為沒其他環境，所以以下不列出。
若已經設定完，請移駕到檢測自己的 SMTP DANE。

進入到你的 Domain 頁面，左邊找到 DNS 來開，然後按 Setting，第二個格子就是 DNSSEC 開啟按鈕。

開啟之後，Cloudflare 會開始幫你處理 Key exchange，處理完後就會看到 Success，按鈕也會從 Cancel setup 變成 Disable。

檢測自己的 SMTP DANE#

這時候你用 dig MX $YOUR_DOMAIN +dnssec，如果 flags 有 ad 和 RRSIG 記錄，就表示 DANE 正式完成，其他 MTA 寄信看到這筆記錄，會跟著看服務供應商的 TLSA 記錄。

如果你看到你在 Cloudflare 上，有開啟 DNSSEC，但是沒有 ad flags 和 RRSIG，用 dig $YOUR_DOMAIN DNSKEY 能看到 KSK 和 ZSK 記錄，那就表示你的 Resolver 不支援 DNSSEC 解析。
我所在學校的 Resolver 就不支援，這裡我附上我知道支援的，在 dig 後面加上 @ + 支援 DNSSEC 解析的 Resolver IP 就能測試。

支援 ad flags 的 Resolver:

Google 8.8.8.8
Cloudflare (例如 1.1.1.1)
中華電信 168.95.1.1

重點要看 flags 有沒有 ad，有這個 Flag 才代表你的簽章是正確的。

輸出參考：

─ dig MX just-passersby.net +dnssec @1.1.1.1

; <<>> DiG 9.10.6 <<>> MX just-passersby.net +dnssec @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4886
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;just-passersby.net.		IN	MX

;; ANSWER SECTION:
just-passersby.net.	300	IN	MX	10 mxext1.mailbox.org.
just-passersby.net.	300	IN	MX	10 mxext2.mailbox.org.
just-passersby.net.	300	IN	MX	10 mxext3.mailbox.org.
just-passersby.net.	300	IN	MX	10 mxext4.mailbox.org.
just-passersby.net.	300	IN	RRSIG	MX 13 2 300 20260911033041 20260909013041 34505 just-passersby.net. wCjY83BhKC1dafN65kPeCFLfgd8uZVpBdjlzAokha75TcSZPfqJblGVP ecHqXiLSqtr7ZRHLzdc4C7x+fYogaQ==

因為 dig 僅是傳話筒，它只是把 Resolver 的解析結果印出來而已。
所以 Resolver 在傳遞結果時，因為走的是 UDP 53，預設沒加密，所以結果是可篡改的。
因此如果你想自己跑驗證，更好的工具是 delv。

壞消息是 macOS 並不內建 delv (授權問題，dig 也是舊版)，但好消息是在 Linux 上，delv 通常和 dig 放在同一個套件，裝了 dig 通常就有。(至少 CachyOS 有)
所以你如果要最為可信的結果，就是自己跑 delv，自己去跑整個驗證，自己從 Root 驗證到自己的域名的公鑰。

指令：

delv MX $YOUR_DOMAIN

如果你看到 ; fully validated 代表你的 DNSSEC 才是成功的：

~
❯ delv MX just-passersby.net
; fully validated
just-passersby.net.     299     IN      MX      10 mxext1.mailbox.org.
just-passersby.net.     299     IN      MX      10 mxext2.mailbox.org.
just-passersby.net.     299     IN      MX      10 mxext3.mailbox.org.
just-passersby.net.     299     IN      MX      10 mxext4.mailbox.org.
just-passersby.net.     299     IN      RRSIG   MX 13 2 300 20260912112751 20260910092751 34505 just-passersby.net. E6ku+LgHAukCIHBocqgIs419pJCtSfn10d2eETO6tBAF+jho8yvsNMvG 1Jo8Z7tujJE2h/1JI4oZhzxhP2TssA==

如果你覺得指令好恐怖，或者你是 Windows，連 dig 都沒有，那你也可以試試看圖形化工具，這裡我用 DNSviz。

它可以幫你圖形化顯示驗證結果，以及整個信任鏈路關係。

你只看到 DNSSEC 有起來，但不知道這個代管機制真的有效？我們也可以用 DANE 驗證器來檢測：

你會看到一堆 not trusted 憑證，這很正常，因為這些多出來的憑證，不是目前使用的憑證，只是先放到 DNS 記錄內，或者已過期，自動過渡到新憑證。

DANE 也有 Reports？#

你寄信給別人，會有 DMARC Report，但你知道別人寄信給你，也有一個 Report 嗎？

這就是 TLS-RPT，我會放到下一篇的 MTA-STS 設定說明內。
任何有關 SMTP 的加密傳輸報告，都是利用這個協定。

(如果你看到 404，那就代表我還沒上傳文章)

Reference#

註解#

在 DNSSEC 中，「安全地」表示可被 DNSSEC 記錄驗證。 ↩
DNS 專業術語，以 TLSA 為例，就是 RFC 7671 說明的 _PORT._tcp.FQDN。 ↩