Đừng đoán mò DNS của bạn: hướng dẫn thân thiện với lập trình viên về MX, SPF, DKIM và DMARC

Vì sao bản ghi DNS cho email hiện nay lại quan trọng

Xác thực email từng là tùy chọn. Đến năm 2026, đó là điều kiện tối thiểu. Gmail và Outlook đều thực thi SPF và DKIM đối với người gửi số lượng lớn, và DMARC đang nhanh chóng trở thành bắt buộc với mọi domain gửi email giao dịch. Nếu bản ghi DNS của bạn sai, email của bạn sẽ không đến nơi—không có bounce, không có cảnh báo, chỉ là im lặng.

Vấn đề là các bản ghi này được tài liệu hóa như RFC, không phải như công cụ. Hầu hết lập trình viên sao chép-dán ví dụ từ hướng dẫn thiết lập của nhà cung cấp email rồi hy vọng mọi thứ ổn. Cách đó hiệu quả cho đến khi bạn cần khắc phục sự cố, thêm dịch vụ gửi thứ hai, hoặc giải thích với khách hàng vì sao email từ biểu mẫu liên hệ của họ lại rơi vào spam.

Hướng dẫn này đi qua MX, SPF, DKIM và DMARC theo đúng thứ tự bạn sẽ thực sự gặp chúng, với đủ chi tiết để cấu hình đúng và đủ bối cảnh để gỡ lỗi khi chúng gặp sự cố.

Bản ghi MX: email gửi đến sẽ đi đâu

Bản ghi MX cho internet biết máy chủ thư nào chấp nhận email cho domain của bạn. Chúng là loại đơn giản nhất trong bốn loại, nhưng cũng là loại dễ cấu hình sai nhất.

Một bản ghi MX có hai phần: số ưu tiên và hostname. Số ưu tiên thấp hơn sẽ được thử trước. Nếu bạn dùng Google Workspace, bản ghi MX của bạn có thể trông như thế này:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Các dấu chấm ở cuối rất quan trọng—chúng cho biết hostname là tên miền đầy đủ. Hầu hết nhà cung cấp DNS tự động thêm chúng, nhưng không phải tất cả.

Các lỗi phổ biến: trỏ bản ghi MX đến một bản ghi A thay vì hostname, đặt tất cả mức ưu tiên cùng một số (làm mất ý nghĩa của việc có máy chủ dự phòng), hoặc quên xóa bản ghi MX cũ khi bạn chuyển nhà cung cấp. Bản ghi MX cũ không chỉ nằm đó một cách vô hại—chúng có thể gây vòng lặp thư hoặc chia việc gửi thư sang hai hộp thư đến.

Nếu bạn đang vận hành biểu mẫu liên hệ của riêng mình và muốn tránh spam mà không phụ thuộc vào dịch vụ bên thứ ba, hiểu cách biểu mẫu trở thành vector spam là một điểm khởi đầu hữu ích.

SPF: máy chủ nào được phép gửi thay bạn

SPF (Sender Policy Framework) là một bản ghi TXT liệt kê các địa chỉ IP và domain được phép gửi email thay mặt domain của bạn. Đây là bước kiểm tra đầu tiên mà hầu hết máy chủ thư thực hiện khi nhận một thư tự nhận là đến từ bạn.

Một bản ghi SPF cơ bản trông như sau:

v=spf1 include:_spf.google.com ~all

Phân tích từng phần:

• v=spf1 khai báo phiên bản SPF
• include:_spf.google.com ủy quyền cho bản ghi SPF của Google
• ~all là soft fail—từ chối thư từ nguồn không được liệt kê, nhưng đừng quá nghiêm ngặt

Bạn cũng có thể dùng ip4: hoặc ip6: để đưa các địa chỉ cụ thể vào danh sách cho phép, hoặc a và mx để tham chiếu bản ghi A và MX của domain. Cơ chế all ở cuối kiểm soát điều gì xảy ra với thư từ các nguồn bạn không liệt kê: -all là hard fail (từ chối), ~all là soft fail (đánh dấu là đáng ngờ), ?all là trung lập (không có ý kiến), và +all là mở hoàn toàn (đừng dùng cách này).

