DNS TXT 記錄是什麼？一篇搞懂它的用途與設定方式
更新日期： 2025 年 6 月 26 日
當你在網域 DNS 控制台裡設定紀錄時，可能會看到很多種紀錄類型（如 A、CNAME、MX、TXT 等）。
其中的 TXT 記錄 雖然不像 A 記錄那樣直接決定網站是否能被連上，但它卻在網站驗證、Email 防詐騙、安全驗證中扮演關鍵角色。
本文將帶你了解什麼是 TXT 記錄、它的應用場景、該如何設定，以及常見問題排查，一步步讓你搞懂這個常被忽略但實用度極高的設定。
TXT 記錄是什麼？基本概念
什麼是 TXT？
TXT（Text）記錄 是 DNS（網域名稱系統）中的一種記錄類型，用來在你的網域名稱底下儲存一段純文字資訊。
這段文字不會影響網站本身的運作或 IP 指向，但卻可以被其他服務或平台讀取，用來執行驗證、安全檢查或資訊傳遞等目的。
- 它不會直接影響網頁載入，但卻是很多「背景驗證」動作不可或缺的角色。
- 和其他記錄類型（例如 A 記錄把網址對應到 IP、MX 記錄讓你能收信）相比，TXT 記錄的角色比較像是「備註欄」或「對外說明書」，讓其他服務知道這個網域有哪些安全設定或擁有者聲明。
✅ 特性總結：
- 記錄格式：文字字串，可以是任意內容，但許多應用會有自己的格式要求
- 支援多筆：一個網域可以設定多筆 TXT 記錄
- 可被公開查詢：只要知道網域名稱，就能查詢這些 TXT 記錄內容
TXT 記錄的用途有哪些？
雖然 TXT 記錄只是一段純文字，但它在許多系統中都有實際而關鍵的功能，尤其是在Email 安全、第三方驗證、網域擁有權證明等情境中極為常見。
以下是最常見的 4 種應用場景：
| 用途 | 說明 |
|---|---|
| Email 驗證 | 透過設定 SPF、DKIM、DMARC，告訴其他郵件系統「哪些主機有權代表這個網域發信」、「怎麼驗證這封信沒被竄改」、「如果驗證失敗要怎麼處理」。這是對抗釣魚詐騙郵件的標準做法。 |
| 網域驗證 | 當你要將網域與 Google Search Console、Facebook 商務後台、AWS 憑證服務等系統綁定時，它們會要求你在 DNS 中加一筆 TXT 記錄，作為「你是擁有者」的證明。 |
| 安全用途 | 有些系統（例如 Facebook）會要求你新增 facebook-domain-verification=xxxxxx 這樣的 TXT 記錄來完成權限綁定，避免他人盜用你的網域進行廣告操作或 API 連結。 |
| 自訂資訊 | 除了驗證與安全用途，也可以儲存任意文字（例如服務名稱、API Key、版本資訊等），供公司內部或第三方工具讀取，是一種開放式的擴充欄位。 |
💬 舉例讓你更有感
- 當你申請 Google Workspace（企業信箱），系統會要求你新增一筆 TXT 記錄，用來驗證你是否真的擁有
yourcompany.com這個網域。 - 當你要防止詐騙信件冒充你的信箱寄信給客戶，會需要設定 SPF、DKIM、DMARC，這三種通通都需要用 TXT 記錄完成。
- 當你想使用 AWS 申請 SSL 憑證，但你沒有辦法用 HTTP 驗證，就可以改用新增 TXT 的方式來完成域名驗證。
最常見的用途：Email 驗證（SPF、DKIM、DMARC）
在現代電子郵件傳送系統中，為了防止詐騙、釣魚信、冒名發信等問題，許多郵件服務提供商（如 Gmail、Outlook、Yahoo）都會檢查寄件網域的 TXT 記錄 中是否有設定下列三種驗證機制：
| 驗證機制 | 作用說明 |
|---|---|
| SPF | 驗證「這封信是不是從授權的伺服器發出來的？」 |
| DKIM | 驗證「這封信有沒有在傳送過程中被竄改？」 |
| DMARC | 定義「如果 SPF 或 DKIM 驗證失敗，該怎麼處理？」 |
這三種機制缺一不可，是現代 Email 安全的基本防線。以下分別說明。
SPF（Sender Policy Framework）
📌 功能：
SPF 用來聲明「哪些伺服器有權以這個網域的名義發信」。如果發信的主機 IP 沒有列在 SPF 授權清單中，收件伺服器就會認為這封信「可能是偽造的」。
🔧 設定方式：
在 DNS 中新增一筆 TXT 記錄，格式如下：
@ TXT "v=spf1 include:_spf.google.com ~all"v=spf1：版本（固定開頭）include:_spf.google.com：授權 Google 的伺服器可發信~all：代表其他非授權伺服器寄出的信件會被標示為「soft fail」（可能是假信）
🧠 常見錯誤：
- 設錯 include 網域
- 沒有加上
all結尾，導致無效 - 同一個網域有多筆 SPF 記錄（應該合併為一筆）
DKIM（DomainKeys Identified Mail）
📌 功能：
DKIM 是一種「數位簽章」機制，寄信方會在信件中加入簽章，收信方會去 DNS 查詢「公開金鑰」來驗證這封信有沒有在中途被竄改，並確認發信人為真正擁有該網域的單位。
🔧 設定方式：
- 郵件系統會自動為每封信產生簽章（Header 裡的 DKIM-Signature）。
- 你需要在 DNS 中新增一筆 TXT 記錄，放入「公開金鑰」。
範例：
google._domainkey.yourdomain.com TXT
"v=DKIM1; k=rsa; p=MIGfMA0GC...（很長的 Base64 公鑰）"google是選擇的 selector 名稱（由系統產生）_domainkey是固定字串，代表這是 DKIM 用的記錄p=後面接的是 RSA 公鑰
🧠 常見錯誤：
- 金鑰貼錯格式，漏了引號或換行
- selector 名稱不一致，導致收件方查不到簽章對應的公開金鑰
DMARC（Domain-based Message Authentication, Reporting and Conformance）
📌 功能：
DMARC 是在 SPF 和 DKIM 的基礎上，再加一層「策略設定」機制。你可以指定：
- 收到冒用你網域的 Email 時，該不該擋下來？
- 是否要寄送驗證報告給你（讓你知道有沒有人冒用你的網域）？
🔧 設定方式：
在 DNS 中新增一筆 TXT 記錄，格式如下：
_dmarc.yourdomain.com TXT
"v=DMARC1; p=reject; rua=mailto:[email protected]"參數說明：
v=DMARC1：版本（固定）p=reject：策略是「驗證失敗就拒收」（也可以設為none或quarantine）rua=：寄送報告的信箱地址（可選）
策略值比較：
| 策略值 | 行為說明 |
|---|---|
| none | 不採取行動，只記錄事件並回報 |
| quarantine | 將驗證失敗的信件標為垃圾信 |
| reject | 直接拒收驗證失敗的信件 |
🧠 常見錯誤：
- 設成
none但忘了收報告，無法發現冒名寄信的情形 - 設太嚴格導致合法信也被擋（例如 SPF/DKIM 設錯）
它們如何一起運作？
寄出一封 Email 時，收件方會依序進行以下檢查：
- 查 SPF → 寄信 IP 是否在授權清單中？
- 查 DKIM → 信件是否有通過簽章驗證？
- 查 DMARC → SPF 和 DKIM 有沒有其中一個成功？如果都失敗，要依 DMARC 政策怎麼處理？
✅ 只要你正確設定這三項，收件方就會更信任你的信件，不容易被標成垃圾信，還能防止他人假冒你寄信給客戶、同事或合作夥伴。
網站驗證用途：為什麼 Google、Facebook、AWS 都叫你設定 TXT？
當你想要把自己的網域與某些外部平台（例如 Google、Meta、AWS 等）綁定或進行驗證時，這些平台必須「確認你是真的擁有這個網域的管理權」，而最簡單的方法之一就是透過 DNS 加上一筆 TXT 記錄。
這個方式不需要你提供密碼，也不需要下載檔案，因為：
- 只有真正掌握 DNS 控制權的人，才有辦法新增 TXT 記錄
- 其他人即使知道你要填的驗證碼，也無法偽造 DNS 記錄
常見應用場景
| 應用平台 | 驗證目的 | 驗證方式（TXT 記錄） |
|---|---|---|
| Google Search Console | 驗證網站擁有權 | google-site-verification=xxxxxx |
| Facebook 商務管理後台 | 驗證網域所有權（Pixel/轉換 API） | facebook-domain-verification=xxxxxx |
| AWS Certificate Manager | 領取免費 SSL 憑證 | _acme-challenge 用於 DNS 驗證 |
| Vercel / Netlify / GitHub Pages | 驗證靜態網站部署網域綁定 | 通常也是透過 _acme-challenge |
為什麼選擇 TXT 驗證？
TXT 驗證的好處在於：
- ✅ 不影響網站內容：不用改首頁、不用上傳檔案
- ✅ 容易設定：只要有 DNS 權限就能處理
- ✅ 不需持續維護：設定一次驗證成功即可
實際範例
✅ Google Search Console 驗證
當你將網站加入 Search Console，Google 會提供一段驗證碼，並請你新增如下 TXT 記錄：
Name：@（或 yourdomain.com）
Value：google-site-verification=abc123xyzGoogle 系統會對你的網域發起 DNS 查詢，確認這筆 TXT 記錄是否存在。
✅ Let’s Encrypt / AWS 憑證驗證
如果你透過 DNS 驗證來取得 SSL 憑證，像是使用 AWS Certificate Manager（ACM）或 Let’s Encrypt，會要求新增像這樣的 TXT 記錄：
Name：_acme-challenge.yourdomain.com
Value：xxxxxxxxxxxxxxxxxx這是為了驗證你有權代表這個網域申請憑證。
設定正確後，憑證頒發系統會透過 DNS 查詢驗證，再核發 HTTPS 憑證給你。
如何實際新增 TXT 記錄？（以 Cloudflare 為例）
以下是設定 TXT 記錄的標準流程，其他平台如 GoDaddy、Gandi、Namecheap 也都大同小異。
操作步驟：
- 登入 DNS 控制台（如 Cloudflare）
- 點選你要驗證的網域
- 進入「DNS 記錄（DNS Records）」設定頁
- 點選「新增紀錄（Add Record）」
- 在「類型（Type）」選擇
TXT - 填入以下資訊：
- Name（名稱）：例如
@（主網域），或_acme-challenge、_dmarc等指定子網域 - Content（值）：驗證碼或要求輸入的字串（通常是一段亂碼）
⏳ 等待時間
- 通常 5 分鐘至幾小時內生效
- 最長可能需等待 24 小時（視 DNS TTL 設定與快取狀況）
🔍 驗證是否成功的方式
你可以使用以下工具查詢 TXT 記錄是否成功寫入：
- Google Admin Toolbox – DIG 工具
- 或終端機輸入：
nslookup -type=TXT yourdomain.com或：
dig TXT yourdomain.com +short這些查詢會返回你所設定的 TXT 內容，確認記錄已經被正確寫入並對外可見。
為什麼 TXT 記錄要公開查詢？
因為 DNS 是一個公開查詢的系統，它的本質就是「任何人都可以詢問某個網域的設定（A、MX、TXT 等）」，這樣外部服務如：
- 收信方的郵件伺服器（要看你的 SPF / DKIM / DMARC 設定）
- Google Search Console（查 TXT 來驗證你是否是擁有者）
- Facebook / AWS / Netlify（也是查 TXT 來驗證）
才有辦法不登入、不密碼 就知道你是否擁有這個網域、或有沒有正確設定防詐騙機制。
🧠 換句話說：TXT 的「可查詢性」就是它「防偽」的關鍵之一。
如果不公開查詢，會出什麼問題？
1. ✅ 無法驗證擁有權
像 Google、Facebook、AWS 都會查詢 DNS 中的 TXT 記錄，來驗證你是否擁有某個網域。如果無法查到，它們會拒絕你綁定該網域。
2. 📭 郵件可能進垃圾信
收件方的郵件伺服器通常會查詢寄件人的網域 SPF、DKIM、DMARC 設定（TXT 記錄），如果無法查到：
- 信件就可能被視為詐騙
- 或直接丟進垃圾信件匣
3. 🚨 更容易被冒用
如果大家都不能查到你聲明的「誰能代你發信」，反而更容易被駭客偽造，因為沒辦法比對真偽。
公開的 TXT 記錄，會不會被濫用或偽造？
這是很多新手在學習 DNS 設定時的常見疑問：TXT 記錄能被任何人查詢，這樣不會有安全風險嗎？會不會被有心人偽造或濫用？
其實這裡有一個很重要的觀念是：
✅ 「可被查到」不代表「可以偽造」，而且公開查詢反而是「防偽」的必要條件。
以下我們就從兩個層面來解釋。
第一層：可查 ≠ 可偽造
📌 查詢是驗證的基本條件
像 SPF、DKIM、DMARC、Google 憑證驗證這些功能，都是透過第三方系統「主動查詢你 DNS 中的 TXT 記錄」來完成驗證。如果這些資訊不公開，就無法執行自動化驗證機制。
想像一下：如果你在門口貼一張公告「本公司只接受官方快遞」，這個公告本來就應該是公開的，否則快遞員怎麼知道該不該送？
🔒 為什麼不能偽造？
因為系統查的是「權威 DNS 回應」的內容。即使攻擊者知道你的 SPF、DKIM 記錄內容，他也無法：
- 更改 DNS 內容（除非他入侵你的 DNS 控制台）
- 偽造 DNS 回應給驗證方（除非中間人攻擊，但 DNSSEC 現在逐步解決這問題）
➡️ 換句話說：驗證者只相信實際查詢 DNS 得到的內容，而不是攻擊者聲稱的資訊。
你說得對，那段說明不夠清楚、舉例也不夠直觀。我來幫你重新寫一個更具體、更容易理解的版本：
🧠 舉例說明：為什麼知道 SPF 記錄內容也無法偽造？
假設你擁有一個網域叫做 mycompany.com，你在 DNS 裡設定了以下 SPF 記錄：
v=spf1 include:_spf.google.com ~all這表示：只有經過 Google 認證的郵件伺服器，才有權幫 @mycompany.com 發送 Email。
📬 情境：駭客試圖冒充你寄信給別人
駭客想寄一封詐騙信，偽裝成你的客服信箱 [email protected]。他知道你的 SPF 記錄是上面那串，也試圖用他的伺服器發信。
🔒 發信過程中，會發生什麼事？
- 駭客寄出信件 → 收件方郵件伺服器接收到這封看起來來自
@mycompany.com的 Email。 - 收件方伺服器進行 SPF 驗證：
- 它會主動查詢
mycompany.com的 DNS TXT 記錄。 - 發現 SPF 政策規定「只有
_spf.google.com的 IP 有發信權」。
- 比對發信 IP：
- 系統比對駭客的 IP 和
_spf.google.com所屬的 IP 範圍。 - 發現駭客用的 IP 不在授權範圍內 → 驗證失敗。
- 處理方式：
- 根據你的 SPF 政策（這邊是
~all，即軟退回），系統會將信標記為「可疑」或直接丟到垃圾信件匣。
✅ 重點來了
即使駭客完全知道你 SPF 的內容：
v=spf1 include:_spf.google.com ~all他依然無法：
- 更改 DNS 記錄內容（除非他入侵你的 DNS 控制台）
- 騙過收件方（因為收件方會自己去查 DNS，不聽駭客講的）
🧱 簡單比喻
這就像是：
- 你在店門口貼了公告：「本店只接受由順豐快遞送來的包裹」
- 客人收到一個包裹，自然會看「是不是順豐快遞送來的」
- 即使詐騙集團知道你貼了這張公告，他還是沒辦法用別的快遞冒充順豐，因為送貨的那個人（＝IP）不是對的
第二層：不要放敏感資料在 TXT 裡
雖然 TXT 記錄格式上允許你輸入「任意文字」，但這不表示你可以把什麼都放進去。
⚠️ 不能放什麼？
- 密碼
- API Token / Secret
- 金融資訊（如信用卡號）
- 使用者個資（如 email、電話、身份證字號）
因為 DNS 是設計來給「所有人」查詢的，只要有人知道你的網域名稱，就可以執行查詢指令：
nslookup -type=TXT yourdomain.com
dig TXT yourdomain.com這就像是你在店門口貼了一張公告，任何人走過去都能看到——這不是保險箱，而是公告欄。
🧾 那應該放什麼？
- SPF、DKIM、DMARC 等 Email 安全政策
- Google / Facebook / AWS 等提供的驗證碼
- ACME DNS challenge（如 Let’s Encrypt 的 SSL 驗證）
- 自家服務用來讓程式讀取的設定值（不含私密資訊）
這些資訊本來就設計成「公開可讀」，用來讓外部服務確認真偽、完成驗證或實施安全策略。
有了這些概念，你就能正確設定 TXT 記錄，為你的網站和信箱增加一層安全防護，並順利整合各種雲端服務！
結論：TXT 記錄雖小，但影響巨大！
雖然 TXT 記錄不會讓網站變快、不會影響 Google 排名，也不會出現在畫面上。
但它的存在幾乎是所有專業網站、Email 系統與 API 服務的「隱形基礎建設」。
不懂 TXT 記錄，許多整合就會卡關；反之，掌握 TXT 的設定，你會發現很多平台串接起來變得超順利！