DNS Record Generator

Tính năng nổi bật

• Sinh bản ghi SPF từ sáu nhà cung cấp mail phổ biến, chỉ cần bật công tắc tương ứng
• Thêm IPv4, IPv6 và dải CIDR thủ công, công cụ tự nhận loại địa chỉ
• Đếm số lần tra DNS ước tính và cảnh báo ngay khi chạm trần mười lần của chuẩn SPF
• Chọn cơ chế kết thúc -all hoặc ~all kèm giải thích hệ quả của từng lựa chọn
• Sinh bản ghi DMARC với chính sách, chính sách cho tên miền con, tỷ lệ áp dụng, rua, ruf và chế độ khớp
• Hướng dẫn lấy khóa công khai DKIM theo từng nhà cung cấp, kèm cảnh báo khi khóa quá ngắn
• Tự tách giá trị DKIM thành nhiều chuỗi khi vượt 255 ký tự của một chuỗi TXT
• Ô kiểm tra cú pháp cho bản ghi SPF và DMARC đang có, phân biệt lỗi chặn và cảnh báo rủi ro

Vì sao nên dựng bản ghi ở đây trước khi chạm vào trang quản lý DNS

Ba bản ghi xác thực thư đều là chuỗi văn bản dài, không dấu cách thừa, viết sai một ký tự là hỏng mà giao diện quản lý DNS gần như không bao giờ báo lỗi. Bạn dán vào, hệ thống lưu, mọi thứ trông bình thường, và chỉ vài ngày sau mới phát hiện thư gửi đi rơi vào thư rác. Tệ hơn là loại lỗi không hỏng hẳn: bản ghi SPF hợp lệ về cú pháp nhưng vượt trần số lần tra DNS, khi đó máy chủ nhận trả kết quả lỗi vĩnh viễn và coi như tên miền không có SPF, kể cả thư gửi từ nguồn hoàn toàn hợp lệ. Không có cách nào nhìn bằng mắt mà biết được điều đó. Công cụ này gom mọi lựa chọn thành các ô bấm, tự ghép chuỗi đúng thứ tự, đếm số lần tra DNS theo từng nhà cung cấp và bật cảnh báo trước khi bạn kịp dán lên DNS. Với DMARC, nó chặn luôn hai lỗi kinh điển là thiếu tiền tố mailto trong địa chỉ nhận báo cáo và đặt thẻ chính sách không đứng ngay sau thẻ phiên bản.

Lợi ích khi sử dụng

• •Không phải nhớ chuỗi include của từng nhà cung cấp, chỉ cần bật đúng công tắc
• •Biết trước bản ghi SPF sắp vượt trần thay vì phát hiện khi thư đã rơi vào thư rác
• •Bản ghi DMARC luôn đúng thứ tự thẻ và đúng định dạng địa chỉ nhận báo cáo
• •Khóa DKIM dán vào kiểu gì cũng được chuẩn hóa, kể cả khi còn dòng BEGIN PUBLIC KEY
• •Ô kiểm tra soi được bản ghi đang chạy mà không cần thay đổi gì trên DNS

Cách tạo bộ ba bản ghi xác thực thư

1. 1Nhập tên miền gửi thư ở ô trên cùng, tên bản ghi trong cả ba thẻ sẽ đổi theo giá trị này.
2. 2Ở thẻ SPF, bật công tắc cho từng nhà cung cấp mail bạn đang dùng, thêm IP tĩnh nếu có máy chủ gửi riêng, rồi chọn cơ chế kết thúc.
3. 3Kiểm tra số lần tra DNS ước tính, nếu chạm mức cảnh báo thì bỏ bớt nhà cung cấp không còn dùng trước khi chép bản ghi.
4. 4Sang thẻ DMARC, chọn chính sách none để bắt đầu, điền địa chỉ nhận báo cáo tổng hợp rồi chép bản ghi cho tên _dmarc của tên miền.
5. 5Sang thẻ DKIM, chọn nhà cung cấp để xem đường đi lấy khóa, dán khóa công khai vào và chép bản ghi đã chuẩn hóa.
6. 6Dán cả ba bản ghi lên trang quản lý DNS, chờ vài phút rồi dùng công cụ tra DNS để xác nhận đã có hiệu lực.

