簡單說，TXT 記錄就是你網域在網際網路「電話簿」裡的一塊公開「公告／備註欄」——一段可以自由填寫的文字。它最常見的兩個用途，一是網域驗證（證明「這個網域真的是你的」），二是存放你的電郵安全規則（SPF、DKIM、DMARC）。當 Google 或 Microsoft 365 要你「加一條 TXT 記錄來驗證網域」時，讀完這一篇，你就知道那是什麼、安不安全、會不會洩露公司資料，也知道該把這件事交給誰去做，省得自己對著一串看不懂的字元發愁。
這篇文章適合誰看？ ❓
如果你有公司網域、用著企業電郵，又遇到過下面任意一種情況，這篇值得看：Google、Microsoft 或某個第三方服務要你「加一條 TXT 記錄來驗證網域所有權」；或者你聽過 SPF、DKIM、DMARC，卻不知道它們到底放在哪裡、為什麼和「網域」有關。如果你沒有自己的網域、也不打算用企業電郵，可以跳過這一篇。
先說為什麼會有 TXT 記錄
要理解 TXT 記錄，得先回到 DNS。DNS（網域名稱系統）是網際網路的電話簿：你給它一個好記的網域，它幫你查出伺服器真正的數字位址，訪客才連得上。想把這本電話簿和它的其他常用欄目一起搞懂，可以看我們關於 DNS 記錄 的文章。
電話簿裡，A 記錄登記「網站在哪台伺服器」，MX 記錄登記「電郵送到哪個收發室」。但人們還想在自己這條登記下面附一段普通的文字說明——既不是位址，也不是號碼，就是一段任何系統都能讀到的備註。早期的 DNS 沒有這樣一個通用欄目，於是 TXT 記錄被設計出來，專門在網域上掛一段自由格式的文字。它本來只是個「想寫什麼寫什麼」的欄目；後來大家發現這塊公開、人人可查、又只有網域擁有者能改的地方特別好用，就把兩件重要的事放了進來：網域驗證和電郵安全規則。
一條 TXT 記錄長什麼樣
在網域管理後台裡，一條 TXT 記錄通常由三部分組成。看懂這三欄，你再打開自己的控制台就不會發懵：
- 主機／名稱（Host / Name）：這條記錄掛在網域的哪個位置。對整個根網域生效時，通常填一個「@」；某些用途（比如下面會講到的 DKIM）則會要求填一個特定的前綴（叫「選擇器」）或子網域。
- 值（Value）：一段用引號括起來的自由文字，這才是記錄真正的內容——驗證字串、電郵規則，都寫在這一欄。
- TTL：這條記錄可以被各地伺服器快取多久。改動之後，舊值要等快取到期才會在各地陸續換成新值。
提醒一句：不同服務商對這幾欄的叫法不完全一樣——「主機」有的寫作「Name」或「Host」，根網域有時是「@」有時乾脆留空，「值」也可能叫「Value」「Content」或「TXT Value」。名字不同，填的東西是一回事。
Google／Microsoft 要我加的那條 TXT 記錄，到底是什麼
最常見、也最貼近這個問題的例子，是用 Google Search Console（Google 站長工具）做網域驗證。當你在裡面加入一個「網域」資源時，Google 會發給你一段類似 google-site-verification=AbC123… 的值，讓你把它發佈到網域根部的 TXT 記錄裡。隨後 Google 會去查你這個網域的 DNS，一旦讀到這段值，就確認你確實掌控這個網域——驗證通過。這和「對方寄給你一張專屬回執，你把它貼到自家門口的公告欄上，他再過來看一眼確認是你」是一個意思。Microsoft 365 以及很多其他服務，用的也是同一套 TXT 驗證套路。
這樣做安全嗎？會洩露什麼嗎？
這一點最該說清楚，也最能打消顧慮：那段驗證值只是一串公開的文字，把它發佈出去既不會給任何人開門，也不會洩露任何敏感資料。具體來說：
- TXT 記錄本來就是設計成公開可查的——任何人都能查到任意網域的 TXT 記錄，這是正常的運作方式，不是漏洞。
- 那段驗證字串對外人沒有任何意義，也不包含你公司的任何機密資料；讀到它的人，並不能因此登入你的電郵、網站或後台。它只能證明「網域歸你」，不能用來存取任何東西。
- 真正的安全關口，在於誰能修改你的 DNS（也就是誰握有網域管理後台的帳號），而不在於這段公告別人能不能看到。
所以，按 Google／Microsoft 的指示加一條驗證用的 TXT 記錄，本身是安全的常規操作。需要謹慎的不是「加這條記錄」，而是那封要你加記錄的電郵是不是真的來自官方——而這，正好是 TXT 記錄的另一個用途要解決的問題。
在 GoDaddy 上大致是怎麼加的
各家網域後台的介面略有差異，以常見的 GoDaddy 為例，加一條驗證用的 TXT 記錄大致是這樣：進入網域的 DNS 管理頁，點「新增記錄」（Add record），「類型」選 TXT，「名稱」（Name）填「@」，「值」（Value）貼上對方給你的那串字元，儲存即可。整個過程不改動別的記錄，也不影響網站和電郵的正常運作。
另一個大用途：電郵安全規則就住在 TXT 記錄裡
除了網域驗證，TXT 記錄還是三套電郵安全規則的存放地。這三套規則合起來，相當於給你公司寄出去的電郵蓋上一個「防偽公證章」——讓收件方的郵件系統能核實「這封信確實從你公司網域寄出，不是騙子冒名頂替」。它們不是獨立的新欄目，而是以特定格式寫進 TXT 記錄裡的文字：
- SPF：在 TXT 記錄裡列出「哪些伺服器有資格用我的網域寄信」，相當於一份授權名單。它怎麼寫、怎麼影響投遞，我們在 SPF 的文章裡講得更細。
- DKIM：給每封電郵附上一個加密簽章，收件方用同樣寫在 TXT 記錄裡的公鑰來核對，確認郵件中途沒被竄改、確實來自你的網域。這一套的來龍去脈，可以讀我們關於 DKIM 的文章。
- DMARC：在 TXT 記錄裡設定一條策略，告訴收件方「如果有人冒用我的網域寄信、又沒通過上面兩道檢查，該怎麼處理」。想了解怎麼定這條策略，可以看我們關於 DMARC 的文章。
這三者配合，能明顯降低別人冒用你公司網域寄垃圾郵件、釣魚郵件的機率，也影響你正常寄出的郵件能不能順利進對方收件匣。它們都不在郵件軟體裡設定，而是寫在網域的 TXT 記錄裡——這也是為什麼「設定電郵安全」聽起來和電郵有關，做起來卻要動 DNS。
一個容易踩空的細節
還有一點常讓人白忙一場：一條 TXT 記錄，只有寫在你的「名稱伺服器」（Name Server）實際指向的那家 DNS 服務商那裡，才會真正生效。很多網域雖然在某家註冊商名下買的，DNS 卻交給了另一家（比如 Cloudflare）託管。這時你若在註冊商後台改 TXT，記錄看似加上了，外界卻查不到、驗證也一直不通過。換句話說，要改對地方，先得弄清楚這個網域的記錄到底歸誰管——這也是交給熟悉你網域設定的人來做更省心的原因之一。
所以你該怎麼應對
你不需要自己研究怎麼把一段字串填進 DNS。對非技術的企業老闆來說，最穩妥的做法很簡單：當 Google、Microsoft 或任何服務商要求你「加一條 TXT 記錄來驗證網域」時，把那封電郵原樣轉發給負責你網站和網域的技術服務方去處理。如果不確定那封電郵是不是真的來自官方，更應該先找人核實，而不是照著陌生電郵裡的連結動手——畢竟冒名頂替正是電郵安全要防的事。
5U Website 怎麼幫客戶處理
網域驗證和電郵安全這類設定，屬於「設好了沒人注意、設錯了郵件就大面積進垃圾匣甚至寄不出去」的事。在過去近二十年的網站與託管工作裡，我們替客戶處理過大量企業電郵接入（Google Workspace、Microsoft 365）和 SPF／DKIM／DMARC 設定。我們的做法是：動 TXT 記錄前先確認要求來源是否可信、看清該網域的 DNS 到底由誰託管，再按服務商規範填寫並複核。
把這件事交給我們
不必為一條看不懂的 TXT 記錄費神——這正是我們的日常工作。5U Website 的網頁設計、網站製作及託管服務裡，就包含網域驗證與電郵安全（SPF／DKIM／DMARC）的設定與維護。如果你收到要求加 TXT 記錄的通知，或者企業電郵出現「寄不出、收不到、總進垃圾匣」的情況，給我們寫一封電郵，我們通常會在一到兩個工作日內回覆。
最早發佈於：，最近一次編輯時間：
