Định tuyến DNS và Mail

Email Concepts Encyclopedia Published March 2026

ELI5: Hãy tưởng tượng bạn muốn gửi một lá thư cho ai đó tại một công ty. Bạn không biết tòa nhà chính xác, nên bạn gọi đến tổng đài của công ty (DNS) và hỏi "tôi nên gửi thư đến đâu?" (truy vấn MX). Họ cung cấp cho bạn một danh sách các phòng thư được xếp hạng theo mức độ ưu tiên. Bạn thử cái đầu tiên. Nếu nó đóng cửa, bạn thử cái tiếp theo. Nếu công ty không có danh sách tổng đài, bạn thử địa chỉ văn phòng chính (bản ghi A). Nếu họ đã dán một biển báo nói "không nhận thư" — đó là Null MX.

Cách DNS điều khiển toàn bộ đường dẫn gửi email — các bản ghi MX, mức độ ưu tiên và dự phòng, dự phòng A/AAAA, Null MX, các bản ghi PTR và các bản ghi DNS mà mọi miền gửi cần.

Thuật toán định tuyến thư

Khi máy chủ gửi cần gửi tin nhắn đến user@example.com, nó tuân theo thuật toán này, được định nghĩa trong RFC 5321 Phần 5:

Truy vấn bản ghi MX cho example.com
Nếu bản ghi MX tồn tại, sắp xếp theo mức độ ưu tiên (số thấp hơn = ưu tiên cao hơn)
Đối với mỗi tên máy chủ MX, phân giải các bản ghi A và/hoặc AAAA để lấy địa chỉ IP
Cố gắng kết nối với MX có mức độ ưu tiên cao nhất. Nếu thất bại, hãy thử cái tiếp theo.
Nếu không có bản ghi MX (phản hồi NODATA), dự phòng sang bản ghi A/AAAA của miền và cố gắng gửi ở đó
Nếu bản ghi MX là Null MX (0 .), miền không chấp nhận thư — tạo ra lỗi vĩnh viễn
Nếu miền không tồn tại (NXDOMAIN), tạo ra lỗi vĩnh viễn

Bản ghi MX

Bản ghi MX (Mail Exchanger) là loại bản ghi DNS chính để định tuyến thư. Nó ánh xạ một miền đến một hoặc nhiều máy chủ thư với các mức độ ưu tiên:

$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.
30 mx-backup.example.com.

Mỗi bản ghi có hai phần:

Mức độ ưu tiên (giá trị sở thích) — Các số thấp hơn được thử trước. Máy chủ gửi luôn cố gắng MX có mức độ ưu tiên thấp nhất trước tiên.
Trao đổi (tên máy chủ) — Máy chủ thư để kết nối. Đây phải là tên máy chủ, không bao giờ là địa chỉ IP. Tên máy chủ phải có bản ghi A hoặc AAAA.

Mức độ ưu tiên và dự phòng

Trong ví dụ trên, người gửi thử mx1.example.com trước tiên (mức độ ưu tiên 10). Nếu máy chủ đó không thể truy cập được, trả về lỗi 4xx tạm thời hoặc kết nối hết thời gian chờ, người gửi sẽ thử mx2.example.com (mức độ ưu tiên 20), sau đó là mx-backup.example.com (mức độ ưu tiên 30).

Nếu nhiều bản ghi MX có cùng mức độ ưu tiên, người gửi nên ngẫu nhiên hóa giữa chúng. Điều này cung cấp cân bằng tải:

10 mx1.example.com.
10 mx2.example.com.
10 mx3.example.com.

Ở đây, cả ba máy chủ đều có mức độ ưu tiên bằng nhau. Máy chủ gửi chọn ngẫu nhiên một trong số chúng cho mỗi lần cố gắng gửi, phân phối tải trên cả ba.

MX phải trỏ đến tên máy chủ, không phải IP

Trường trao đổi của bản ghi MX phải là tên máy chủ. Nó không thể là địa chỉ IP (RFC 5321 rõ ràng về điều này). Tên máy chủ chính nó phải phân giải thành bản ghi A và/hoặc AAAA. Nó phải không là CNAME — mặc dù một số trình phân giải chấp nhận các mục tiêu MX là CNAME, điều này bị cấm về mặt kỹ thuật và gây ra các vấn đề tương tác.