Ba bản ghi làm ba việc khác nhau và chỉ có tác dụng khi đi cùng nhau

SPF khai báo danh sách máy chủ được phép gửi thư danh nghĩa tên miền của bạn. Máy chủ nhận thư sẽ so địa chỉ IP của bên gửi với danh sách đó. Điểm yếu của SPF là nó kiểm tra địa chỉ trong phong bì kỹ thuật chứ không kiểm tra dòng người gửi mà người đọc nhìn thấy, và nó vỡ hoàn toàn khi thư được chuyển tiếp qua một hộp thư khác. DKIM giải quyết vế còn lại: máy chủ gửi ký một chữ ký mật mã lên nội dung thư, máy chủ nhận lấy khóa công khai từ DNS của bạn để kiểm tra chữ ký đó. Chữ ký đi theo thư nên vẫn còn nguyên sau khi chuyển tiếp. Nhưng cả hai thứ này đều không nói cho máy chủ nhận biết phải làm gì khi kiểm tra thất bại, và cũng không bắt buộc tên miền trong kết quả kiểm tra phải trùng với tên miền người đọc nhìn thấy. DMARC lấp đúng hai lỗ đó: nó yêu cầu ít nhất một trong hai phép kiểm tra phải qua và phải khớp tên miền với dòng người gửi hiển thị, rồi ra lệnh cho máy chủ nhận xử lý ra sao khi không đạt. Thiếu DMARC thì SPF và DKIM chỉ là thông tin tham khảo.

Trần mười lần tra DNS của SPF: vì sao có, khi nào vỡ, sửa thế nào

Chuẩn SPF quy định máy chủ nhận không được thực hiện quá mười lần tra DNS khi phân giải một bản ghi. Giới hạn này tồn tại để chống việc một tên miền độc hại dựng chuỗi include lồng nhau vô tận, biến mọi máy chủ nhận thư trên thế giới thành công cụ tấn công. Các cơ chế tiêu tốn lượt tra gồm include, a, mx, ptr, exists và redirect, còn ip4 và ip6 thì không tốn lượt nào vì đã là địa chỉ cụ thể. Vấn đề là một chuỗi include có thể lồng nhiều include bên trong, nên bản ghi trông chỉ có ba dòng vẫn có thể tiêu tốn tám chín lượt. Khi vượt trần, kết quả trả về là lỗi vĩnh viễn và phần lớn máy chủ nhận coi như thư trượt SPF. Có ba cách xử lý. Thứ nhất là dọn dẹp: rà lại xem còn dùng dịch vụ nào, bỏ include của dịch vụ đã ngừng. Thứ hai là thay include bằng dải ip4 khi nhà cung cấp công bố dải IP ổn định, cách này bỏ hẳn lượt tra nhưng bạn phải tự theo dõi khi họ đổi dải. Thứ ba là tách các dịch vụ gửi thư hàng loạt sang tên miền con riêng có bản ghi SPF riêng, đây là cách bền nhất.

Lộ trình triển khai DMARC theo ba chặng, đừng nhảy thẳng tới reject

Chặng một là theo dõi. Đặt chính sách none kèm địa chỉ nhận báo cáo tổng hợp, chờ khoảng bốn tuần. Trong thời gian này không có thư nào bị chặn thêm, nhưng mỗi ngày bạn nhận về các tệp báo cáo liệt kê nguồn nào đã gửi thư danh nghĩa tên miền của bạn cùng kết quả kiểm tra. Đây là lần đầu nhiều chủ tên miền phát hiện ra hệ thống nào đang gửi thư mà mình không biết, thường là phần mềm kế toán, hệ thống chăm sóc khách hàng, biểu mẫu liên hệ trên website hoặc một dịch vụ tiếp thị mà phòng khác đăng ký. Chặng hai là cách ly: sau khi mọi nguồn hợp lệ đều đã qua được kiểm tra và khớp tên miền, chuyển sang quarantine, có thể bắt đầu ở tỷ lệ nhỏ rồi nâng dần lên toàn bộ. Thư trượt sẽ vào thư rác chứ chưa bị chặn hẳn, nên vẫn cứu được nếu bạn sót nguồn nào. Chặng ba là từ chối: chuyển sang reject, thư trượt bị máy chủ nhận từ chối thẳng, tên miền của bạn không còn giả mạo được nữa. Nhảy thẳng từ chặng một sang chặng ba là nguyên nhân phổ biến nhất khiến thư thật của doanh nghiệp biến mất.

