Hướng dẫn thiết lập SPF, DKIM và DMARC cho tên miền gửi email

Xác thực email thường bị bỏ qua khi bạn thiết lập hệ thống gửi thư tự động. Bạn kết nối nhà cung cấp email, gửi một thư thử nghiệm, và nó rơi thẳng vào thư mục spam. Hoặc Gmail trả lại thư với lỗi 550 5.7.26 về người gửi chưa được xác thực. Bài viết này giải thích cách một tên miền gửi thư được xác thực, giúp thư của bạn tránh xa thư mục spam.

Sơ đồ xác thực email với SPF, DKIM và DMARC

Ba thành phần bảo mật email quan trọng nhất là SPF, DKIM và DMARC. Chúng cho phép máy chủ nhận thư kiểm tra xem một thư có được phép sử dụng tên miền của bạn hay không, và chúng hoạt động cùng nhau: SPF xác thực địa chỉ IP của máy chủ gửi, DKIM thêm chữ ký mã hóa để chứng minh tính toàn vẹn của thư, còn DMARC dùng cả hai kết quả để kiểm tra sự khớp với địa chỉ người gửi hiển thị và thực thi chính sách của bạn.

Việc cấu hình đúng không đảm bảo thư sẽ vào hộp thư đến, nhưng thiếu bản ghi chắc chắn khiến thư thông thường không đến được. Thư đặt lại mật khẩu và hóa đơn cũng cần những kiểm tra này chẳng khác gì bản tin quảng cáo.

Ba câu hỏi mà máy chủ nhận thư đặt ra

Khi thư của bạn đến, máy chủ nhận sẽ hỏi ba câu hỏi. Mỗi bản ghi trả lời một câu:

• SPF (Sender Policy Framework): Máy chủ đã gửi thư này có được phép gửi thay cho tên miền này không?
• DKIM (DomainKeys Identified Mail): Thư này có thực sự đến từ tên miền này không, và nó có đến nguyên vẹn không?
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Những câu trả lời đó có áp dụng cho địa chỉ mà người nhận thấy trong dòng From không? Nếu không, thư nên bị xử lý thế nào?

Cả ba đều là bản ghi DNS: những đoạn văn bản ngắn được công bố tại nhà cung cấp DNS của bạn, như Cloudflare, để bất kỳ máy chủ thư nào cũng có thể tra cứu.

Điều đáng lưu ý là mỗi kiểm tra đọc một tên miền khác nhau từ cùng một thư. SPF dùng Return-Path, DKIM dùng tên miền d= trong chữ ký, còn DMARC dùng địa chỉ From. Hầu hết các vấn đề khi thiết lập đều đến từ việc một trong những tên miền đó không phải là tên miền bạn mong đợi.

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

SPF là danh sách các máy chủ được phép gửi thư cho một tên miền, được công bố dưới dạng bản ghi TXT trong DNS. Khi thư đến, máy chủ nhận so sánh địa chỉ IP đã gửi thư với danh sách đó. Nếu địa chỉ nằm trong danh sách, SPF đạt. Nếu không, SPF thất bại hoặc softfail, tùy thuộc vào cách bản ghi kết thúc.

Ví dụ SPF cho máy chủ example.com:

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

Điều dễ bỏ sót là SPF kiểm tra tên miền nào. Nó không nhìn vào địa chỉ From mà người nhận thấy. Nó kiểm tra người gửi phong bì (envelope sender), còn gọi là MAIL FROM hoặc Return-Path. Đó là một địa chỉ riêng được dùng ở hậu trường, chủ yếu để thư báo lỗi có nơi gửi về.

Hãy hình dung một lá thư trong phong bì. Bưu điện dùng địa chỉ gửi lại trên phong bì; người đọc thấy tiêu đề thư bên trong. SPF kiểm tra phong bì, không phải tiêu đề thư.

SPF cũng gắn với máy chủ chuyển giao thư. Khi thư được chuyển tiếp, máy chủ chuyển tiếp trở thành bên gửi thư, và nó thường không nằm trong danh sách của bạn, nên SPF thường thất bại sau khi chuyển tiếp.

DKIM: chữ ký chứng minh thư là của bạn