MX không được trỏ đến CNAME

Đây là một cấu hình sai phổ biến. Nếu mx1.example.com là CNAME trỏ đến mail.provider.com, một số máy chủ gửi sẽ không gửi được. Luôn sử dụng bản ghi A/AAAA cho các mục tiêu MX.

Dự phòng A/AAAA

Nếu miền không có bản ghi MX nào cả (thậm chí không có Null MX), máy chủ gửi sẽ dự phòng sang bản ghi A hoặc AAAA của miền và cố gắng gửi SMTP ở đó. Điều này được gọi là quy tắc "MX ngầm".

; Không có bản ghi MX cho tiny-domain.com
tiny-domain.com. IN A 198.51.100.50

Máy chủ gửi sẽ cố gắng gửi đến 198.51.100.50 trên cổng 25. Điều này hoạt động, nhưng nó được coi là thực hành tồi tệ cho bất kỳ miền nào gửi hoặc nhận thư một cách tích cực. Luôn phát hành các bản ghi MX rõ ràng.

Dự phòng chỉ áp dụng khi có số bản ghi MX bằng không. Nếu bản ghi MX tồn tại nhưng tất cả các máy chủ MX không thể truy cập được, người gửi không dự phòng sang bản ghi A — nó xếp hàng đợi tin nhắn để thử lại.

Null MX: "Miền này không chấp nhận thư"

RFC 7505 định nghĩa Null MX — một cách để rõ ràng khai báo rằng miền không chấp nhận email:

no-mail.example.com. IN MX 0 .

Dấu chấm đơn (.) là trao đổi, với mức độ ưu tiên 0, có nghĩa là "không cố gắng gửi". Máy chủ gửi nên ngay lập tức tạo ra lỗi vĩnh viễn (5.1.2 — hệ thống đích xấu) thay vì lãng phí thời gian kết nối.

Sử dụng Null MX cho:

Các miền chỉ gửi email và không bao giờ nhận
Các miền được đỗ xe
Các miền được sử dụng độc quyền cho lưu trữ trang web

Nếu không có Null MX, người gửi sẽ dự phòng sang bản ghi A và lãng phí thời gian cố gắng kết nối sẽ không bao giờ thành công.

Bản ghi PTR: DNS đảo ngược

Bản ghi PTR ánh xạ địa chỉ IP trở lại tên máy chủ. Đó là điều ngược lại của bản ghi A:

; Tìm kiếm phía trước
mail.example.com. IN A 198.51.100.42

; Tìm kiếm đảo ngược
42.100.51.198.in-addr.arpa. IN PTR mail.example.com.

Bản ghi PTR không phải là một phần của thuật toán định tuyến MX, nhưng chúng rất quan trọng cho khả năng gửi. Hầu hết các nhà cung cấp hộp thư lớn kiểm tra bản ghi PTR của địa chỉ IP máy chủ kết nối:

IP phải có bản ghi PTR (PTR bị thiếu = có khả năng spam)
Tên máy chủ PTR sẽ phân giải lại thành cùng IP (DNS đảo ngược được xác nhận về phía trước, hoặc FCrDNS)
Tên máy chủ PTR không nên trông "chung chung" (ví dụ: 198-51-100-42.dynamic.isp.com gợi ý kết nối dân cư)

Bản ghi PTR được quản lý bởi chủ sở hữu khối địa chỉ IP (thường là nhà cung cấp lưu trữ hoặc ISP của bạn), không phải thông qua DNS của miền. Bạn có thể cần liên hệ với nhà cung cấp của mình để đặt hoặc thay đổi bản ghi PTR.

Bản ghi DNS mà mọi miền gửi cần

Đây là bộ hoàn chỉnh các bản ghi DNS cho miền gửi email thông qua dịch vụ như Mailer To Go:

; Bản ghi MX (để nhận thư)
example.com. IN MX 10 mx1.example.com.
example.com. IN MX 20 mx2.example.com.