Khớp tên miền: vì sao thư qua được SPF mà vẫn trượt DMARC

Đây là tình huống gây bối rối nhất khi mới triển khai. Bạn kiểm tra thấy SPF trả kết quả đạt, DKIM cũng có chữ ký hợp lệ, nhưng báo cáo DMARC vẫn báo trượt. Nguyên nhân nằm ở yêu cầu khớp tên miền. DMARC không chỉ hỏi phép kiểm tra có đạt hay không, nó còn hỏi tên miền cho ra kết quả đạt đó có phải là tên miền trong dòng người gửi mà người đọc nhìn thấy hay không. Với SPF, phép kiểm tra chạy trên địa chỉ đường về nằm trong phong bì kỹ thuật, và rất nhiều dịch vụ gửi thư hàng loạt đặt địa chỉ đó thuộc tên miền của chính họ. Kết quả là SPF đạt cho tên miền của nhà cung cấp, không phải cho tên miền của bạn, và DMARC coi như không khớp. Cách sửa là bật tính năng đường về tùy chỉnh trong trang quản trị dịch vụ đó, thường gọi là custom return path hoặc custom MAIL FROM, để địa chỉ đường về nằm trên tên miền con của bạn. Với DKIM thì đơn giản hơn, chỉ cần chữ ký được ký bằng tên miền của bạn thay vì tên miền dùng chung của nhà cung cấp. Chế độ khớp lỏng chấp nhận tên miền con, chế độ khớp chặt đòi trùng khít, nên hãy giữ khớp lỏng cho tới khi mọi thứ ổn định.

Selector, độ dài khóa và giới hạn 255 ký tự khi tạo bản ghi DKIM

Bản ghi DKIM luôn nằm ở tên dạng selector chấm _domainkey chấm tên miền. Selector là nhãn do nhà cung cấp đặt, và mục đích của nó là cho phép một tên miền có nhiều khóa cùng lúc: dịch vụ thư nội bộ dùng một selector, dịch vụ gửi thư tiếp thị dùng selector khác, không đụng nhau. Đây cũng là cơ chế để xoay khóa mà không gián đoạn, bạn tạo selector mới, chuyển sang ký bằng khóa mới, rồi sau vài ngày mới gỡ bản ghi cũ. Về độ dài khóa, mức 2048 bit là tiêu chuẩn hiện nay, mức 1024 bit vẫn chạy nhưng đã bị coi là yếu, và công cụ sẽ cảnh báo khi chuỗi khóa bạn dán vào ngắn bất thường. Vấn đề kỹ thuật hay gặp với khóa 2048 bit là giá trị bản ghi dài hơn 255 ký tự, trong khi chuẩn DNS quy định một chuỗi TXT đơn lẻ không được vượt con số đó. Cách xử lý là tách giá trị thành nhiều chuỗi đặt cạnh nhau trong cùng một bản ghi, máy chủ nhận sẽ ghép lại. Phần lớn giao diện quản lý DNS hiện nay tự làm việc này, nhưng nếu nhà cung cấp DNS của bạn báo lỗi độ dài, hãy dùng bản đã tách sẵn mà công cụ hiện ra ngay dưới bản ghi.

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

Từ khóa liên quan

• tạo bản ghi spf
• tạo bản ghi dmarc
• tạo bản ghi dkim
• spf record generator
• dmarc record generator
• cấu hình spf dkim dmarc
• spf vượt 10 lần tra dns
• lỗi permerror spf
• spf all hay ~all
• chính sách dmarc none quarantine reject
• dmarc rua ruf là gì
• alignment adkim aspf
• dkim selector domainkey
• khóa dkim 2048 bit
• bản ghi txt vượt 255 ký tự
• chống giả mạo email tên miền
• email vào spam do thiếu spf
• kiểm tra cú pháp bản ghi spf
• include spf google workspace
• cấu hình email microsoft 365 dns