網域轉移教學 2026｜授權碼、DNS、Email 與停機風險一次看

網域轉移教學 2026｜授權碼、DNS、Email 與停機風險一次看

內容目錄 顯示
加入為 Google 偏好來源

網域轉移通常是把同一個網域名稱從目前的受理註冊機構轉到另一家管理。它不等於更換網域名稱，也不代表網站檔案、資料庫、DNS 或企業信箱會自動搬到新服務商。

例如 example.com 從 A 註冊商轉到 B 註冊商，轉移前後仍是 example.com。如果 nameserver 與 DNS zone 維持不變，網站及 Email 可能不需要更改解析；如果同時更換 DNS 代管或 nameserver，就要另外複製 A、AAAA、CNAME、MX、SPF、DKIM、DMARC 及驗證紀錄。

主要依據：ICANN Transfer Policy、ICANN 網域轉移 FAQ與TWNIC 網域名稱註冊管理業務規章（查證 2026-07-24）。ICANN 與 TWNIC 管理範圍不同，本文不把 gTLD 規則直接套用到 `.tw`。

網域轉移是什麼？與換網域、改 DNS、搬網站有何不同？

網域轉移至少有兩種常被混用的意思：

  1. 受理註冊機構轉移：網域名稱不變，把註冊管理服務從目前 registrar 轉到新的 registrar。
  2. 註冊人變更：把網域的權利人或聯絡資料從目前 registrant 變更為另一個人或組織。

轉移註冊商不會把 old.com 變成 new.com

網域名稱本身無法透過「轉移」改字。想把品牌從 old.com 改成 new.com，需要另外註冊或取得 new.com，建立網站及 Email，設定舊 URL 到新 URL 的永久轉址，再處理 Search Console、內鏈及其他品牌資產。

轉移註冊商不等於更換 DNS 代管

Registrar 管理網域註冊資料、續用及轉移；DNS host 管理 nameserver 與 zone 中的解析紀錄。兩個角色可以是同一家，也可以分開。

  • 網域註冊在 A。
  • nameserver 指向 Cloudflare 或另一家 DNS 服務。
  • 網站在主機商 C。
  • Email 使用 Google Workspace、Microsoft 365 或台灣郵件服務。

轉移註冊商不等於網站搬家

網站檔案及資料庫放在 hosting provider，不會因 registrar 轉移自動複製。只轉 registrar 時，網站主機 IP、程式及資料通常不需要改動。

轉移註冊商不等於企業信箱搬家

企業信箱透過 DNS 的 MX 紀錄接收郵件，並使用 SPF、DKIM、DMARC 等紀錄驗證寄件來源。Registrar 轉移本身不會把信箱帳號與歷史郵件移到新系統。

  • MX。
  • SPF TXT。
  • DKIM TXT 或 CNAME。
  • DMARC TXT。
  • autodiscover、mail 或其他用戶端紀錄。
  • 郵件供應商的網域驗證紀錄。

Registry、Registrar、Registrant、DNS host 與網站主機差在哪裡？

網域轉移能否安全完成，取決於團隊是否知道每一層由誰管理。最實用的做法不是背名詞，而是為每層填上公司、帳號、權限及驗收證據。

角色中文概念主要責任轉移時要確認
Registry註冊管理機構維護頂級網域資料庫及規則TLD 由誰管理，適用哪套政策
Registrar受理註冊機構／註冊商受理註冊、續用、解鎖及轉移目前與目標 registrar、轉移資格及費用
Registrant註冊人持有及負責網域註冊權益與資料名稱、組織、Email 是否正確及可存取
DNS hostDNS 代管服務回應 nameserver 及管理 zone recordsnameserver、zone、DNSSEC 及帳號
Hosting provider網站主機商執行網站並提供檔案與資料庫網站是否留在原主機，IP 是否改變

Registry 制定特定 TLD 的技術與政策框架

Registry 維護某個頂級網域的註冊資料及系統。例如 TWNIC 管理 .tw、.台灣 與 .台湾；不同 gTLD 則有各自 Registry operator，並透過 ICANN 認可的 registrar 提供服務。

Registrar 是你日常付款及管理網域的窗口

