RFC 1035 – Tên Miền: Triển Khai và Thông Số Kỹ Thuật

Internet Standard DNS & Mail Routing Published March 2026

ELI5: Khi bạn gửi một lá thư, bạn cần biết bưu điện nào xử lý địa chỉ của người nhận. DNS là danh bạ điện thoại trả lời câu hỏi đó cho email. Bạn tra cứu tên miền và DNS cho bạn biết những máy chủ thư nào chấp nhận email cho nó (bản ghi MX), địa chỉ IP của chúng là gì (bản ghi A/AAAA), và những chính sách nào áp dụng (bản ghi TXT cho SPF, DKIM, DMARC). Nếu không có DNS, không có cách nào để gửi email.

Tại sao RFC này tồn tại

RFC 1035, được công bố năm 1987 cùng với RFC 1034, xác định các chi tiết triển khai của Hệ thống Tên Miền. Mặc dù DNS là cơ sở hạ tầng đa mục đích, nó lại cực kỳ quan trọng đối với email. Mỗi lần gửi email bắt đầu bằng một truy vấn DNS — máy chủ gửi phải khám phá máy chủ nào chấp nhận thư cho miền của người nhận.

RFC 1035 xác định các loại bản ghi, định dạng truy vấn và cấu trúc phản hồi giúp điều này trở thành có thể. Đối với email, bốn loại bản ghi quan trọng nhất: MX (định tuyến trao đổi thư), A (địa chỉ IPv4), AAAA (địa chỉ IPv6, được xác định sau trong RFC 3596) và TXT (bản ghi văn bản được sử dụng cho SPF, khóa DKIM, chính sách DMARC và hơn thế nữa).

Nếu không có RFC 1035, sẽ không có cách tiêu chuẩn để ánh xạ tên miền đến những máy chủ xử lý thư của nó. Mọi cơ chế xác thực và định tuyến trong email hiện đại đều phụ thuộc vào nó.

Cách thức hoạt động

Khi một MTA gửi cần gửi tin nhắn đến user@example.com, nó tuân theo một chuỗi truy vấn DNS cụ thể:

Truy vấn bản ghi MX cho example.com. Phản hồi chứa một hoặc nhiều bộ trao đổi thư, mỗi bộ có giá trị ưu tiên (thấp hơn = ưa thích).
Sắp xếp theo ưu tiên. Nếu nhiều bản ghi MX chia sẻ cùng ưu tiên, người gửi sẽ chọn ngẫu nhiên giữa chúng để cân bằng tải.
Phân giải tên máy chủ MX thành địa chỉ IP bằng cách sử dụng truy vấn A (IPv4) hoặc AAAA (IPv6).
Kết nối đến máy chủ thư tại địa chỉ IP được phân giải trên cổng 25 và bắt đầu phiên SMTP.
Nếu MX ưa thích không thể truy cập được, hãy thử MX ưu tiên thấp hơn tiếp theo, và cứ thế tiếp tục.
Nếu không có bản ghi MX, quay lại bản ghi A/AAAA cho chính miền đó (theo RFC 5321).

Chi tiết kỹ thuật chính

Bản ghi MX — Định tuyến thư

Bản ghi MX là nền tảng của định tuyến email. Nó ánh xạ một miền đến tên máy chủ của các máy chủ thư của nó, với giá trị ưu tiên xác định thứ tự chúng sẽ được thử:

example.com. IN MX 10 mx1.example.com. example.com. IN MX 20 mx2.example.com. example.com. IN MX 30 mx-backup.example.com.

Mục tiêu MX phải là tên máy chủ, không bao giờ là địa chỉ IP. MTA gửi sau đó phân giải tên máy chủ đó thành IP qua truy vấn A/AAAA. Bản ghi MX chỉ đến CNAME về mặt kỹ thuật bị cấm theo đặc tả, mặc dù một số bộ phân giải chấp nhận nó.

Bản ghi A và AAAA — Phân giải IP

Khi biết tên máy chủ MX, bản ghi A cung cấp địa chỉ IPv4 và bản ghi AAAA cung cấp địa chỉ IPv6:

mx1.example.com. IN A 198.51.100.25 mx1.example.com. IN AAAA 2001:db8::25

Nếu tên máy chủ MX phân giải thành cả bản ghi A và AAAA, MTA gửi chọn dựa trên cấu hình của nó và kết nối. Hầu hết các MTA hiện đại ưa thích IPv6 khi có sẵn, quay lại IPv4.

Bản ghi TXT — Xác thực email

Bản ghi TXT ban đầu là một cơ chế chung để đính kèm dữ liệu văn bản vào tên miền. Xác thực email đã áp dụng chúng rộng rãi:

# SPF — máy chủ nào có thể gửi thư cho miền này example.com. IN TXT "v=spf1 include:mailertogo.com ~all" # Khóa công khai DKIM — được sử dụng để xác minh chữ ký tin nhắn selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGf..." # Chính sách DMARC — phải làm gì với thư không vượt qua xác thực _dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Bản ghi TXT bị giới hạn 255 byte trên mỗi chuỗi, nhưng một bản ghi duy nhất có thể chứa nhiều chuỗi được nối. Bản ghi SPF vượt quá 255 byte phải được chia tách theo cách này.

MX Null — RFC 7505