DKIM hoạt động như một con dấu chống giả mạo. Khi nhà cung cấp của bạn gửi thư, nó ký thư bằng khóa riêng mà chỉ nhà cung cấp nắm giữ, rồi thêm chữ ký vào thư dưới dạng header. Khóa công khai tương ứng được công bố trong DNS của bạn, nên bất kỳ máy chủ nhận nào cũng có thể tra cứu và kiểm tra chữ ký.

Nếu chữ ký hợp lệ, bên nhận biết được hai điều. Thư được ký bởi người kiểm soát khóa của tên miền đó, và những phần đã ký không bị thay đổi trên đường đi. Những phần được ký là phần thân thư và một tập header luôn bao gồm From và thường bao gồm Subject.

Mỗi chữ ký ghi rõ tên miền mà nó ký trong trường d=. Đó là tên miền mà bên nhận tra cứu, và cũng là tên miền mà DMARC sau đó so sánh với địa chỉ From của bạn.

DMARC: gắn tất cả với địa chỉ From

SPF và DKIM có một lỗ hổng khi dùng riêng lẻ: cả hai đều không kiểm tra địa chỉ From mà người nhận thấy. Kẻ gửi spam có thể gửi thư qua máy chủ của chúng, với SPF đạt cho tên miền Return-Path của chúng và chữ ký DKIM cho tên miền của chúng, mà vẫn đặt tên miền của bạn vào dòng From. Cả hai kiểm tra đều đạt, nhưng cho sai tên miền.

DMARC bịt lỗ hổng đó bằng cách kết nối các kiểm tra với tên miền trong địa chỉ From hiển thị. Để một thư đạt DMARC, ít nhất một trong hai SPF hoặc DKIM phải đạt và dùng tên miền khớp với tên miền From. Sự khớp đó gọi là alignment (căn chỉnh).

Theo quy tắc mặc định (relaxed), hai tên miền bất kỳ chia sẻ cùng organizational domain thì được coi là khớp. Organizational domain là phần bạn mua từ nhà đăng ký, ví dụ example.com. Vì vậy mail.example.com và send.mail.example.com khớp với nhau, nhưng cả hai đều không khớp với example.net.

Điều này giải thích kết quả tưởng chừng khó hiểu khi cả SPF và DKIM đều báo "pass" nhưng DMARC lại báo "fail". Các kiểm tra có thể thành công nhưng cho sai tên miền.

Trước khi mở phần cài đặt DNS

Hãy chọn tên miền bạn sẽ gửi thư. Với thư từ ứng dụng, một tên miền phụ như mail.example.com là điểm khởi đầu tốt. Nó cho bạn không gian cấu hình việc gửi thư mà không trộn lẫn các bản ghi đó vào thiết lập bạn dùng cho email nhân viên.

Bạn cần quyền truy cập vào dịch vụ lưu trữ DNS của mình. Đó có thể là nhà đăng ký tên miền, nhưng cũng có thể là Cloudflare hoặc một nhà cung cấp khác. Nếu không chắc, lệnh sau sẽ hiển thị nameserver của tên miền:

dig NS example.com +short

Trong Mailfully, thêm tên miền từ trang Domains. Bạn sẽ nhận được danh sách các bản ghi, kèm nút sao chép và trạng thái cho từng bản ghi.

Bước 1: thêm các bản ghi DKIM

Mailfully cung cấp ba bản ghi CNAME DKIM. Mỗi bản ghi trỏ đến một khóa công khai do Mailfully lưu trữ, nghĩa là khóa có thể xoay vòng mà không cần chỉnh sửa DNS thêm lần nữa.

Hãy chú ý đến trường Name hoặc Host. Một số nhà cung cấp DNS yêu cầu tên đầy đủ; số khác tự động thêm tên vùng cho bạn. Nếu bạn đang sửa vùng example.com và biểu mẫu tự thêm example.com, hãy nhập k7qz2._domainkey.mail. Nhập tên đầy đủ vào loại biểu mẫu đó có thể tạo ra k7qz2._domainkey.mail.example.com.example.com.

Đó là một nơi hợp lệ để công bố bản ghi, nhưng không máy chủ nhận nào sẽ tìm khóa DKIM của bạn ở đó.

