Tạo và kiểm tra bản ghi SPF và DMARC ngay trong trình duyệt, không truy vấn DNS.
Nhập CIDR để có mạng, quảng bá, máy chủ dùng được và mặt nạ cho IPv4 và IPv6.
Mở →Tra cứu dữ liệu đăng ký RDAP và DNS ngược của địa chỉ IPv4/IPv6, tên miền hoặc URL.
Mở →Hiển thị IP công khai, thông tin mạng và vị trí gần đúng của bạn, kèm kiểm tra rò rỉ WebRTC.
Mở →Chưa có bình luận nào. Hãy là người đầu tiên!
Trình tạo SPF & DMARC xây dựng và kiểm tra bản ghi xác thực email theo RFC 7208 (SPF) và RFC 9989 (DMARC). Với SPF bạn có thể đánh dấu include của các dịch vụ gửi phổ biến, thêm IP, đặt quy tắc kết thúc và ước tính số lượt tra cứu DNS (giới hạn 10); với DMARC bạn đặt chính sách p/sp/np, hộp thư báo cáo, tùy chọn báo cáo lỗi và chế độ căn chỉnh. Bạn cũng có thể dán bản ghi có sẵn để kiểm tra cú pháp ngoại tuyến. Công cụ chỉ xử lý văn bản: không bao giờ truy vấn DNS và không thể chứng minh DNS được cấu hình đúng.
Không. Nó chỉ xây dựng và kiểm tra VĂN BẢN bản ghi trong trình duyệt của bạn và không bao giờ truy vấn DNS, nên không thể chứng minh bản ghi đã được xuất bản hay đang hoạt động. Sau khi xuất bản, hãy xác nhận bằng công cụ tra cứu DNS và kiểm tra kết quả xác thực bằng một thư thử thật.
Theo RFC 7208, một lần đánh giá SPF có thể liên quan tối đa 10 thuật ngữ kích hoạt truy vấn DNS (include, a, mx, ptr, exists và redirect), và các thuật ngữ lồng trong include cũng được tính. ip4, ip6 và all không được tính. Vượt giới hạn, bên nhận trả về permerror, nghĩa là SPF thất bại.
Với các bên gửi phổ biến tích hợp sẵn, công cụ dùng số lượt tra cứu lồng được đo trong DNS công khai vào 2026-10-20; với include bạn tự nhập, số lượng lồng không biết nên được tính là 1 kèm thông báo. Nhà cung cấp có thể đổi bản ghi bất cứ lúc nào, nên hãy xác nhận bằng trình kiểm tra SPF dựa trên DNS trước khi xuất bản.
~all (soft fail) nói rằng nguồn không có trong danh sách có lẽ không được phép nhưng vẫn nên chấp nhận và đánh dấu; phù hợp lúc bắt đầu, trước khi xác nhận mọi bên gửi. -all (hard fail) từ chối thẳng. Hướng dẫn của Google khuyên dùng ~all, còn Microsoft khuyên -all khi DKIM và DMARC cũng đã có. Đừng bao giờ dùng +all, vì nó cho phép bất kỳ ai gửi thư với tư cách tên miền của bạn.
RFC 9989 (DMARCbis) định nghĩa v, p, sp, np, adkim, aspf, fo, rua, ruf, psd và t. Các thẻ pct, rf và ri của RFC 7489 đã bị loại bỏ, với t (cờ thử nghiệm; t=y gần như thay thế cách dùng pct=0 phổ biến) đảm nhận trường hợp sử dụng thông thường. Công cụ này mặc định không ghi pct; nó chỉ được thêm nếu bạn bật trong “Tùy chọn nâng cao và tương thích”.
Bắt đầu với p=none và một địa chỉ rua, rồi thu thập báo cáo tổng hợp ít nhất một tháng để tìm mọi bên gửi hợp lệ. Căn chỉnh SPF hoặc DKIM của từng bên gửi với tên miền From, sau đó chuyển sang p=quarantine và theo dõi lại (dùng t=y trước nếu chưa chắc). Chỉ chuyển sang p=reject khi thư hợp lệ không còn bị ảnh hưởng. p=reject có thể làm gián đoạn danh sách thư và chuyển tiếp, nên hãy đọc báo cáo trước.
Khi hộp thư rua hoặc ruf nằm ngoài tên miền của bạn, tên miền kia phải xuất bản bản ghi TXT có giá trị v=DMARC1; tại “ten-mien-cua-ban._report._dmarc.ten-mien-khac”, nếu không hầu hết bên nhận sẽ không gửi báo cáo; công cụ hiển thị tên máy chủ chính xác. Tài liệu của Postmark nói bạn không cần thêm nó vào SPF, nên nó không có trong các mẫu; giá trị include của mỗi dịch vụ được liệt kê lấy từ tài liệu chính thức của dịch vụ đó.
v=spf1 include:_spf.google.com ~all
| Loại | Tên máy chủ DNS | Giá trị |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.google.com ~all |