DNS 記錄設定教學：A、CNAME、MX、TXT 怎麼設

DNS 記錄決定你的網域怎麼被使用：A 與 AAAA 記錄把網址指到主機的 IP 位址，CNAME 讓一個名稱跟著另一個名稱走，MX 決定公司信件送到哪台郵件伺服器，TXT 放網域驗證等文字資料，NS 指定由哪裡回答這些查詢，TTL 則決定各地快取多久才會換成新設定。動任何一筆之前，先把整份記錄表備份下來；許多「網站打不開、信收不到」的狀況，都是改了一筆、漏了另一筆。

以下是幾種常見情況的示意，不是真實客戶案例，用來幫你找到該先讀的段落與第一個動作。

• 室內設計工作室要改用雲端信箱：一間五、六人的設計工作室，老闆決定把主機附的信箱換成 Google Workspace，設定精靈要求新增 MX 與 TXT 記錄。他最擔心改到一半，業主寄來的圖面確認信新舊兩邊都收不到。先讀「MX 記錄」一段，弄清楚帳號何時建、舊的 MX 何時處理；動手前照「修改前先備份記錄表」把現有設定存下來。
• 烘焙坊的行銷人員接手新官網上線：一家有三間門市的烘焙坊，外包廠商把新官網架在另一個平台，只給了一個主機名稱，要她「設 CNAME」。她照做後，加上 www 的網址可以開，不加 www 的卻打不開，DNS 後台也不讓她在根網域新增 CNAME。她擔心開幕檔期的廣告連結失效。先讀「CNAME 記錄」一段，了解根網域為什麼不能設、有哪些替代做法。
• 會計師事務所的行政要驗證網站：一間十來人的會計師事務所，行政要把官網加進 Google Search Console 查看搜尋成效，貼上 TXT 記錄後按驗證，連續失敗好幾次。她擔心是不是把網站改壞了。先讀「TXT 記錄」一段核對名稱欄位與貼上的值，再看「TTL」一段，了解為什麼新增後不該馬上按驗證。

A 記錄存的是一個 32 位元的 IPv4 位址，AAAA 記錄存的是 128 位元的 IPv6 位址。訪客輸入網址時，瀏覽器就是靠這兩種記錄找到網站主機。換主機時，主機商給你的新 IP，就是要填進 A 記錄的值。

DNS 後台的每一筆記錄大致有四個欄位：名稱（有的介面叫主機名稱或 Host）、類型、值（或叫目標、指向）與 TTL。以網域 example.com 為例：

表中的網域與 IP 都是標準文件保留給範例用的，請換成你自己的。「@」沿用 DNS 區域檔的寫法，代表網域本身，也就是根網域。

• 根網域與 www 是兩個名稱：只設了 @，www 就查不到；只設了 www，不加 www 的網址就打不開。兩者都要有記錄，www 也可以改用下一段的 CNAME。
• 名稱欄位填了完整網域：區域檔裡沒有以句點結尾的名稱，會自動接上網域本身。名稱欄填「www.example.com」，有些介面就會存成 www.example.com.example.com。先看介面範例怎麼寫，存檔後用查詢工具確認實際名稱。
• 舊 IP 沒刪：同一個名稱留著新舊兩筆 A 記錄，查詢會兩個位址都拿到，訪客可能連到任何一台，結果網站時好時壞、表單資料分散兩邊。
• 留著用不到的 AAAA：新主機沒有提供 IPv6，舊的 AAAA 卻還在，透過 IPv6 連線的訪客就會被帶到錯的地方，出現「只有某些網路打不開」的怪現象。新主機沒有 IPv6 位址，就把 AAAA 一併刪除。

CNAME 記錄把一個名稱設成另一個名稱的別名，查詢時會轉去查目標名稱的記錄。好處是不必自己記 IP：網站放在平台或雲端服務上，對方給你一個主機名稱，你在 www 設 CNAME 指過去，之後對方更換 IP，你不用跟著改。Microsoft 365 開通時要求的 autodiscover 記錄，也是一筆 CNAME。

範例：名稱 www、類型 CNAME、值 sites.example.net。值只能填網域名稱，不能填 IP，也不能填帶 https:// 或路徑的網址。

CNAME 有一條硬規則：DNS 規範（RFC 1034、RFC 2181）規定，一個名稱只要有 CNAME，就不能再有其他記錄。根網域一定帶著 SOA 與 NS 這兩種管理用的記錄，所以根網域不能設 CNAME。同樣的道理，在 www 設了 CNAME，又想在 www 放 TXT 驗證碼或 MX，也會衝突。有些後台會直接擋下，有些允許存檔，但查詢結果無法預期。

根網域需要跟著平台走時，常見的做法有三種：

1. 根網域用 A 記錄，填平台公布的固定 IP；www 用 CNAME。
2. 使用 DNS 代管商提供的變通功能，例如 Cloudflare 的 CNAME 攤平（CNAME flattening），或其他代管商稱為 ALIAS、ANAME 的記錄。代管商先查出最終的 IP，再以位址記錄回答，因此不違反規範。這類功能不是 DNS 標準，各家名稱與行為不同；Cloudflare 也提醒，第三方服務若靠讀取 CNAME 本身來驗證網域，攤平後可能驗證不過。
3. 以 www 為正式網址，根網域的 A 記錄指到一台會做轉址的主機，由它把訪客轉到 www。