Một miền không chấp nhận email có thể xuất bản bản ghi Null MX — một MX có ưu tiên 0 chỉ đến "." (gốc). Điều này cho máy chủ gửi biết không nên cố gắng gửi, tránh trì hoãn và lỗi trả lại:

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

TTL và Lưu vào bộ nhớ đệm

Mỗi bản ghi DNS có một TTL (thời gian sống) kiểm soát bộ phân giải lưu vào bộ nhớ đệm kết quả trong bao lâu. Đối với bản ghi MX, các TTL điển hình dao động từ 300 đến 3600 giây. TTL thấp hơn cho phép chuyển đổi dự phòng nhanh hơn nhưng tăng khối lượng truy vấn DNS. Trong quá trình di chuyển, giảm TTL trước đó để bản ghi được lưu vào bộ nhớ đệm hết hạn trước khi thay đổi có hiệu lực.

Ví dụ truy vấn DNS

Chuỗi truy vấn DNS hoàn chỉnh để gửi đến user@example.com:

# Bước 1: Truy vấn bản ghi MX $ dig example.com MX +short 10 mx1.example.com. 20 mx2.example.com. # Bước 2: Phân giải tên máy chủ MX ưa thích $ dig mx1.example.com A +short 198.51.100.25 $ dig mx1.example.com AAAA +short 2001:db8::25 # Bước 3: Kiểm tra SPF cho miền gửi $ dig example.com TXT +short "v=spf1 include:mailertogo.com ~all" # Bước 4: Kiểm tra chính sách DMARC $ dig _dmarc.example.com TXT +short "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Lỗi thường gặp

Chỉ bản ghi MX đến địa chỉ IP. Bản ghi MX phải chỉ đến tên máy chủ, không phải IP. MX 10 198.51.100.25 không hợp lệ và sẽ gây ra lỗi gửi.
Chỉ bản ghi MX đến CNAME. Mục tiêu MX phải phân giải trực tiếp thành bản ghi A/AAAA. MX chỉ đến CNAME bị cấm theo đặc tả và gây ra hành vi không thể dự đoán trên các bộ phân giải khác nhau.
Thiếu DNS ngược (PTR) cho các IP máy chủ thư. Mặc dù không được xác định bởi RFC 1035, hầu hết các máy chủ nhận kiểm tra xem địa chỉ IP của máy chủ thư của bạn có bản ghi PTR phân giải lại thành cùng IP. Bản ghi PTR bị thiếu hoặc không khớp kích hoạt bộ lọc thư rác.
Quên cập nhật DNS sau khi di chuyển nhà cung cấp thư. Nếu bạn chuyển dịch vụ email nhưng để lại bản ghi MX cũ, thư sẽ đi đến nhà cung cấp cũ. Luôn xác minh bản ghi MX sau khi di chuyển.
Đặt TTL quá cao trước khi di chuyển. Nếu bản ghi MX của bạn có TTL 24 giờ và bạn thay đổi nhà cung cấp, một số máy chủ sẽ tiếp tục gửi đến đích cũ trong tới 24 giờ. Giảm TTL xuống 300 giây ít nhất 48 giờ trước khi chuyển đổi.
Vượt quá giới hạn 10 truy vấn cho SPF. Đánh giá SPF tuân theo các chỉ thị include: và redirect=, mỗi chỉ thị tạo ra các truy vấn DNS bổ sung. Nhiều hơn 10 truy vấn gây ra lỗi SPF vĩnh viễn. Giữ bản ghi SPF của bạn phẳng.
Không có bản ghi MX và không có bản ghi A. Nếu miền không có bản ghi MX cũng không có dự phòng A/AAAA, thư đến miền đó không thể gửi được. Xuất bản bản ghi MX rõ ràng hoặc ít nhất là bản ghi A.

Tác động khả năng gửi

Bản ghi MX được kiểm tra trước tiên. Nếu bản ghi MX của bạn bị thiếu, cấu hình sai hoặc chỉ đến máy chủ không thể truy cập, không thư nào đến được bạn. Đây là yêu cầu khả năng gửi cơ bản nhất.
SPF, DKIM và DMARC đều nằm trong DNS. Mỗi kiểm tra xác thực email bắt đầu bằng tra cứu bản ghi TXT. Nếu DNS của bạn chậm, không đáng tin cậy hoặc cấu hình sai, xác thực sẽ thất bại và thư của bạn sẽ bị gắn cờ hoặc từ chối.
DNS ngược ảnh hưởng đến danh tiếng người gửi. Máy chủ thư có cấu hình DNS chuyển tiếp và ngược thích hợp được máy chủ nhận tin tưởng hơn. Bản ghi PTR không khớp hoặc bị thiếu là tín hiệu thư rác mạnh.
Trì hoãn lan truyền DNS ảnh hưởng đến di chuyển. Khi thay đổi nhà cung cấp email, bộ nhớ đệm DNS có nghĩa là quá trình chuyển đổi không bao giờ tức thì. Hãy lên kế hoạch cho một giai đoạn mà cả hệ thống cũ và mới phải chấp nhận thư.
IPv6 yêu cầu bản ghi AAAA và PTR phù hợp. Nếu bạn gửi từ địa chỉ IPv6, bạn cần bản ghi AAAA cho tên máy chủ gửi và bản ghi PTR cho địa chỉ IPv6. Cài đặt DNS IPv6 không đầy đủ gây ra lỗi gửi cho các nhà cung cấp thích IPv6.