Registrar 後台通常提供：

  • 網域註冊及續用。
  • 聯絡資料管理。
  • transfer lock。
  • AuthInfo／EPP code。
  • nameserver 設定。
  • DNS 服務或加值功能。
  • 自動續約及付款。
  • 轉入與轉出申請。

Registrant 才是網域控制權的核心

公司付錢不代表公司一定是登記註冊人。如果網域長期登記在員工、代理商或前廠商名下，轉移時可能需要對方登入，提供授權碼或確認 Email。

  • registrant 名稱及組織。
  • registrant Email 是否能收信。
  • administrative contact 或替代聯絡資料。
  • 公司是否有 registrar 帳號及復原能力。
  • MFA 裝置是否仍由在職人員持有。
  • 付款及續約通知寄到誰。

DNS host 決定網站及 Email 去哪裡

查看 nameserver 可以知道目前由誰對外回答 DNS。Registrar 後台可能顯示 DNS 編輯器，但如果 nameserver 指向另一家，真正生效的 zone 不在 registrar。

  • Registrar of record。
  • Registry status，例如 clientTransferProhibited。
  • 建立、更新及到期資訊。
  • nameserver。
  • DNSSEC delegation。
  • 公開可查的聯絡或狀態資訊。

gTLD、.tw 與其他 TLD 的轉移規則差在哪裡？

網域轉移最危險的簡化句是「網域都要解鎖，並取得 EPP code，等五到七天」。這只描述部分常見情況，不能跨所有 TLD 使用。

比較ICANN Transfer Policy 範圍內的 gTLD.tw、.台灣 與 .台湾其他 ccTLD／特殊 TLD
主要政策來源ICANN Transfer Policy、Registry 與 registrar 規則TWNIC 規章、公告及受理註冊機構流程對應 Registry 與 registrar 規則
常見授權方式AuthInfo／Auth-Code＋轉移確認依 TWNIC 及來源／目的受理註冊機構要求可能是 code、帳號確認或文件
常見鎖定初次註冊、前次轉移及 registrant change 可能涉及 60 天規則不應直接套用 ICANN gTLD 的 60 天結論各 TLD 不同
身分資料registrant 及聯絡資料要正確TWNIC 規章允許要求足以證明身分的文件及資料依 Registry 或當地規則
轉入費及續期依 registrar、TLD 及方案依受理註冊機構及 .tw 規則各自確認
固定完成天數不宜承諾，取決於狀態、確認及雙方處理不宜承諾，依實際流程不宜承諾

gTLD 常見的 60 天限制不是單一規則

ICANN 文件列出多個會影響 registrar transfer 的情況：

  • 網域建立後的前 60 天。
  • 前一次 registrar transfer 後的 60 天。
  • Change of Registrant 後，若適用並已設置 60 天 inter-registrar transfer lock。
  • 網域處於 transfer lock。
  • 涉及特定爭議程序、法院命令或政策要求。

transfer lock 與 AuthInfo 是兩個不同控制

常見 EPP status clientTransferProhibited 表示 client 端禁止 transfer。註冊人通常要在 registrar 後台解鎖，或向客服提出要求。

  1. Registry status 已允許 transfer。
  2. AuthInfo 是目前有效值。
  3. registrant 或指定聯絡 Email 可收取確認。
  4. 網域未落入不可轉的政策或爭議狀態。
  5. 目標 registrar 支援該 TLD。

AuthInfo 不能貼在工單、群組或文章中

AuthInfo 能協助發起網域轉移，應視為敏感憑證。安全做法包括：

  • 只在來源 registrar 的正式後台產生或取得。
  • 使用密碼管理工具或目標 registrar 的安全表單傳遞。
  • 不貼在 Email 主旨、一般聊天群組或專案文件。
  • 不把真實 code 放入截圖及教學。
  • 轉移完成後依 registrar 能力輪替或確認舊 code 不再有效。
  • 若懷疑外洩，立即重新產生 code 並恢復 lock。

.tw 要依 TWNIC 與受理註冊機構流程