MX 記錄告訴寄件端：寄到 @example.com 的信要送到哪台郵件伺服器。每筆 MX 有兩個值，一個是優先順序數字，一個是郵件伺服器的主機名稱。

依郵件傳輸標準 RFC 5321，數字越小越優先。寄件端先試 10，連不上才試 20；兩筆數字相同時，寄件端必須隨機挑選，用來分散負載。所以數字大的那筆是備援，不是分流。

• 值要填主機名稱，不能填 IP：MX 的目標必須是查得到 A 或 AAAA 記錄的名稱，而且 RFC 2181 規定不得是 CNAME 別名。郵件服務給的值照抄，結尾的句點依後台要求保留或省略。
• 換信箱服務時要處理舊 MX：Google Workspace 的設定說明要求移除其他 MX 記錄，否則信件可能無法正常運作；Microsoft 365 則說明，可以刪掉舊服務的 MX，或把舊 MX 的優先順序設得比新的低，也就是數字更大。Microsoft 也提醒，先在新服務把所有使用者與信箱建好再改 MX；改了之後新信送到新服務，舊信仍留在原本的主機。
• 生效需要時間：Google 說明新的 MX 最多可能要 72 小時才會被辨識。這段期間新舊兩邊都可能收到信，舊信箱先不要停用。
• 刪掉 MX 不等於停止收信：RFC 5321 規定，網域查不到 MX 時，寄件端會把網域本身的 A 或 AAAA 位址當成郵件伺服器嘗試投遞。確定不收信的網域，例如只用來轉址的備用網域，可以依 RFC 7505 設定「Null MX」：只放一筆優先順序 0、值為單一句點「.」的 MX，寄件端會立即退信，不會白白重試好幾天。會用來寄信的網域不要這樣設。

TXT 記錄存的是一段文字，DNS 本身不解讀內容，由讀取它的服務自行判斷。最常見的用途是證明「這個網域是我的」：開通 Google Workspace、Microsoft 365，或把網站加進 Google Search Console 時，服務會給你一串驗證碼，你把它放進 TXT 記錄，服務查得到，就確認你有網域的管理權。Google 說明多數網站以 TXT 記錄完成網域驗證。寄件驗證用的 SPF 也是一筆 TXT 記錄，設定原則與常見錯誤請見公司信件被歸垃圾信的檢查步驟。

同一個名稱可以有多筆 TXT，用途不同的驗證碼彼此不衝突，所以加新的驗證碼時是「新增一筆」，不要覆蓋原有那筆。貼上前核對三件事：

1. 名稱欄位：服務要求放在網域本身的，依介面說明填 @ 或留空；要求放在特定名稱的，例如以底線開頭的子名稱，只抄名稱部分，不要再多接一次網域。
2. 值要完整：從服務頁面直接複製，前後不要多出空白；介面會自動加引號的，就不要自己再包一層。依 RFC 1035，單一段文字最長 255 個字元，更長的值要拆成多段；有的後台會自動拆，手動拆分時照該服務的說明。
3. 新增後不要馬上判定失敗：Google Search Console 說明，手動新增的記錄可能要兩、三天，DNS 服務商才開始提供；驗證失敗就隔一兩天再試。

驗證成功後也不要刪掉這筆 TXT。Google 說明要維持驗證狀態就得保留記錄，查不到時會收到通知，問題沒解決，寬限期過後權限就會失效。記錄表裡每一筆 TXT 都要註明屬於哪個服務、由誰新增；看不懂的 TXT，不要因為「看起來沒用」就清掉。

NS 記錄指定哪幾台名稱伺服器對這個網域具有權威，外界要查你網域的任何記錄，都去問這幾台。實務上它決定一件事：你該去哪個後台改記錄。網域註冊商後台、主機控制台、CDN 服務都可能有 DNS 設定畫面，但只有目前 NS 指向的那一家改了才算數，在別處改得再正確，外界也看不到。

確認方法：在 Windows 命令提示字元輸入 nslookup -type=NS example.com，看回傳的名稱伺服器屬於哪一家，就到那一家的後台操作。名稱伺服器本身要換成哪一組，則是在網域註冊商那裡修改。

• 至少兩台：RFC 1034 要求每個區域至少由兩台伺服器提供服務，一台故障時另一台還能回答。代管商給了幾組名稱伺服器就全部照填，不要只填第一組。
• 註冊商登記的清單要和代管商一致：RFC 1912 建議，上層登記的 NS 要與你區域內的 NS 相同。被列為名稱伺服器、實際上卻沒有這個網域資料的情形稱為失效委派（lame delegation），會讓部分查詢失敗；停用舊代管商前，先確認註冊商那邊已經不再列出它。
• 改 NS 等於整份記錄表搬家：改 NS 之前，新代管商那邊要先把 A、CNAME、MX、TXT 全部建好。最常見的事故是只建了網站的 A 記錄，MX 與驗證用的 TXT 被漏掉，結果網站正常，信卻收不到，網站驗證也跟著失效。

