Không KYC: một email đã xác minh, không giấy tờ tùy thân · Thanh toán bằng tiền mã hóa: BTC, USDT, USDC, ETH, SOL, LTC · .com 12,49 US$/năm, cùng giá mỗi năm
Ngôn ngữ: Tiếng Việt
Tìm địa chỉ của bạn

Hướng dẫn · kiểm tra ngày 12 tháng 11 năm 2026

Làm sao chuyển email sang nhà cung cấp mới mà không mất thư?

Việc chuyển giữa các nhà cung cấp chỉ làm mất thư khi các bước chạy sai thứ tự. Với tên miền riêng, thứ tự là: chuẩn bị, sao chép, chuyển, xác nhận, dọn dẹp.

Cập nhật lần cuối: · 8 phút đọc

Trả lời nhanh

Làm sao chuyển email sang nhà cung cấp mới mà không mất thư?

Hạ TTL của các bản ghi MX xuống 300 đến 600 giây trước 24 đến 48 giờ, nhập kho lưu trữ cũ vào hộp thư mới, đổi các bản ghi MX sau cùng, và giữ tài khoản cũ cho đến khi thư mới đã về. Postelva lưu trữ DNS, nên việc chuyển chỉ cần một lần sửa cho hai bản ghi trở lên.

Khi chuyển, có bao nhiêu bản ghi thay đổi?

Postelva tổng hợp từ các trang trợ giúp của nhà cung cấp, đọc ngày 12 tháng 11 năm 2026. Màn hình của nhà cung cấp bạn là nguồn chính xác nhất cho các giá trị cụ thể.
Nhà cung cấp mớiMXTXT xác minhSPFDKIMDMARCTổng số bản ghi
Proton Mail211 include3 CNAME18
Mailbox.org411 include4 CNAME111
Fastmail2Không bắt buộc với thiết lập chỉ dùng MX1 include3 CNAMEChưa đọc (chưa xác minh)6, không tính DMARC

Năm bước theo đúng thứ tự

  1. Hạ TTL

    Ít nhất 24 đến 48 giờ trước khi chuyển, đặt TTL của các bản ghi MX thành 300 đến 600 giây. Một thay đổi lan truyền trong khoảng TTL cũ, nên giá trị ngắn đặt trước sẽ làm thay đổi diễn ra nhanh.

  2. Chuẩn bị hộp thư mới

    Thêm tên miền ở nhà cung cấp mới, tạo địa chỉ và bí danh, rồi sao chép bản ghi xác minh mà nhà cung cấp hiển thị. Chưa chạm vào các bản ghi MX.

  3. Sao chép thư cũ

    Nhập kho lưu trữ bằng công cụ nhập IMAP của nhà cung cấp mới, trong khi tài khoản cũ vẫn nhận thư. Chuyển tiếp riêng lẻ chỉ chuyển thư mới.

  4. Chuyển các bản ghi MX

    Thay các bản ghi MX cũ bằng bản ghi mới, thêm include SPF mới vào bản ghi SPF hiện có và thêm các bản ghi DKIM. Giữ máy chủ cũ tiếp tục nhận thư cho đến khi TTL cũ hết hạn.

  5. Xác nhận, rồi dọn dẹp

    Gửi thư thử cho chính bạn từ hai tài khoản bên ngoài, kiểm tra header, giữ tài khoản cũ một thời gian, rồi tăng lại TTL và xóa các bản ghi cũ.

Vì sao TTL quyết định thư có bị mất hay không?

TTL là số giây mà bộ phân giải có thể giữ một câu trả lời, nên nó quyết định người gửi tiếp tục dùng các bản ghi MX cũ của bạn trong bao lâu. Nếu TTL cũ là 86400 giây, một người gửi đã tra cứu bạn một phút trước khi thay đổi vẫn sẽ gửi đến máy chủ cũ trong tối đa một ngày. Với TTL 300 đến 600 giây, khoảng thời gian đó chỉ là năm đến mười phút.