SPF có hai điểm sắc cạnh. Thứ nhất, nó hỏng khi email được chuyển tiếp, vì máy chủ chuyển tiếp không nằm trong bản ghi SPF của bạn. Thứ hai, bản ghi SPF có giới hạn tra cứu là mười truy vấn DNS. Nếu bạn include quá nhiều dịch vụ bên thứ ba, bạn sẽ vượt giới hạn và SPF sẽ ngừng hoạt động. Cách khắc phục là flatten bản ghi SPF—thay các chỉ thị include: bằng dải IP thực tế—nhưng việc này cần bảo trì khi nhà cung cấp thay đổi IP.

DKIM: bằng chứng mật mã về danh tính người gửi

DKIM (DomainKeys Identified Mail) thêm chữ ký số vào email gửi đi của bạn. Máy chủ nhận kiểm tra chữ ký này với khóa công khai được công bố trong DNS của bạn. Nếu chữ ký hợp lệ và thư chưa bị can thiệp, DKIM đạt.

Khác với SPF, DKIM vẫn hoạt động sau khi chuyển tiếp, vì chữ ký đi cùng thư. Nó cũng linh hoạt hơn—bạn có thể có nhiều khóa DKIM cho các dịch vụ gửi khác nhau, mỗi khóa có selector riêng.

Một bản ghi DNS DKIM trông như sau:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Selector (default trong ví dụ này) là tùy ý—nhà cung cấp email của bạn chọn nó. Giá trị p= là khóa công khai, thường là một chuỗi dài được mã hóa base64. Nhà cung cấp email tạo khóa riêng và dùng nó để ký các thư gửi đi.

Việc thiết lập DKIM gần như luôn do nhà cung cấp email xử lý. Việc của bạn là sao chép bản ghi TXT họ cung cấp và dán vào DNS. Phần khó là một số nhà cung cấp DNS không xử lý tốt bản ghi TXT dài—họ hoặc cắt ngắn chúng, hoặc yêu cầu bạn tách giá trị thành nhiều chuỗi đặt trong dấu ngoặc kép.

Để xác minh DKIM đang hoạt động, hãy gửi một email thử nghiệm đến một địa chỉ Gmail và kiểm tra header. Tìm dkim=pass trong header Authentication-Results.

DMARC: thực thi chính sách và báo cáo

DMARC (Domain-based Message Authentication, Reporting and Conformance) kết nối SPF và DKIM với nhau, đồng thời cho máy chủ nhận biết phải làm gì khi xác thực thất bại. Nó cũng bật báo cáo, để bạn có thể thấy ai đang gửi email dưới danh nghĩa domain của bạn—cả hợp lệ lẫn giả mạo.

Một bản ghi DMARC tối thiểu trông như sau:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none nghĩa là chỉ giám sát—không từ chối hoặc cách ly thư thất bại
• rua=mailto:[email protected] chỉ định nơi gửi báo cáo tổng hợp

Khi bạn tự tin rằng SPF và DKIM đang hoạt động, bạn có thể siết chính sách thành p=quarantine (đưa thư thất bại vào spam) hoặc p=reject (bounce chúng ngay). Bạn cũng có thể đặt chính sách cho subdomain bằng sp= và chỉ định tỷ lệ phần trăm thư áp dụng chính sách bằng pct=.

Báo cáo DMARC là các tệp XML được các bên nhận lớn gửi hằng ngày. Chúng dài dòng và khó đọc ở dạng thô, nhưng cho bạn biết chính xác thư nào đạt hoặc không đạt xác thực và vì sao. Nếu bạn thấy thư hợp lệ bị từ chối, các báo cáo sẽ cho biết kiểm tra SPF hoặc DKIM nào đang thất bại.

Một điểm dễ vấp: DMARC yêu cầu alignment. Với SPF, domain trong header Return-Path phải khớp với domain trong header From (hoặc là subdomain). Với DKIM, domain d= trong chữ ký DKIM phải khớp với domain From. Nếu bạn dùng dịch vụ gửi bên thứ ba, họ cần hỗ trợ return path tùy chỉnh hoặc ký DKIM bằng domain của bạn, không phải của họ.

Cách audit thiết lập hiện tại của bạn

