Bật DMARC từ p=none: nhảy thẳng p=reject có thể chặn thư thật

Để bật DMARC cho tên miền đang gửi thư, hãy kiểm kê mọi dịch vụ gửi email, cấu hình SPF và DKIM, rồi xuất bản bản ghi TXT với p=none và địa chỉ nhận báo cáo. Chỉ tăng lên quarantine rồi reject sau khi xử lý các luồng thư hợp lệ bị lỗi; hướng dẫn của Microsoft cảnh báo rằng siết chính sách quá nhanh có thể khiến máy chủ nhận từ chối thư thật do lỗi DMARC ngoài ý muốn.

Điều kiện quyết định là căn chỉnh với miền trong địa chỉ From mà người nhận nhìn thấy. Thư chỉ đạt DMARC khi SPF hoặc DKIM vừa xác thực thành công, vừa dùng miền phù hợp với From. Một dịch vụ gửi thay mặt doanh nghiệp vẫn có thể trượt DMARC dù bảng điều khiển của dịch vụ báo SPF và DKIM đều hoạt động.

Kiểm kê mọi nơi gửi bằng tên miền doanh nghiệp

Hãy lập danh sách theo từng miền và tên miền phụ xuất hiện trong địa chỉ From. Ngoài hộp thư nhân viên, cần tính cả hệ thống bán hàng, hóa đơn, thông báo đơn hàng, biểu mẫu website và nền tảng tiếp thị. Với doanh nghiệp nhỏ, việc hỏi người phụ trách từng nghiệp vụ thường phát hiện được dịch vụ gửi thay mặt mà quản trị viên không thấy trong hệ thống email chính.

Với mỗi nguồn, ghi lại người quản lý, loại thư, miền From, miền trong địa chỉ MAIL FROM dùng khi truyền thư và miền ký DKIM nếu có. Gửi một thư mẫu từ từng luồng tới hộp nhận cho phép xem phần đầu thư và kết quả xác thực. Luồng gửi theo kỳ, chẳng hạn hóa đơn chỉ phát vào cuối tháng, cũng phải có mặt trong danh sách trước khi quyết định siết chính sách.

Đừng cấp quyền cho một địa chỉ IP chỉ vì báo cáo cho thấy nó gửi thư mang miền của bạn. Địa chỉ đó có thể thuộc dịch vụ đã quên, dịch vụ chuyển tiếp hoặc bên giả mạo. Cần xác định chủ sở hữu và đối chiếu với thư mẫu trước khi sửa SPF hay cấu hình DKIM.

Sửa SPF và DKIM theo miền From

SPF kiểm tra nguồn gửi đối với miền của MAIL FROM; DKIM kiểm tra chữ ký và miền ký trong tham số d=. DMARC đối chiếu miền đã vượt một trong hai phép kiểm tra ấy với miền From. Theo chế độ căn chỉnh mặc định, các tên miền phụ có thể phù hợp khi cùng miền tổ chức; chế độ strict yêu cầu tên miền khớp chính xác.

Ví dụ giả định: hóa đơn có From là [email protected], nhưng dịch vụ chỉ dùng MAIL FROM và chữ ký DKIM thuộc miền của chính họ. SPF và DKIM có thể đều đạt cho miền của dịch vụ, trong khi DMARC vẫn trượt đối với example.com. Chỉ thêm IP của dịch vụ vào bản ghi SPF của example.com không tự khắc phục được tình huống này nếu MAIL FROM vẫn dùng miền khác.

Cách sửa là cấu hình dịch vụ để ký DKIM bằng miền doanh nghiệp, hoặc dùng MAIL FROM thuộc miền hay tên miền phụ doanh nghiệp kiểm soát và cho phép nguồn gửi bằng SPF. Chỉ cần một trong hai đường xác thực đạt và căn chỉnh, nhưng kiểm tra cả hai giúp thấy rõ điều gì sẽ xảy ra khi một dịch vụ thay đổi cấu hình. Với nền tảng tiếp thị, tên miền phụ riêng còn giúp khoanh vùng việc kiểm kê và điều chỉnh chính sách.

Xuất bản p=none và nhận báo cáo

Với miền ví dụ example.com, tạo bản ghi TXT tại _dmarc.example.com có giá trị v=DMARC1; p=none; rua=mailto:[email protected]. Thay miền và hộp nhận bằng thông tin do doanh nghiệp quản lý. Đặc tả RFC 7489 quy định vị trí bản ghi, cú pháp chính sách và địa chỉ nhận báo cáo; nếu truy vấn trả về nhiều bản ghi chính sách DMARC cho cùng một tên, máy nhận sẽ không áp dụng xử lý DMARC cho thư đó.

Sau khi lưu, truy vấn DNS từ bên ngoài để chắc bản ghi đã xuất hiện đúng tên và đúng giá trị. p=none không yêu cầu máy nhận xử lý riêng thư trượt DMARC, nhưng các bộ lọc thư khác vẫn có thể đánh dấu hoặc chặn thư. Trường rua yêu cầu gửi báo cáo tổng hợp về kết quả xác thực; nên dùng hộp thư hoặc công cụ có người chịu trách nhiệm đọc dữ liệu XML nhận được.