Quy tắc trong các hướng dẫn về khả năng nhận thư là hạ TTL 24 đến 48 giờ trước khi chuyển, để mọi bộ nhớ đệm đã giữ giá trị ngắn vào ngày chuyển, rồi tăng lại sau đó. Một thay đổi MX thông thường ổn định trong 1 đến 4 giờ, và có thể mất 24 đến 48 giờ trong trường hợp xấu nhất. Đây là hướng dẫn từ các nhà cung cấp dịch vụ, không phải tiêu chuẩn. Các câu trả lời rỗng cũng được lưu đệm, với TTL của bản ghi SOA của vùng (RFC 2308), nên một bản ghi bạn tạo muộn có thể vẫn không hiển thị ở một số bộ phân giải trong một thời gian.

Làm sao sao chép thư cũ trước khi chuyển?

Nhập kho lưu trữ cũ qua IMAP trước khi đổi bất kỳ bản ghi MX nào. Proton Mail, chẳng hạn, mô tả việc chuyển từ Gmail bằng một công cụ nhập, và các hướng dẫn chuyển nhà cung cấp đều thống nhất cùng một thứ tự: nhập trước, chỉ đổi MX khi đích đã sẵn sàng, và giữ tài khoản cũ cho đến khi bạn xác nhận mọi thứ đã về đủ.

Hai thói quen ngăn được hầu hết mất mát. Thứ nhất, giữ hộp thư cũ tiếp tục nhận thư trong khi quá trình nhập chạy, vì thư đến trong lúc sao chép sẽ chỉ nằm trong tài khoản cũ. Thứ hai, chạy thêm một lần nhập ngắn sau khi chuyển MX để lấy những thư đã rơi vào máy chủ cũ trong thời gian lan truyền. Về thứ tự công việc khi địa chỉ đổi nhà cung cấp nhưng không đổi tên, hãy đọc cách giữ địa chỉ email khi đổi nhà cung cấp.

Làm sao chuyển các bản ghi MX an toàn?

Xóa các bản ghi MX cũ hoặc đặt số ưu tiên thấp nhất cho bản ghi mới, và không bao giờ để hai nhà cung cấp lẫn lộn. Fastmail và Proton Mail đều nói điều này trong trang trợ giúp: khi bản ghi cũ và mới cùng tồn tại, thư được gửi đến một trong hai máy chủ một cách khó đoán. Một bản ghi MX nêu tên một máy chủ thư và một mức ưu tiên; người gửi thử số nhỏ nhất trước. Khái niệm này được giải thích trong bản ghi MX là gì.

Tại Postelva, vùng được sửa trong khu vực khách hàng, và mẫu DNS một cú nhấp cho Proton Mail, Fastmail, Zoho Mail, Google Workspace và Microsoft 365, cùng mẫu SPF + DMARC và mẫu "không email" cho tên miền không gửi thư nào. Một mẫu thay thế các bản ghi MX, SPF và DKIM của nhà cung cấp trong một thao tác. Với Tuta, Mailbox.org, iCloud+ và Migadu, bạn tự nhập các bản ghi MX, TXT và CNAME trong trình chỉnh sửa DNS, theo giá trị hiển thị trên màn hình của chính nhà cung cấp.

SPF và DKIM thay đổi thế nào khi chuyển?

Một tên miền chỉ được công bố một bản ghi SPF, nên hãy thêm include của nhà cung cấp mới vào bản ghi SPF hiện có thay vì tạo bản ghi thứ hai. Proton Mail, Mailbox.org và Mailfence đều đưa ra cùng một chỉ dẫn. Giữ include cũ trong bản ghi cho đến khi bạn ngừng gửi từ nhà cung cấp cũ, rồi xóa nó: kiểm tra SPF cho phép tối đa 10 lần tra cứu DNS (RFC 7208), và mỗi include đều được tính.

DKIM thì khác: mỗi nhà cung cấp dùng tên selector riêng, như fm1, fm2 và fm3 ở Fastmail, hoặc protonmail, protonmail2 và protonmail3 ở Proton Mail, nên các bản ghi mới có thể nằm cạnh các bản ghi cũ cho đến khi bạn gỡ nhà cung cấp cũ. Xem các bản ghi đã công bố bằng các lệnh trong cách kiểm tra bản ghi MX, SPF, DKIM và DMARC.

Làm sao biết việc chuyển đã thành công?