TWNIC 的網域名稱註冊管理業務規章說明，.tw、.台灣 與 .台湾 的申請、續用、移轉及取消屬於其註冊服務範圍。客戶移轉或取消時，應依要求提供足以證明身分的文件及相關資料。

  • .tw 類型及註冊資格。
  • 目前與目標受理註冊機構是否支援該服務。
  • 線上授權、申請書或身分文件要求。
  • 網域目前狀態及到期情況。
  • 轉入費、續用年限及付款規則。
  • registrant 資料是否一致。

哪些情況適合轉移？哪些時機應先不要動？

Registrar transfer 的合理目的，是把控制權、續約及安全管理移到更適合的服務。若只是想換網站主機或修正 DNS，不一定要轉移 registrar。

適合評估轉移的情況

  • 公司要把散落在多家 registrar 的網域集中管理。
  • 目前帳號缺乏 MFA、子帳號或合理的權限分工。
  • 現有 registrar 支援、帳務或安全通知無法滿足需求。
  • 續約幣別、付款方式或總成本長期不合適。
  • 前廠商代管即將結束，需要把網域收回公司帳號。
  • 企業併購或治理要求統一網域 owner 與流程。
  • 目標 registrar 支援所需 TLD、DNSSEC 或其他必要功能。

轉移前要比較三年成本，不只比較首年。計算可以拆成：

  • 第一年：轉入費＋可能包含的續期＋稅額／匯率＋代辦費
  • 第二年：標準續約費＋隱私或安全加值＋稅額／匯率
  • 第三年：標準續約費＋持續加值＋稅額／匯率
  • 三年總成本：第一年＋第二年＋第三年

網域快到期時，不要只憑「轉入會送一年」判斷

到期前才開始轉移，可能遇到 code、lock、付款、核准或 registrar 支援問題。不同 TLD 對到期後轉移及續期的處理不同，轉入費是否包含延長年限也不是通則。

  1. 查看 TLD、Registry 及雙方 registrar 的正式規則。
  2. 確認目前網域沒有欠費及特殊狀態。
  3. 留出足夠緩衝，不在最後幾天開始。
  4. 若時程不確定，先向目前 registrar 續用，再確認續用後轉移對年限及費用的影響。
  5. 保存付款、續用及 transfer 的正式通知。

剛註冊，剛轉移或剛改 registrant 時先查 lock

對 ICANN policy 範圍內的 gTLD，初次註冊後 60 天、前次 transfer 後 60 天，以及適用的 Change of Registrant lock 都可能影響轉移。

  • 哪一個動作會構成 Change of Registrant。
  • 是否提供符合規則的 opt-out。
  • 正確操作順序。
  • 需要哪些確認與文件。
  • 執行後會顯示什麼 EPP status。

重大活動、付款檔期與改版窗口前不要冒險

Registrar transfer 理論上可以在 DNS 不變的情況下進行，但實務上仍有帳號、nameserver、DNSSEC、續期及支援風險。

  • 廣告活動或新品上線前。
  • 電商大促、募款、售票或結帳高峰。
  • 網站搬家、換網域或重大改版同一週。
  • 企業信箱供應商切換期間。
  • 網域距離到期太近。
  • 主要管理員或 registrar 客服無法即時回應的假期。

網域轉移前要準備哪些權限、DNS 與 Email 資料？

轉移前的目標是建立一份「即使 registrar 後台暫時無法登入，仍能知道網站及 Email 應如何運作」的基準。不要等轉移完成後才從記憶重建 DNS。

確認 registrant 與帳號控制權

先登入目前 registrar，核對：

  • 網域名稱及 TLD。
  • registrant 名稱、組織及 Email。
  • administrative contact 或適用聯絡資料。
  • 帳號主要 Email、MFA、復原電話及復原碼。
  • 網域建立日、到期日及自動續約狀態。
  • 目前 registrar 及客戶編號。
  • transfer lock 及 EPP status。
  • 最近是否變更 registrant 或完成 transfer。
  • 是否有爭議、付款、贖回或特殊狀態。

先備份一筆 DNS sample，再盤點全集

先顯示一筆實際結構，但在文件中匿名化：

  • name：@
  • type：A
  • value：203.0.113.10
  • TTL：3600
  • 其他供應商特有欄位：proxy=off
