許多站長在架設或搬遷網站時，往往被網域名稱系統（DNS）設定卡住——確實曾經改過 A 紀錄，但網站還是沒上線；或者郵件怎麼設都收不到。這些問題通常不是方向錯誤，而是對 DNS 紀錄的用途、優先序與傳播機制理解不足。本文逐一拆解四類核心紀錄的設定邏輯，以及如何用查詢工具追蹤傳播進度、快速診斷常見失敗。
A 紀錄指向網站伺服器
A 紀錄是最基礎的 DNS 紀錄，用來指向你的網站伺服器 IP 位址。當訪客在瀏覽器輸入網域（例如 example.com），系統會解析這個 A 紀錄，進而找到存放網站檔案的主機。
在主機商或網域註冊商的後台，通常會看到一個設定欄位要填 IP 位址。假設你的主機 IP 是 203.0.113.42，就把它填進 A 紀錄。設定完成後，並不會馬上生效——全球傳播需要 1 至 48 小時（取決於 TTL 設定），期間不同地區的訪客可能連到新站也可能還連到舊站。為了加快切換速度，站長在正式改 A 紀錄之前通常會預先調低 TTL 值（例如改成 300 秒），讓傳播時間壓縮到幾分鐘，之後再改回較高的 TTL 減少查詢次數。
CNAME 的別名轉向與限制
CNAME（Canonical Name）的功能是讓多個網域或子域指向同一個目標。最常見的用途是設定 www 子域——大多數主機商會自動幫你建立 CNAME，指向主域 example.com。這樣訪客無論輸入 www.example.com 或 example.com，最後都會連到同一個位址。
但 CNAME 有一個重要限制：不能用在根域（root domain）。也就是說，example.com 只能用 A 紀錄，不能用 CNAME 指向別的地方。如果硬要在根域用 CNAME，會導致郵件服務、SSL 憑證驗證等依賴根域的功能全部失效。這是站長最常踩的坑——看到有些 CDN 服務或託管方案建議用 CNAME 加快部署，就直接套用到根域上，結果 Email 收不到、轉向斷掉。
另一個 CNAME 的限制是一層只能一個。如果你已經設了 www.example.com 指向 example.com.cdn.example（用 CNAME），就不能再在 mail.example.com 上掛 CNAME——每層只能選一種指向方式。
MX 紀錄配置郵件收發
想要用自家網域接收郵件（例如 hello@example.com），需要設定 MX 紀錄（Mail Exchange）。MX 紀錄告訴全球郵件伺服器，寄給你這個網域的信要送到哪台郵件伺服器。
MX 紀錄的設定與 A 紀錄不同，它不是填 IP 位址，而是填一個郵件伺服器域名。例如用 Google Workspace 提供的郵件服務，Google 會告訴你設定成「mail.google.com」或「aspmx.l.google.com」之類的，再搭配一個優先級數字（Priority）。優先級數字越低優先度越高，最常見的設定是用 10、20、30 等 10 的倍數，好讓主郵件伺服器故障時自動遞補到次要伺服器。
不設 MX 紀錄的網域無法收信，即使郵件客戶端登入成功也只能寄不能收；只設一個 MX 紀錄的網域則沒有冗餘，如果那台郵件伺服器當掉就會掉信。所以稍具規模的郵件系統至少要設 2 至 3 個優先級不同的 MX 紀錄做備援。
TTL 控制傳播速度
TTL（Time To Live）是個時間值（以秒為單位），控制 DNS 紀錄在各地伺服器上的快取時間。TTL 越高，快取保留時間越長，全球傳播時間越長（但減少查詢次數、降低延遲）；TTL 越低，快取失效越快，改動會很快生效，但查詢次數會增加。
典型情況下，一個網域的 TTL 預設值往往是 3600 秒（1 小時）甚至 86400 秒（24 小時）。如果你改了 A 紀錄且設定的 TTL 是 86400，那全世界有些伺服器會繼續用舊 IP 直到 24 小時過去。為了規避這個問題，職業站長在大搬家前會提前 48 至 72 小時登入網域註冊商，把 A 紀錄和 CNAME 的 TTL 預先改成 300 秒（5 分鐘），有的甚至壓到 60 秒。真正切換時，新 IP 就能在幾分鐘內傳遍全球，避免搬家期間訪客同時連到新舊兩台主機。
修改完 TTL 後，不需要馬上改 IP——只是等它生效。等待 1 至 2 小時後，再登入網域註冊商改 A 紀錄指向新主機 IP，這樣傳播延遲會非常短。
用工具驗證設定狀況
DNS 設定完成後，要確認全球各地的解析是否已經同步，可以用免費的傳播檢查工具。常用的有 DNSChecker.org 和 ReviewMyDNS.com，兩者都能檢查全球 50 個以上的伺服器，看你的 A 紀錄、CNAME、MX 紀錄是否已經更新。
檢查流程很簡單：在工具的輸入框填入你的網域名稱，工具會自動查詢目前全球各地的伺服器回傳什麼 IP 位址。如果大部分伺服器都指向新 IP，但仍有少數指向舊 IP（通常是某些 ISP 的伺服器），就代表傳播仍在進行，再等幾小時就會全部同步。
這類工具也能驗證 MX 設定——選擇檢查 MX 紀錄，就能看到全球郵件伺服器是否都已經知道該用哪台伺服器接收你的郵件。
診斷常見設定錯誤
網站不上線最常見的原因有三種。其一是主機商與網域註冊商的命名伺服器（Nameserver）不匹配。例如你買網域的是 GoDaddy，但選擇的主機商是 Bluehost，兩邊的後台要指向同一組 Nameserver 才能生效。假如 GoDaddy 的 Nameserver 指向 Bluehost 的名稱伺服器，但你在 Bluehost 後台改的設定卻放在另一個虛擬主機商的帳戶，兩邊會對不上，網域就會無法解析。正確做法是從網域註冊商確認目前用的 Nameserver，再登入該 Nameserver 對應的後台（通常就是你的主機商）去做設定。
其二是 A 紀錄或 CNAME 填成了 URL 或域名，而非 IP 位址或純域名。A 紀錄一定要填 IP 位址（例如 203.0.113.42），不能填網址（不要填 http://example.com）；CNAME 要填純域名（例如 cdn.example.com），不能帶 http:// 或路徑。
其三是傳播還在進行，但站長沒有耐心等待。改完設定後立刻試著訪問網站，很可能因為本機快取還保留著舊 IP，所以仍然看到舊內容。遇到這種情況，可以打開命令列用 nslookup 或 dig 指令查詢目前伺服器回傳的 IP，或者乾脆清除瀏覽器與作業系統的快取，再重新存取。
郵件收不到通常是 MX 紀錄或 SPF／DKIM 紀錄設定錯誤。如果已經確認 MX 紀錄正確（用檢查工具驗證過），但郵件還是寄不進來，那八成是缺少 SPF（Sender Policy Framework）或 DKIM（DomainKeys Identified Mail）。這兩項紀錄告訴郵件伺服器「寄件人確實是用這個網域授權過的伺服器」，主要用來防止詐騙信。若不設這兩項，信件容易被當成垃圾郵件。不過 SPF 和 DKIM 的設定相對複雜，涉及公鑰與加密驗證，通常郵件服務商（例如 Google Workspace、Office 365）會在後台文件裡告訴你怎麼設，照著做就行。
設定邏輯其實很簡單：用 A 紀錄指向網站、用 CNAME 別名轉向、用 MX 紀錄指向郵件伺服器，再搭配 TTL 控制傳播速度。常見失敗多半是命名伺服器對不上、欄位填錯格式，或者沒有預留足夠的時間讓傳播完成。下次遇到網站不上線或郵件無法運作的狀況，先用檢查工具確認一下目前的解析狀態，通常就能快速定位問題所在。