Hầu hết vấn đề DNS đều vô hình cho đến khi chúng gây sự cố. Đây là cách kiểm tra bản ghi của bạn trước khi có gì đó hỏng:

1. Truy vấn bản ghi MX của bạn: dig MX example.com nên trả về hostname và mức ưu tiên của máy chủ thư. Xác minh chúng khớp với tài liệu của nhà cung cấp email.

1. Kiểm tra cú pháp SPF: dig TXT example.com và tìm bản ghi v=spf1. Chạy nó qua một trình xác thực SPF để bắt lỗi cú pháp và vi phạm giới hạn tra cứu.

1. Xác minh khóa DKIM: Gửi một email thử nghiệm và kiểm tra header DKIM-Signature. Trích xuất selector và domain, rồi truy vấn dig TXT selector._domainkey.example.com để xác nhận khóa công khai tồn tại.

1. Xác thực chính sách DMARC: dig TXT _dmarc.example.com nên trả về bản ghi DMARC của bạn. Đảm bảo rua= trỏ đến một địa chỉ bạn thực sự theo dõi.

1. Kiểm thử từ đầu đến cuối: Dùng một dịch vụ như mail-tester.com hoặc gửi đến một địa chỉ Gmail và kiểm tra toàn bộ header. Tìm spf=pass, dkim=pass, và dmarc=pass trong header Authentication-Results.

Nếu bạn đang gỡ lỗi vì sao email không đến nơi, header là công cụ tốt nhất. Hầu hết ứng dụng email cho phép bạn xem header thô—trong Gmail, mở thư, bấm dấu ba chấm và chọn 'Hiển thị bản gốc'. Header Authentication-Results sẽ cho bạn biết chính xác kiểm tra nào thất bại và vì sao.

Khi nào nên dùng chính sách subdomain

Nếu bạn gửi email từ nhiều subdomain—ví dụ newsletter.example.com cho marketing và app.example.com cho thư giao dịch—bạn có thể đặt chính sách DMARC riêng cho từng subdomain. Cách này cho phép bạn thực thi chính sách nghiêm ngặt trên các subdomain bạn kiểm soát, trong khi giữ chính sách thoáng hơn trên domain chính.

Đổi lại là độ phức tạp. Mỗi subdomain cần bản ghi SPF, DKIM và DMARC riêng, và bạn cần theo dõi dịch vụ gửi nào được phép cho subdomain nào. Với hầu hết nhóm nhỏ, một domain được cấu hình tốt sẽ đơn giản hơn và cũng an toàn không kém.

Làm gì khi xác thực bị hỏng

Kiểu lỗi phổ biến nhất là thêm một dịch vụ gửi mới mà không cập nhật DNS. Nếu bạn bắt đầu dùng một nhà cung cấp email giao dịch mới, bạn cần thêm SPF include hoặc dải IP của họ, cấu hình ký DKIM bằng domain của bạn, và xác minh DMARC alignment.

Vấn đề phổ biến thứ hai là chuyển tiếp. Nếu người dùng chuyển tiếp email của bạn đến địa chỉ khác, SPF sẽ thất bại vì máy chủ chuyển tiếp không nằm trong bản ghi SPF của bạn. DKIM thường vẫn qua được chuyển tiếp, nên miễn là DKIM đạt và chính sách DMARC của bạn cho phép alignment một phần, thư vẫn nên được gửi. Nếu bạn thấy thư được chuyển tiếp bị từ chối, hãy kiểm tra chính sách DMARC—p=reject với alignment nghiêm ngặt sẽ làm hỏng chuyển tiếp.

Vấn đề thứ ba là lan truyền DNS. Thay đổi bản ghi DNS có thể mất nhiều giờ để lan truyền, và các máy chủ thư khác nhau cache bản ghi trong thời gian khác nhau. Nếu bạn vừa cập nhật một bản ghi và nó chưa hoạt động, hãy chờ vài giờ rồi thử lại. Bạn có thể kiểm tra lan truyền bằng một công cụ như whatsmydns.net.

Điểm chính cần nhớ