類型主要用途轉移後驗收
NS指定 DNS hostRegistry／公開查詢的 nameserver
A／AAAA網站或服務 IPdig／nslookup＋HTTP
CNAMEwww、CDN 或第三方服務最終解析及服務功能
MX郵件接收公開 MX＋外部寄入
TXTSPF、DMARC、驗證及其他文字完整值、數量及查詢
DKIM郵件簽章公鑰，可能是 TXT 或 CNAMEselector 查詢＋測試信
CAA可簽發憑證的 CA公開查詢＋續期驗證
DS／DNSSECDNSSEC 信任鏈驗證解析器及官方工具
SRV通訊或其他服務探索對應用戶端或服務測試

分開保存網站與 Email 驗收資料

網站 baseline：

  • example.com 與 www.example.com 的解析。
  • HTTP 到 HTTPS 轉址。
  • TLS 憑證及有效期。
  • 首頁、重要 landing page、表單及登入。
  • CDN、WAF 及來源主機設定。
  • MX 優先權及目的地。
  • SPF 完整字串，並確認只有一筆 SPF。
  • DKIM selector 及紀錄值。
  • DMARC policy 及報告地址。
  • autodiscover、mail 或其他用戶端紀錄。
  • 從外部寄入、向外寄出及郵件驗證結果。

核對到期、付款與續期

要把三個時間分開：

  1. Registry 或公開資料所示的 expiration。
  2. Registrar 帳務所示的續約截止或服務期限。
  3. 轉入訂單及可能增加年限的生效日。
項目來源 registrar目標 registrar是否一次性幣別／稅額正式來源
轉出待填不適用可能待填合約／報價
轉入不適用待填是待填結帳頁
增加年限待確認待確認視 TLD不適用TLD／registrar 文件
標準續約不適用待填每期待填非促銷價
隱私／安全加值待填待填每期待填方案頁

從解鎖到完成驗收，網域轉移流程怎麼走？

以下流程以「同一個網域更換 registrar，盡量保留 DNS 及網站服務」為目標。實際按鈕、授權方式及時程要依 TLD 與來源／目標 registrar 的正式文件調整。

步驟一：確認註冊人與控制權

輸入：

  • RDAP／WHOIS 公開資料。
  • 目前 registrar 帳號。
  • registrant 及聯絡 Email。
  • 公司合約、付款或授權證據。
  • 網域 owner 表。
  • 有權發起及核准 transfer 的人。
  • 聯絡 Email 可用性。
  • 帳號、MFA 及復原狀態。
  • registrant 權利有爭議。
  • 帳號只能由無法聯絡的前人員存取。
  • 聯絡 Email 無法接收通知。
  • 網域涉及法院、爭議或特殊限制。

步驟二：確認轉移資格及目標 registrar

依 TLD 查正式政策，再核對來源及目標 registrar：

  • 是否支援該 TLD。
  • 初次註冊、前次 transfer 或 registrant change lock。
  • EPP status。
  • 到期、贖回、付款及續期狀態。
  • AuthInfo 或替代授權方式。
  • 轉入費、續期、稅額及幣別。
  • DNS、DNSSEC、MFA 及權限功能。
  • 可轉／不可轉判定。
  • 最早可執行日期。
  • 轉移成本。
  • nameserver 保留或 DNS 搬遷計畫。

步驟三：備份 DNS 並建立驗收基準

輸入：

  • 公開 DNS 查詢。
  • DNS host 匯出。
  • 網站及 Email 測試。
  • 匿名 sample row。
  • 完整 zone baseline。
  • nameserver、DNSSEC 及 DS baseline。
  • 網站 HTTP／TLS baseline。
  • Email MX／SPF／DKIM／DMARC 與寄收 baseline。
  • 匯出紀錄：A 4＋AAAA 2＋CNAME 8＋MX 2＋TXT 12＋CAA 1＋SRV 3＝32
  • 公開抽查：網站 4＋郵件 8＋驗證 5＋其他關鍵紀錄 6＝23
  • 其餘低風險紀錄：32－23＝9

步驟四：解鎖並安全取得授權資訊

在目前 registrar：

  1. 依正式流程關閉 transfer lock。
  2. 取得或自行產生 AuthInfo。
  3. 確認 code 沒有前後空白或過期。
  4. 檢查 registrant／admin Email 可收確認。
  5. 記錄解鎖及取得時間。
  6. 以安全方式交給實際操作人。