Nếu bạn dùng Cloudflare, hãy đặt các CNAME này thành DNS only (đám mây màu xám). Proxy chỉ dành cho lưu lượng web và ngăn CNAME phân giải đến đích DKIM như mong muốn.

Bước 2: thiết lập SPF trên return path

Nhiều nhà cung cấp email dùng tên miền riêng của họ cho Return-Path trừ khi bạn cấu hình một tên miền tùy chỉnh. SPF có thể đạt trong thiết lập đó, nhưng nó sẽ không khớp với tên miền From của bạn. Thư của bạn vẫn có thể đạt DMARC nhờ DKIM khớp; thiết lập MAIL FROM tùy chỉnh cho nó thêm một cách để đạt.

Ví dụ, Mailfully mặc định dùng send.. Với tên miền gửi của chúng ta, tên miền MAIL FROM trở thành send.mail.example.com. Bạn cần một bản ghi MX và một bản ghi TXT tại tên đó.

Ảnh chụp màn hình cấu hình bản ghi SPF và DKIM

Bản ghi MX định tuyến thư báo lỗi trở lại dịch vụ gửi. Bản ghi TXT ủy quyền cho các máy chủ được liệt kê qua _spf.mailfully.com gửi thay cho tên miền này.

Các bản ghi này thuộc về send.mail.example.com. Bạn không cần thay thế bản ghi SPF mà Google Workspace hay Microsoft 365 dùng tại example.com. Bản ghi SPF áp dụng cho tên nơi nó được công bố; chúng không được kế thừa bởi tên miền phụ.

Một tên miền chỉ có thể có một bản ghi SPF duy nhất. Nếu bạn công bố hai bản ghi TXT bắt đầu bằng v=spf1 tại cùng một tên, bên nhận sẽ trả về lỗi permerror. Ngoài ra còn có giới hạn 10 lần tra cứu DNS trong quá trình đánh giá, bao gồm các tra cứu do mục include: lồng nhau gây ra.

Bước 3: thêm DMARC và theo dõi báo cáo

Trước tiên, hãy kiểm tra xem tên miền của bạn đã có chính sách DMARC chưa. Đừng thay thế chính sách quarantine hoặc reject hiện có bằng none chỉ để làm theo ví dụ này. Nếu bạn không công bố _dmarc.mail.example.com, bên nhận sẽ dùng chính sách tại _dmarc.example.com, bao gồm cả chính sách tên miền phụ sp= nếu có.

Với thiết lập mới chưa có chính sách, hãy bắt đầu với:

v=DMARC1; p=none;

p=none yêu cầu bên nhận không cách ly hay từ chối thư vì chính sách DMARC của bạn. Họ vẫn có thể lọc thư vì lý do khác. Điều này cho bạn cơ hội tìm ra những người gửi hợp lệ chưa khớp trước khi yêu cầu bên nhận chặn những thư thất bại.

Để xem điều gì đang diễn ra, hãy thêm một địa chỉ nhận báo cáo tổng hợp:

v=DMARC1; p=none; rua=mailto:[email protected]

Hãy tạo hộp thư hoặc alias đó trước khi công bố bản ghi. Các bên nhận tham gia thường gửi báo cáo XML hàng ngày cho thấy các IP gửi thư họ quan sát được và kết quả xác thực. Những tệp này không dễ đọc bằng tay, nên một dịch vụ báo cáo DMARC sẽ hữu ích khi chúng bắt đầu đến.

Hãy để báo cáo có đủ thời gian bao phủ hoạt động gửi thư thông thường của bạn. Vài tuần có thể đủ cho một ứng dụng gửi thư hàng ngày, nhưng sẽ không cho bạn biết nhiều về hệ thống thanh toán chỉ gửi mỗi tháng một lần.

Khi những người gửi đó đều đạt, hãy chuyển chính sách sang p=quarantine và tiếp tục theo dõi. Khi bạn chắc chắn thư hợp lệ đã được bao phủ, chuyển sang p=reject để yêu cầu bên nhận từ chối những thư thất bại.

Bước 4: gửi thư thật và kiểm tra