; Bản ghi A cho máy chủ MX
mx1.example.com. IN A 203.0.113.10
mx2.example.com. IN A 203.0.113.11

; Bản ghi SPF (ai có thể gửi là miền này)
example.com. IN TXT "v=spf1 include:_spf.mailertogo.com -all"

; Khóa công khai DKIM (để xác minh chữ ký)
mtg._domainkey.example.com. IN CNAME mtg._domainkey.mailertogo.com.

; Chính sách DMARC
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

; Chính sách MTA-STS (thực thi TLS cho thư đến)
_mta-sts.example.com. IN TXT "v=STSv1; id=20260311"

; TLSRPT (báo cáo lỗi TLS)
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Đối với miền gửi nhưng không nhận thư (ví dụ: tên miền phụ được sử dụng cho email giao dịch):

; Null MX (không chấp nhận thư)
notifications.example.com. IN MX 0 .

; SPF, DKIM, DMARC như trên
notifications.example.com. IN TXT "v=spf1 include:_spf.mailertogo.com -all"
mtg._domainkey.notifications.example.com. IN CNAME mtg._domainkey.mailertogo.com.
_dmarc.notifications.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Cân nhắc TTL

Bản ghi DNS có Thời gian tồn tại (TTL) kiểm soát thời gian các trình phân giải lưu trữ chúng. Đối với các bản ghi liên quan đến thư:

Bản ghi MX: 1 giờ (3600) là điển hình. TTL thấp hơn cho phép dự phòng nhanh hơn nhưng tăng tải truy vấn DNS.
Bản ghi SPF/DKIM/DMARC: 1 giờ là phổ biến. Sử dụng TTL ngắn hơn (300 giây) trong quá trình thiết lập hoặc thay đổi ban đầu, sau đó tăng lên.
Bản ghi A/AAAA cho máy chủ MX: 5 phút đến 1 giờ. Ngắn hơn nếu bạn cần thay đổi IP nhanh chóng.

Khi thực hiện thay đổi DNS, giảm TTL trước thay đổi (đợi TTL cũ hết hạn), thực hiện thay đổi, xác minh, sau đó tăng TTL trở lại giá trị hoạt động.

DNSSEC và Thư

DNSSEC (DNS Security Extensions) thêm chữ ký mật mã vào bản ghi DNS, ngăn chặn giả mạo và tham nhũng bộ đệm. Đối với email, DNSSEC đặc biệt quan trọng vì:

Nó xác thực bản ghi MX — kẻ tấn công không thể chuyển hướng thư đến máy chủ giả bằng cách tham nhũng DNS
Nó được yêu cầu cho DANE (DNS-Based Authentication of Named Entities), ràng buộc chứng chỉ TLS với DNS
Nó xác thực SPF, khóa công khai DKIM và bản ghi DMARC

Nếu không có DNSSEC, kẻ tấn công mạng có thể giả mạo phản hồi DNS và chuyển hướng hoặc chặn email. Áp dụng DNSSEC cho các miền email đang tăng lên nhưng chưa phổ biến.

Bản ghi SRV cho Gửi Email

RFC 6186 định nghĩa bản ghi SRV mà các ứng dụng khách thư có thể sử dụng để tự động khám phá máy chủ gửi và IMAP/POP:

_submission._tcp.example.com. IN SRV 0 1 587 mail.example.com.
_imaps._tcp.example.com. IN SRV 0 1 993 imap.example.com.
_pop3s._tcp.example.com. IN SRV 0 1 995 pop.example.com.

Chúng được sử dụng để tự động cấu hình ứng dụng khách thư — khi người dùng nhập địa chỉ email của họ, ứng dụng khách truy vấn bản ghi SRV để tìm máy chủ, cổng và giao thức chính xác. Điều này riêng biệt với định tuyến máy chủ dựa trên MX.

Điều gì có thể sai

Thiếu bản ghi MX

Nếu không có bản ghi MX, người gửi sẽ dự phòng sang bản ghi A của bạn. Nếu máy chủ web của bạn không chạy máy chủ SMTP trên cổng 25, việc gửi thư sẽ không thành công sau hết thời gian chờ. Luôn phát hành các bản ghi MX rõ ràng hoặc Null MX nếu bạn không chấp nhận thư.