步驟五：向目標 registrar 申請轉入

在目標 registrar：

  1. 輸入要轉入的網域。
  2. 確認 TLD 及資格。
  3. 輸入 AuthInfo 或完成指定授權。
  4. 檢查 registrant、nameserver 及 DNS 選項。
  5. 確認轉入費、增加年限、稅額及續約標準價。
  6. 完成付款。
  7. 保存訂單編號及狀態。

步驟六：完成來源與目標雙方核准

轉移可能需要：

  • 目標 registrar 驗證 transfer request。
  • registrant 或 administrative contact Email 確認。
  • 來源 registrar 的 transfer-out 核准或取消選項。
  • .tw 或特定 TLD 的線上流程及身分文件。

步驟七：確認 registrar of record 已變更

完成通知到達後，從三處驗證：

  1. 目標 registrar 後台顯示網域可管理。
  2. RDAP／WHOIS 顯示新的 registrar of record。
  3. 來源 registrar 顯示已轉出或不再負責續約。
  • registrant 資料仍正確。
  • expiration date 及增加年限符合正式規則。
  • 自動續約及付款方式符合公司政策。
  • transfer lock 重新啟用。
  • AuthInfo 已輪替或不再可用。
  • 兩位公司管理員可登入，並啟用 MFA。

步驟八：驗收 DNS、網站與 Email

比較轉移前後：

項目搬前搬後證據異常處理
RegistrarABRDAP／WHOIS聯絡雙方 registrar
Nameserver基準 NS應相同或依計畫公開 NS 查詢依 baseline 恢復
DNSSECvalid／未啟用應符合計畫DS＋驗證工具依供應商順序修復
網站解析基準 IP／CNAME應相同dig＋HTTP查 NS 與 zone
HTTPS有效應有效瀏覽器＋TLS查 DNS、CDN 及憑證
MX基準值應相同公開 MX恢復郵件紀錄
SPF／DKIM／DMARC基準值應相同TXT／CNAME＋測試信依郵件商文件修復
外部寄入成功成功實際收件查 MX 及郵件 log
向外寄出驗證通過驗證通過郵件 header查 SPF／DKIM／DMARC
到期／續期基準符合轉入規則後台＋正式通知向目標 registrar 查核

步驟九：保存紀錄及移除不再需要的存取

交付文件至少包含：

  • 轉移日期、操作人及核准人。
  • 來源與目標 registrar。
  • 適用 TLD 規則及正式文件。
  • 訂單、付款及完成通知。
  • 轉移前後 RDAP／WHOIS。
  • DNS baseline 與轉移後查詢。
  • 網站及 Email 測試結果。
  • expiration date 及續約設定。
  • 管理員、MFA 及復原方式。
  • 例外、修復及重測。

來源：ICANN Transfer Policy、ICANN 網域轉移 FAQ、ICANN Auth-Code 說明與TWNIC 網域名稱註冊管理業務規章（查證 2026-07-24）。實際授權、核准、費用及完成時間依 TLD 與 registrar 而異，所有值應從自己的網域狀態及正式文件取得。

網域轉移常見的八個風險

Registrar transfer 的技術動作不多，但它處理的是網域控制權。風險多半來自敏感憑證、錯誤時機、DNS 邊界及續期誤解。

風險一：AuthInfo 外洩

AuthInfo 可能被用來發起 transfer。把 code 貼到工單、聊天室、Email 主旨或可共用試算表，會擴大未授權存取風險。

  • 只從 registrar 官方後台取得。
  • 用密碼管理工具或安全表單傳遞。
  • 限定實際操作人。
  • 轉移完成後輪替 code 或確認舊 code 失效。
  • 恢復 transfer lock。
  • 檢查 registrar 登入及變更紀錄。

風險二：聯絡 Email 無法收信

Transfer request 可能需要 registrant 或 administrative contact 確認。如果聯絡信箱已停用，或屬於前員工，或剛好使用同一個可能受 DNS 影響的公司網域，核准流程可能中斷。

  • 在開始前實際寄信測試聯絡 Email。
  • 確認公司有合法權限及復原方式。
  • 修改資料前先查是否會觸發 Change of Registrant lock。
  • 保存所有核准信及完成通知。