Các bản ghi mới thường hiển thị trong vài phút, dù bộ nhớ đệm và nhà cung cấp DNS có thể khiến thời gian chờ lâu hơn. Mailfully kiểm tra các bản ghi dựa trên DNS trực tiếp và đánh dấu các vấn đề phổ biến.

Khi các bản ghi đã xác thực, hãy gửi thư qua cùng đường đi mà ứng dụng của bạn sẽ dùng trong môi trường sản xuất. Một thư thử từ hộp thư cá nhân sẽ không cho bạn biết liệu nhà cung cấp của ứng dụng có ký thư đúng hay không.

Hãy gửi đến một tài khoản Gmail, sau đó mở menu thư và chọn Show original. Bạn sẽ thấy phần tóm tắt xác thực ở gần đầu. Ở phía dưới, hãy tìm header Authentication-Results do Gmail thêm vào.

Ảnh chụp màn hình kết quả xác thực email trong Gmail

Hãy kiểm tra cả tên miền chứ không chỉ chữ "pass". DKIM nên dùng tên miền gửi của bạn, và smtp.mailfrom nên dùng tên miền MAIL FROM tùy chỉnh bạn đã thiết lập. Kết quả cuối cùng bạn muốn là dmarc=pass cho tên miền From hiển thị.

Việc đạt được cả SPF và DKIM khớp là điều đáng làm, dù DMARC chỉ cần một trong hai. Chuyển tiếp thư thường phá vỡ SPF, nhưng DKIM có thể tồn tại qua bước đó miễn là bên chuyển tiếp không thay đổi nội dung đã ký.

Nếu vẫn còn lỗi

Dưới đây là một số vấn đề thường gặp và cách kiểm tra:

• Tên miền mãi ở trạng thái pending: Kiểm tra tên DNS đầy đủ đã lưu và xem CNAME có bị proxy không.
• spf=permerror: Tìm bản ghi SPF trùng lặp hoặc chính sách vượt giới hạn tra cứu.
• spf=pass nhưng dmarc=fail: Kiểm tra xem Return-Path có khớp với tên miền From không. SPF đạt trên tên miền nhà cung cấp là chưa đủ.
• dkim=pass nhưng dmarc=fail: Kiểm tra tên miền d= của chữ ký so với tên miền From, bao gồm cả thiết lập căn chỉnh nghiêm ngặt nếu có.
• Mọi thứ đều đạt nhưng thư vào spam: Kiểm tra uy tín tên miền và IP, khiếu nại, nội dung thư và mô hình gửi. Xác thực một mình không quyết định vị trí hộp thư.

Nếu xác thực đã đạt, việc thêm bản ghi DNS không giải quyết được vấn đề uy tín. Với một tên miền mới, hãy bắt đầu với lượng thư dự kiến ở mức vừa phải rồi tăng dần. Google khuyến nghị giữ tỷ lệ thư bị báo spam dưới 0,1% và tránh mức 0,3% trở lên.

Nếu DNS của bạn trên Cloudflare

Bạn có thể tiết kiệm thao tác sao chép thủ công bằng cách chọn Set up with Cloudflare trên trang tên miền của Mailfully. Nó dùng Domain Connect: bạn đăng nhập vào Cloudflare, xem xét các thay đổi DNS được đề xuất và phê duyệt.

Nếu Mailfully tìm thấy bản ghi DMARC hiện có trên tên miền hoặc tên miền cha, thiết lập này sẽ để yên chính sách đó và chỉ thêm các bản ghi DKIM và MAIL FROM. Chính sách quarantine hoặc reject hiện có vẫn được giữ nguyên.

Sau đó, trang tên miền liệt kê các bản ghi và trạng thái của chúng. Khi chúng đã xác thực, hãy gửi thư thử từ Bước 4. Đó là cách bạn xác nhận thiết lập đang hoạt động với chính loại thư mà ứng dụng của bạn thực sự gửi.

Xác thực email không phải là viên đạn bạc cho khả năng vào hộp thư đến, nhưng nó là nền tảng bắt buộc. Với người dùng Việt Nam gửi thư giao dịch qua Gmail, việc thiết lập đúng SPF, DKIM và DMARC ngay từ đầu sẽ tiết kiệm rất nhiều thời gian xử lý sự cố về sau.