• Bản ghi MX định tuyến thư gửi đến; SPF, DKIM và DMARC xác thực thư gửi đi. Chúng giải quyết các vấn đề khác nhau và bạn cần cả bốn.
• SPF hỏng khi chuyển tiếp và có giới hạn mười lượt tra cứu. DKIM vẫn hoạt động khi chuyển tiếp nhưng cần cấu hình theo từng dịch vụ. DMARC kết nối chúng với nhau và bật báo cáo.
• Bắt đầu với p=none trong DMARC, theo dõi báo cáo trong vài tuần, rồi siết lên p=quarantine hoặc p=reject khi bạn tự tin rằng thư hợp lệ đang qua được.
• Lỗi DNS thường im lặng. Hãy kiểm thử cấu hình bằng email thật và kiểm tra header để xác nhận SPF, DKIM và DMARC đều đạt.
• Nếu xác thực bị hỏng sau khi thêm dịch vụ gửi mới, hãy kiểm tra SPF includes, DKIM selectors, và DMARC alignment. Header sẽ cho bạn biết kiểm tra nào thất bại.

Câu hỏi thường gặp

Q: Tôi có thể có nhiều bản ghi SPF không?

A: Không. Nhiều bản ghi SPF sẽ khiến tất cả chúng bị bỏ qua. Nếu bạn cần cho phép nhiều dịch vụ, hãy dùng chỉ thị include: trong một bản ghi SPF duy nhất, hoặc liệt kê trực tiếp dải IP. Hãy chú ý giới hạn mười lượt tra cứu.

Q: Tôi có cần DMARC nếu mỗi ngày chỉ gửi vài email không?

A: Có. DMARC không liên quan đến lưu lượng—nó là để chứng minh bạn đúng là người bạn nói mình là. Ngay cả domain nhỏ cũng hưởng lợi từ DMARC vì nó ngăn giả mạo và cho bạn khả năng nhìn thấy các vấn đề gửi thư. Hãy bắt đầu với p=none và một địa chỉ nhận báo cáo.

Q: Điều gì xảy ra nếu DKIM và SPF đều thất bại nhưng email trông hợp lệ?

A: Điều đó phụ thuộc vào chính sách DMARC của bạn. Nếu p=none, thư được gửi kèm cảnh báo. Nếu p=quarantine, thư vào spam. Nếu p=reject, thư bị bounce. Đây là lý do bạn nên theo dõi báo cáo DMARC trước khi thực thi chính sách nghiêm ngặt—có thể bạn có những nguồn gửi hợp lệ mà bạn chưa biết.

Q: Tôi có thể dùng cùng một khóa DKIM cho nhiều domain không?

A: Về mặt kỹ thuật là có, nhưng đừng. Mỗi domain nên có cặp khóa DKIM riêng. Chia sẻ khóa khiến việc rotation khó hơn và làm tăng phạm vi ảnh hưởng nếu khóa riêng bị lộ.

Q: Tôi nên xoay vòng khóa DKIM bao lâu một lần?

A: Không có quy tắc chung cho mọi trường hợp, nhưng mỗi năm một lần là hợp lý với hầu hết domain. Nếu bạn nghi ngờ một khóa đã bị lộ, hãy xoay vòng ngay. Đảm bảo công bố khóa công khai mới trong DNS trước khi bắt đầu ký bằng khóa riêng mới, và giữ khóa cũ trong DNS thêm vài ngày sau khi xoay vòng để xử lý thư bị trễ.

<!-- tool-cta:start -->

💡 Hãy thử điều này: Kiểm tra chính sách đã công bố của bất kỳ miền nào bằng DMARC Lookup để xem các bản ghi MX, SPF và DMARC kết hợp với nhau trong thực tế như thế nào.

<!-- tool-cta:end -->

Nguồn

• RFC 7208: Sender Policy Framework (SPF) — Đặc tả SPF, bao gồm quy tắc cú pháp và giới hạn mười lượt tra cứu.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Đặc tả DKIM, bao gồm tạo và xác minh chữ ký.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Đặc tả DMARC, bao gồm cú pháp chính sách và định dạng báo cáo tổng hợp.
• Google Workspace: Prevent spoofing and spam — Hướng dẫn thực tế về cấu hình SPF, DKIM và DMARC cho domain Google Workspace.