風險三：把 ICANN 60 天規則套用到所有 TLD

ICANN Transfer Policy 的 60 天情況適用其政策範圍內的 gTLD。.tw 及其他 ccTLD 有自己的 Registry 規則。

  • 每個網域先標 TLD。
  • 連到對應 Registry 官方政策。
  • 再讀來源及目標 registrar 文件。
  • 不用一個網域的成功經驗 batch 套用不同 TLD。
  • 排程寫成條件及窗口，不承諾固定完成日。

風險四：轉移時意外更換 nameserver

如果目標 registrar 預設使用自家 nameserver，而新的 DNS zone 尚未建立，網站、Email、子網域及驗證可能同時失效。

  • 提交前核對 nameserver 欄位。
  • 備份完整 zone。
  • 若必須更換 DNS，先在新 host 建好所有紀錄。
  • 轉移後立即從公開網路查 NS。
  • 網站與 Email 分開驗收。

如何在保持 DNS 不變的情況下降低轉移風險？

以下是匿名情境示例，不代表任何特定 registrar 的按鈕名稱或固定時程。

情境設定

  • 網域：example.com
  • TLD：.com
  • 目的：從 registrar A 轉到 registrar B。
  • 網站：維持在原主機。
  • DNS host：使用獨立 DNS 服務，nameserver 不變。
  • Email：維持原企業信箱。
  • registrant：公司不變。
  • 網站 URL：不變。

這個示例刻意只改 registrar，不搬網站，不換 DNS host，不換 Email，不改 registrant。範圍越單純，轉移後若出現異常，越容易找到差異。

轉移前

  1. 查政策：確認 .com 適用的 ICANN Transfer Policy，以及 A 與 B 雙方 .com 文件。
  2. 查資格：核對建立日、前次 transfer、registrant change、lock、爭議及到期。
  3. 查 owner：registrant 及聯絡 Email 由公司掌握，測試能收信。
  4. 查帳號：A 的登入、MFA 及復原正常。
  5. 比較費用：記錄 B 的轉入、增加年限、標準續約、稅額及幣別。
  6. 保存 DNS：匯出完整 zone，確認 nameserver 為獨立 DNS host。
  7. 保存 DNSSEC：記錄 DS、DNSKEY 及驗證狀態。
  8. 網站 baseline：DNS、HTTPS、重要頁及表單成功。
  9. Email baseline：MX、SPF、DKIM、DMARC 及寄收成功。
  10. 核准窗口：指定 registrant owner、操作人、DNS 及郵件負責人。

提交前的 sample 驗證

從 DNS export 取一筆匿名 sample：

  • 網站相關：A 2＋AAAA 2＋CNAME 3＝7
  • 郵件相關：MX 2＋SPF 1＋DKIM 2＋DMARC 1＝6
  • 驗證及其他：TXT 5＋CAA 1＋SRV 2＝8
  • 總數：7＋6＋8＝21

執行轉移

  1. 在 A 解除 transfer lock。
  2. 以安全方式取得 AuthInfo。
  3. 從 B 官方後台建立 transfer order。
  4. 確認 B 顯示保留既有 nameserver。
  5. 確認轉入費及年限承諾。
  6. 提交 AuthInfo 並付款。
  7. 從官方後台完成所有必要核准。
  8. 監控 A、B 及 registrant Email 的通知。
  9. 不在等待期間更換 DNS、網站及 Email。

內文精華總結

  • 網域轉移是什麼？與換網域、改 DNS、搬網站有何不同：這兩件事可能分開，也可能在同一個商業交易中先後發生。
  • 轉移註冊商不會把 old.com 變成 new.com：想把品牌從 old.com 改成 new.com ，需要另外註冊或取得 new.com ，建立網站及 Email，設定舊 URL 到新 URL 的永久轉址，再處理 Search Console、內鏈及其他品牌資產。
  • 轉移註冊商不等於更換 DNS 代管：Registrar 管理網域註冊資料、續用及轉移；DNS host 管理 nameserver 與 zone 中的解析紀錄。
  • 轉移註冊商不等於網站搬家：網站檔案及資料庫放在 hosting provider，不會因 registrar 轉移自動複製。