TTL 以秒為單位，是各地 DNS 伺服器可以把這筆記錄留在快取裡的最長時間：3600 代表 1 小時，86400 代表 1 天，設為 0 表示不應快取。RFC 2181 規定 TTL 的範圍是 0 到 2147483647 秒，而且同名、同類型的一組記錄，TTL 必須相同。

這也是「我這邊已經改好、客戶那邊還是舊的」的原因：對方使用的 DNS 伺服器在 TTL 到期前，會繼續用快取裡的舊答案。想讓切換時間短一點，可以這樣安排：

1. 在預定修改日前，先把要改的記錄 TTL 調低，例如 300 秒。
2. 等待至少「原本的 TTL」那麼久，讓各地快取裡帶著舊 TTL 的資料過期。原本設 1 天，就要提前 1 天以上調低。
3. 修改記錄的值，確認新設定正常。
4. 穩定後把 TTL 調回原值，減少查詢次數。

有兩個例外要知道。第一，「查不到」也會被快取：RFC 2308 規定，名稱不存在或沒有該類型記錄的否定答案，也會依網域 SOA 記錄的設定被快取一段時間。服務叫你新增記錄時，先建好再按驗證，不要先按一次確認「還查不到」。第二，服務商可能限制 TTL：Microsoft 說明 Exchange Online 只支援低於 6 小時（21,600 秒）的 TTL，照服務文件建議的值填寫即可。

TTL 沒有放諸四海皆準的數字。調低能讓下次修改較快生效，代價是查詢量增加；常改的記錄可以短一點，長期不動的可以長一點。

1. 匯出或抄下整份記錄表：後台有「匯出區域檔」就匯出；沒有就逐頁截圖，再整理成一張表，欄位包含名稱、類型、值、優先順序與 TTL。截圖只是佐證，真要還原時，能複製貼上的文字比圖片可靠。
2. 每一筆註明用途與負責對象：例如「@ A：官網主機」「@ MX：企業信箱」「@ TXT：Search Console 驗證」。答不出用途的記錄先標問號，查清楚之前不刪。
3. 確認要改的後台是對的：照 NS 一段的方法，確定目前由哪一家回答，再登入那一家修改。
4. 一次只改一件事並記下時間：網站和信箱都要搬，也分成兩次改；出問題時才知道是哪一筆造成的。
5. 提前調低 TTL：依上一段的順序，在修改日前先調低。
6. 改完從外部查實際結果：用 nslookup 或 Google 管理工具箱的 Dig 查詢，比對名稱有沒有多接網域、值有沒有少一個字，也請在不同網路的同事實際開網站、寄信。
7. 逐項測試並保留舊值：根網域與 www 各開一次，從外部信箱寄信進來、再回覆一封出去，最後到各服務後台確認驗證狀態。舊值留到確認穩定後再刪，需要時能照備份改回去。

這份記錄表本身就是公司資產。換廠商、換行政人員時一起交接，下一次有人要動 DNS，就不必從頭猜每一筆是做什麼用的。

DNS 問題多半不難修，難的是弄清楚現況。聯絡前請盡量備妥：

1. 網域名稱、網域註冊商名稱，以及誰握有註冊商後台帳號，至少要有修改 DNS 的權限。
2. 目前 NS 的查詢結果，也就是 DNS 實際由哪一家回答。
3. 整份 DNS 記錄表的匯出檔或截圖，包含每一筆的 TTL。
4. 這次要做的事：換主機、換信箱、新增驗證，或某個服務要求新增哪些記錄，附上該服務提供的設定畫面。
5. 網站主機、企業信箱與其他用到網域的服務，各在哪一家、由誰管理。
6. 預計切換的日期，以及哪些時段不能中斷，例如月底對帳、展覽或檔期前，方便倒推 TTL 何時調低。
7. 若已經出問題：開始的時間、改過哪幾筆、錯誤畫面或退信全文。

要先說明的是範圍：DNS 實際由誰回答，就要在誰的後台修改。NS 指向其他廠商時，可以由握有該後台權限的人照我們整理的清單操作，也可以評估把 DNS 改由我們代管；網域續約與名稱伺服器的變更，仍要經過網域註冊商。

凱斯騰可以透過網域註冊與 DNS 代管整理並維護你的記錄表；網站放在虛擬主機、信箱改用企業郵件時，協助設定對應的 A、MX 與 TXT；網站與信箱要一起換環境，則由網站與郵件移轉安排切換順序。資料備妥後，請填寫聯絡表單，或來信 [email protected] 說明需求。

• DNS 是什麼：網域、主機、信箱怎麼串在一起
• 換主機後網站或信箱異常：DNS 生效時間與排查順序
• 公司信件被歸垃圾信：先查驗證、再請客戶協助
• 網域註冊：以公司名義登記網域，並提供 DNS 代管
• 網站與郵件移轉：換主機、換信箱時規劃 DNS 切換順序
• 企業郵件：用公司網域收發信，MX 與驗證記錄一次設好
• 網域到期沒續約：停止解析、贖回期與被搶註的處理