全球 TXT 紀錄查詢
TXT (Text) 紀錄最初在 1980 年代被設計為一個簡單的沙盒，讓系統管理員在區域檔中留下人類可讀的註解，如今已演變為現代網路安全中最具結構關鍵性的元件之一。由於 DNS 協定幾乎不對 TXT Payload 應用任何語法驗證，因此開發人員和安全平台利用這些紀錄來儲存任意的機器可讀資料字串。今天，TXT 紀錄主要用於嚴格的電子郵件驗證框架、加密金鑰散佈，以及自動化的網域所有權驗證。
電子郵件驗證三巨頭：SPF、DKIM 和 DMARC
如果從您的網路應用程式或企業伺服器發出的外寄電子郵件直接進入了垃圾郵件匣，設定錯誤的 TXT 紀錄幾乎總是罪魁禍首。現代的接收 MTA（如 Microsoft 365 或 Gmail）要求透過三個特定的 TXT 政策提供身分的加密證明：
- SPF (Sender Policy Framework)：一種格式嚴謹的 TXT 字串（例如
v=spf1 include:_spf.google.com ~all），作為公開的白名單。它授權特定的 IP 區段和第三方發送服務（如 Mailgun 或 SendGrid）代表網域發送郵件。 - DKIM (DomainKeys Identified Mail)：一個包含大型 Base64 編碼公開加密金鑰的 TXT 紀錄。您的外寄郵件伺服器會對電子郵件標頭進行雜湊處理，並使用私密金鑰進行簽署。接收伺服器會從這個 TXT 紀錄中擷取公開金鑰，以數學方式驗證簽章，確保 Payload 在傳輸過程中未被竄改。
- DMARC (Domain-based Message Authentication, Reporting, and Conformance)：執行層。此 TXT 紀錄指示接收伺服器如何處理未能通過 SPF 或 DKIM 檢查的訊息，規定是否要應用
p=none（監控）、p=quarantine（送至垃圾郵件）或p=reject（完全拒絕）政策。
自動化網域所有權與零信任 (Zero-Trust)
除了電子郵件之外，TXT 紀錄是證明對網域名稱具有管理控制權的通用標準。當將網域與雲端供應商（如 Google Search Console、GitHub Pages 或 AWS SES）整合時，平台會產生一個隨機的加密雜湊值。透過要求管理員將此雜湊值發佈為 TXT 紀錄，供應商即可透過自動化的 DNS 查詢確認使用者持有對該網域路由基礎架構的 root 層級存取權限。同樣地，Let's Encrypt 所使用的 ACME 協定也嚴重依賴 DNS-01 挑戰，其中會部署一個暫時的 TXT 紀錄來授權核發萬用字元 (wildcard) SSL/TLS 憑證。
位元組限制與字串串接 (String Concatenation)
開發人員經常遇到的一個技術限制是 DNS 規範中每個 TXT 區塊 (chunk) 的 255 個字元字串限制。當發佈龐大的 Payload 時，例如用於 DKIM 的 2048 位元 RSA 金鑰，Payload 會超出此位元組限制。為了解決這個問題，標準的 DNS 軟體（如 BIND）會自動將冗長的紀錄分割成多個以引號括住的字串（例如 "string1" "string2"）。用戶端解析器負責在讀取過程中無縫地將這些區塊串接回來。