想把網域轉移規劃成能長期營運的網站？

先用秒站建立可操作的網站，再依實際內容、功能與營運需求調整。你可以先試用，查看方案，或從真實案例確認適合自己的方向。

延伸閱讀

網站基礎建設系列文章

秒站現在不只是一套版型。你可以從現成架構快速開始，用頁面編輯器拖曳、複製與調整版面；需要更高自由度時，也能和 AI 協作，把自製頁面放進 Vibe 畫布。上線速度與設計自由不必二選一。

重點整理

網域轉移是什麼？與換網域、改 DNS、搬網站有何不同？

轉註冊商是更換管理網域註冊的公司；換網域是 old.com 改成 new.com；改 DNS 是更換解析設定或代管；搬網站是更換網站檔案與資料庫所在環境。四者可以分開發生，註冊人資料變更還可能觸發額外鎖定規則。

轉移註冊商不會把 old.com 變成 new.com要注意什麼？

網域名稱本身無法透過「轉移」改字。想把品牌從 old.com 改成 new.com ，需要另外註冊或取得 new.com ，建立網站及 Email，設定舊 URL 到新 URL 的永久轉址，再處理 Search Console、內鏈及其他品牌資產。註冊商轉移則是在不同管理商之間交接同一個 old.com 。網站 URL 理論上不因轉移而變，SEO 也不需要因註冊商名稱改變而逐頁設定 301。

轉移註冊商不等於更換 DNS 代管要注意什麼？

Registrar 管理網域註冊資料、續用及轉移；DNS host 管理 nameserver 與 zone 中的解析紀錄。兩個角色可以是同一家，也可以分開。把網域從 A 轉到 B 時，可以選擇保留既有 nameserver。只要 Registry 中的 nameserver 委派沒有被更動，公開 DNS zone 就可能繼續由原 DNS host 回應。

轉移註冊商不等於網站搬家要注意什麼？

網站檔案及資料庫放在 hosting provider，不會因 registrar 轉移自動複製。只轉 registrar 時，網站主機 IP、程式及資料通常不需要改動。網站搬家則是把網站複製到新主機，可能需要切換 A／AAAA／CNAME。若公開 URL 不變，主要工作是新環境測試與 DNS 切換；若同時換網域，才需要 URL mapping、301／308、canonical、sitemap 及 Search Console 遷移。

轉移註冊商不等於企業信箱搬家要注意什麼？

企業信箱透過 DNS 的 MX 紀錄接收郵件，並使用 SPF、DKIM、DMARC 等紀錄驗證寄件來源。Registrar 轉移本身不會把信箱帳號與歷史郵件移到新系統。如果 nameserver 及 DNS zone 保持不變，郵件紀錄也應保持不變；若更換 DNS 代管，就要先完整複製： 轉移後要從外部查詢實際 MX、SPF、DKIM 及 DMARC，並測試不同外部服務的寄入與寄出。

「網域可以改嗎」要先分成三個問題要注意什麼？

先問三件事：要換註冊商？要更換網域名稱？還是只改 DNS 或網站主機？三種目的涉及不同權限、風險及驗收方式，先定義問題才能判斷是否需要授權碼、轉址、DNS 切換或網站搬遷。

Registry、Registrar、Registrant、DNS host 與網站主機差在哪裡？

Registry 維護特定 TLD 的註冊資料與技術框架；Registrar 受理註冊及轉移；Registrant 是網域持有人；DNS host 管理解析紀錄；hosting provider 提供網站執行環境。應在責任表中記錄各服務的公司、帳號、權限與續約人。

Registry 制定特定 TLD 的技術與政策框架要注意什麼？

Registry 維護某個頂級網域的註冊資料及系統。例如 TWNIC 管理台灣國碼頂級網域、註冊資料與服務系統；不同 gTLD 則有各自 Registry operator，並透過 ICANN 認可的 registrar 提供服務。一般註冊人不會直接在 Registry 的底層系統修改資料，而是透過 registrar 申請及管理。轉移規則要看 TLD 與適用政策，不應因 .com 能用某流程，就推論 .tw 或其他 ccTLD 完全相同。

分享此文章：

相關文章