Gửi thư thử đến tên miền từ hai tài khoản bên ngoài và đọc header gửi thư. Theo mục lục của Postelva ngày 12 tháng 11 năm 2026, chuyển sang Proton Mail nghĩa là đổi 8 bản ghi, sang Mailbox.org là 11 và sang Fastmail là 6 (bản ghi DMARC của Fastmail không được đọc trên các trang đã kiểm tra), nên kiểm tra từng loại bản ghi là cách nhanh nhất để tìm bản ghi bị bỏ sót.

Nếu thư không đến, lỗi gần như luôn thuộc một trong các nguyên nhân trong vì sao thư không đến tên miền email tùy chỉnh. Giữ tài khoản cũ mở vài tuần, vì người gửi có bộ nhớ đệm cũ vẫn có thể gửi đến đó. Khi tài khoản cũ vẫn trống, hãy tăng TTL về giá trị thông thường và xóa các bản ghi cũ.

Chuyển nhà cung cấp: các câu hỏi

Việc chuyển mất bao lâu?

Một thay đổi MX thông thường ổn định trong 1 đến 4 giờ và có thể mất 24 đến 48 giờ. Proton Mail yêu cầu bạn cho phép tối đa một ngày. TTL ngắn đặt trước giúp khoảng thời gian chờ nhỏ lại.

Tôi có mất địa chỉ khi chuyển không?

Không, nếu địa chỉ nằm trên tên miền của chính bạn: tên miền vẫn ở cùng nhà đăng ký và chỉ các bản ghi thay đổi. Một địa chỉ trên tên miền của chính nhà cung cấp cũ, như @proton.me hoặc @tuta.com, thì không thể chuyển.

Tôi có thể chuyển mà không nhập thư cũ không?

Được, nhưng bạn sẽ mất kho lưu trữ trong hộp thư mới. Giữ tài khoản cũ mở, hoặc xuất thư, cho đến khi bạn có đủ những gì cần.

Việc chuyển có thay đổi đăng ký tên miền không?

Không. Đăng ký, ngày gia hạn và chủ sở hữu vẫn giữ nguyên. Chỉ các bản ghi DNS trỏ đến máy chủ thư thay đổi.

Có nên chuyển vào giờ vắng không?

Điều đó có ích nhưng không bắt buộc. Điều quan trọng là việc chuyển MX diễn ra sau khi đã nhập xong và sau khi TTL đã được hạ.

Tóm lại
  • Hạ TTL của MX xuống 300 đến 600 giây 24 đến 48 giờ trước khi chuyển.
  • Nhập kho lưu trữ qua IMAP trước; chuyển tiếp chỉ chuyển thư mới.
  • Đổi các bản ghi MX sau cùng; đừng để hai nhà cung cấp lẫn lộn.
  • Chỉ một bản ghi SPF; thêm include mới vào đó; tối đa 10 lần tra cứu DNS.
  • Bản ghi thay đổi: Proton Mail 8, Mailbox.org 11, Fastmail 6 không tính DMARC.
  • Lan truyền thông thường là 1 đến 4 giờ, tối đa 24 đến 48 giờ.
  • Giữ tài khoản cũ cho đến khi các thư thử đã về.
Nguồn (8)
  1. Chuyển từ Gmail sang Proton — Proton (đọc 2026-11-12)
  2. Tên miền riêng từ Namecheap (giá trị MX) — Proton (đọc 2026-11-12)
  3. Chống giả mạo cho tên miền tùy chỉnh — Proton (đọc 2026-11-12)
  4. Bản ghi DNS mặc định — Fastmail (đọc 2026-11-12)
  5. KB của mailbox.org: tên miền tùy chỉnh — mailbox.org (đọc 2026-11-12)
  6. RFC 7208, mục 4.6.4 — RFC Editor (đọc 2026-11-12)
  7. RFC 2308: lưu đệm phủ định của truy vấn DNS — RFC Editor (đọc 2026-11-12)
  8. Mất bao lâu để thay đổi DNS lan truyền — Suped (đọc 2026-11-12)

.com 12,49 US$/năm · không cần KYC · crypto

Tìm địa chỉ của bạn