MX trỏ đến CNAME

Như đã lưu ý ở trên, điều này là không hợp lệ về mặt kỹ thuật. Một số người gửi sẽ theo CNAME; những người khác sẽ thất bại. Sử dụng bản ghi A/AAAA cho tất cả các tên máy chủ mục tiêu MX.

Tham chiếu MX tuần hoàn

Nếu example.com có MX trỏ đến mail.example.com, và mail.example.com có MX riêng của nó trỏ ngược lại example.com, thư có thể lặp lại. Các mục tiêu MX nên là tên máy chủ lá chỉ có bản ghi A/AAAA.

Thiếu bản ghi PTR

IP gửi của bạn không có DNS đảo ngược hoặc nó phân giải thành tên máy chủ ISP chung chung. Các nhà cung cấp hộp thư lớn (Gmail, Microsoft, Yahoo) sẽ hoãn lại hoặc từ chối thư của bạn. Đảm bảo các IP gửi của bạn có bản ghi PTR giải quyết về phía trước thành cùng IP.

Hết thời gian chờ DNS trong khi gửi

Nếu máy chủ DNS của miền người nhận chậm hoặc không thể truy cập được, máy chủ gửi không thể phân giải bản ghi MX. Tin nhắn được xếp hàng đợi để thử lại. Các lỗi DNS liên tục cuối cùng dẫn đến một bounce (thường sau 4-5 ngày). Không có gì bạn có thể làm là người gửi — đây là vấn đề cơ sở hạ tầng của người nhận.

Bản ghi SPF vượt quá giới hạn UDP DNS

Phản hồi DNS qua UDP được giới hạn ở 512 byte (hoặc 4096 với EDNS0). Bản ghi SPF rất dài với nhiều chỉ lệnh include: có thể bị cắt ngắn. Trình phân giải quay trở lại TCP, điều này làm tăng độ trễ và có thể thất bại nếu máy chủ DNS không hỗ trợ TCP. Giữ bản ghi SPF của bạn ngắn gọn.

Gỡ lỗi DNS cho Thư

Các lệnh cần thiết để chẩn đoán các vấn đề định tuyến thư:

# Kiểm tra bản ghi MX
$ dig MX example.com +short
10 mx1.example.com.
20 mx2.example.com.

# Xác minh các mục tiêu MX phân giải thành IP
$ dig A mx1.example.com +short
203.0.113.10

# Kiểm tra PTR (DNS đảo ngược)
$ dig -x 198.51.100.42 +short
mail.example.com.

# Xác minh DNS đảo ngược được xác nhận về phía trước
$ dig A mail.example.com +short
198.51.100.42

# Kiểm tra bản ghi SPF
$ dig TXT example.com +short | grep spf
"v=spf1 include:_spf.mailertogo.com -all"

# Kiểm tra khóa công khai DKIM
$ dig TXT mtg._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

# Kiểm tra chính sách DMARC
$ dig TXT _dmarc.example.com +short
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

# Kiểm tra Null MX
$ dig MX no-mail.example.com +short
0 .

Những điểm chính

Bản ghi MX là cơ chế chính để định tuyến thư. Các số mức độ ưu tiên thấp hơn được thử trước tiên.
Nếu không có bản ghi MX, người gửi sẽ dự phòng sang bản ghi A/AAAA. Phát hành các bản ghi MX rõ ràng (hoặc Null MX) để tránh sự mơ hồ.
Các mục tiêu MX phải là tên máy chủ có bản ghi A/AAAA — không bao giờ IP, không bao giờ CNAME.
Bản ghi PTR (DNS đảo ngược) không phải là một phần của định tuyến nhưng rất cần thiết cho khả năng gửi. Mỗi IP gửi cần PTR khớp với bản ghi A phía trước.
Miền gửi hoàn chỉnh cần bản ghi MX (hoặc Null MX), SPF, DKIM và DMARC tối thiểu.
Sử dụng dig để xác minh mọi bản ghi DNS trước và sau các thay đổi.