Nếu dùng dịch vụ nhận báo cáo tại một miền khác, hãy xác nhận dịch vụ đã thiết lập quyền nhận báo cáo bên ngoài theo cơ chế DMARC. Việc chỉ ghi địa chỉ của họ vào rua chưa bảo đảm máy nhận sẽ gửi dữ liệu. Bạn có thể bắt đầu bằng địa chỉ cùng miền để tránh thêm biến số trong giai đoạn quan sát.

Đọc báo cáo theo từng luồng thư

Đối chiếu IP, miền, số thư và kết quả SPF, DKIM trong báo cáo với danh sách nguồn gửi đã lập. Một nguồn gửi ít thư vẫn có thể là hệ thống hóa đơn quan trọng; tỷ lệ đạt chung cao không phải lý do bỏ qua nó. Khi gặp luồng hợp lệ bị lỗi, hãy xác định đó là nguồn chưa được SPF cho phép, chữ ký DKIM chưa bật hoặc không hợp lệ, hay cả hai miền xác thực đều lệch miền From.

Báo cáo tổng hợp cho thấy mẫu xác thực tại những máy nhận có gửi báo cáo, chứ không tự xác nhận ai sở hữu một IP. Thư mẫu và cấu hình của dịch vụ giúp nối một dòng báo cáo với luồng nghiệp vụ cụ thể. Cũng cần xem các luồng được gửi gián tiếp qua bên chuyển tiếp hoặc danh sách thư, vì quá trình truyền tiếp có thể làm SPF thất bại hoặc khiến chữ ký DKIM không còn hợp lệ.

Điểm dừng của pha quan sát là mọi luồng gửi quan trọng đã được nhận diện, thư mẫu của chúng đạt DMARC và các trường hợp trượt còn lại đã được phân loại. Nếu một dịch vụ gửi theo kỳ chưa xuất hiện trong dữ liệu, hãy chờ kỳ gửi đó hoặc tạo thư thử đại diện trước khi chuyển chính sách. Tiêu chí này hữu ích hơn việc chỉ đếm số ngày kể từ lúc thêm bản ghi.

Tăng quarantine rồi mới cân nhắc reject

Lộ trình của Google Workspace khuyên theo dõi với p=none ít nhất một tuần và xem báo cáo hằng ngày trước khi chuyển một tỷ lệ nhỏ thư trượt DMARC sang quarantine; tài liệu nêu 10% là một mức khởi đầu ví dụ cho tổ chức nhỏ. Khoảng quan sát thực tế cần đủ dài để bao trùm các luồng gửi ít thường xuyên của chính doanh nghiệp.

Khi các luồng quan trọng đã đạt, có thể thử giá trị giả định v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]. Quarantine yêu cầu máy nhận coi thư trượt DMARC là đáng ngờ, chẳng hạn chuyển vào thư rác; cách xử lý cuối cùng do máy nhận quyết định. Tiếp tục đọc báo cáo và xác minh những thư thật bị ảnh hưởng trước khi tăng tỷ lệ.

Chỉ chuyển sang p=reject khi các nguồn gửi hợp lệ đã được sửa và giai đoạn quarantine không còn bộc lộ luồng quan trọng bị lỗi. Reject yêu cầu máy nhận từ chối thư trượt DMARC, nên thay đổi này có hậu quả rõ hơn đối với hóa đơn hoặc thông báo đơn hàng bị cấu hình sai. Nếu dùng pct để tăng dần ở pha reject, đừng hiểu rằng phần thư ngoài tỷ lệ sẽ chắc chắn được phát như bình thường: đặc tả DMARC cho phép máy nhận xử lý phần đó như thư thuộc chính sách quarantine.

Khi đã bao phủ toàn bộ luồng gửi, có thể áp dụng p=reject cho toàn bộ thư trượt DMARC và tiếp tục theo dõi báo cáo. Mỗi dịch vụ bán hàng, hóa đơn hoặc tiếp thị mới cần được kiểm tra miền From, SPF và DKIM trước khi bắt đầu gửi. Như vậy, một thay đổi vận hành sau này sẽ không âm thầm tạo thêm luồng thư thật bị từ chối.

Miền không gửi thư cần chính sách riêng

Với miền thực sự không dùng để gửi email, có thể công bố v=DMARC1; p=reject sau khi xác nhận không có hệ thống nào dùng miền đó trong From. Không có luồng gửi hợp lệ để quan sát và sửa như đối với miền đang hoạt động. Tuy nhiên, cần kiểm kê cả tên miền phụ: chính sách DMARC của miền cha có thể áp dụng cho tên miền phụ không có bản ghi riêng.

Nếu một tên miền phụ đang gửi thông báo hoặc thư tiếp thị, hãy xử lý nó như một nguồn gửi thật trước khi siết chính sách miền cha, hoặc công bố chính sách riêng phù hợp cho tên miền phụ đó. Quyết định phụ thuộc vào cách doanh nghiệp thực sự dùng địa chỉ From, chứ không chỉ vào việc miền gốc có hộp thư nhân viên hay không.

Đọc thêm:

• Tòa chặn danh sách đen Anthropic: ranh giới mới cho hợp đồng AI quân sự
• Copilot có thể duyệt pull request: một thiết lập sẽ biến nhận xét thành phê duyệt
• Buzzsprout gửi podcast tới 16 thư mục bằng một lần nhấp, nhưng vẫn cần kiểm tra duyệt