Kiểm tra sức khoẻ tên miền gửi mail không chỉ dành cho đội sysadmin. Nếu bạn đang chạy email giao dịch, email marketing, hệ thống CRM, website WordPress, tool MMO hoặc bất kỳ dịch vụ nào có gửi mail, việc này ảnh hưởng trực tiếp đến tỷ lệ vào inbox, độ tin cậy thương hiệu và khả năng bị giả mạo.
Nhiều hệ thống gửi mail vẫn “chạy được” nhưng thực tế đang mất điểm âm thầm. Mail có thể vào spam nhiều hơn, bị Gmail hoặc Outlook trì hoãn, hoặc tệ hơn là bị kẻ khác giả mạo tên miền để gửi phishing.
Checklist tốt nhất là kiểm tra theo định kỳ, có log, có cảnh báo, không đợi đến lúc khách báo “không nhận được mail” mới xử lý.

Vì sao cần Kiểm tra sức khoẻ tên miền gửi mail
Tên miền gửi mail giống như “hồ sơ tín nhiệm” của bạn trước các mailbox provider như Gmail, Outlook, Yahoo, Zoho, iCloud. Một cấu hình sai nhỏ trong DNS hoặc hành vi gửi bất thường có thể làm danh tiếng giảm nhanh.
Với người làm kỹ thuật, điểm đau thường nằm ở chỗ mail server vẫn hoạt động, SMTP vẫn trả 250 OK, nhưng người nhận không thấy mail trong inbox. Khi kiểm tra kỹ mới phát hiện SPF sai, DKIM chưa ký, DMARC chưa bật, IP dính blacklist hoặc reverse DNS không khớp.
Với người làm MMO, affiliate, ecommerce hoặc vận hành nhiều website, vấn đề còn khó hơn. Bạn có thể dùng nhiều công cụ gửi mail khác nhau như hosting, SMTP riêng, email marketing, CRM, plugin WordPress, hệ thống ticket, nhưng tất cả cùng dùng một tên miền.
Pain point 1: Mail gửi đi nhưng không vào inbox
Đây là tình huống phổ biến nhất. Website báo đã gửi mail đặt lại mật khẩu, đơn hàng, OTP hoặc thông báo thanh toán, nhưng người dùng không nhận được.
Nguyên nhân thường gặp:
- SPF thiếu dịch vụ đang gửi mail.
- DKIM chưa bật hoặc selector sai.
- DMARC đặt quá chặt khi chưa kiểm thử.
- IP gửi mail mới, chưa có reputation.
- Nội dung mail giống spam hoặc chứa link rút gọn.
- Tên miền từng bị lạm dụng trước đó.
Một điểm dễ gây nhầm lẫn là “mail vào spam” không luôn do nội dung. Nhiều trường hợp nội dung sạch, nhưng domain authentication yếu nên bị hạ điểm.
Pain point 2: Tên miền bị giả mạo để gửi phishing
Nếu tên miền chưa có DMARC hoặc DMARC để chính sách quá lỏng, kẻ xấu có thể gửi email giả mạo địa chỉ dạng [email protected]. Người nhận nhìn thấy tên miền của bạn, còn bạn có thể không biết gì.
Vấn đề này gây hại ở 2 lớp:
- Người nhận bị lừa, ảnh hưởng uy tín thương hiệu.
- Mailbox provider thấy domain bị lạm dụng, từ đó giảm độ tin cậy.
DMARC report giúp bạn thấy ai đang gửi mail thay mặt domain. Đây là dữ liệu rất quan trọng nếu bạn có nhiều hệ thống gửi mail hoặc nhiều bên thứ ba cùng dùng domain.
Bộ công cụ miễn phí đáng tin
Bạn không cần mua tool đắt tiền để bắt đầu kiểm tra sức khoẻ tên miền gửi mail. Phần lớn lỗi nền tảng có thể phát hiện bằng công cụ miễn phí.
Bảng dưới đây giúp bạn chọn công cụ theo mục đích kiểm tra:
| Nhu cầu kiểm tra | Công cụ gợi ý | Bạn sẽ biết được gì | Ghi chú |
|---|---|---|---|
| Kiểm tra SPF, DKIM, DMARC | MXToolbox, EasyDMARC tools | DNS record đúng hay sai, lỗi cú pháp | Nên kiểm tra sau mỗi lần đổi DNS |
| Kiểm tra header email | Google Admin Toolbox Messageheader | Đường đi email, SPF/DKIM/DMARC pass hay fail | Cần có email mẫu đã nhận |
| Kiểm tra blacklist | MXToolbox Blacklist Check, MultiRBL | IP hoặc domain có bị liệt kê không | Không phải blacklist nào cũng nghiêm trọng như nhau |
| Kiểm tra DNS tổng quát | DNSViz, dig, nslookup | DNS propagate, record trùng, TTL | Hữu ích khi debug sâu |
| Kiểm tra TLS SMTP | CheckTLS, SSL Labs cho web endpoint | Mã hoá kết nối mail có ổn không | Quan trọng với mail server tự vận hành |
| Kiểm tra postmaster | Google Postmaster Tools | Reputation với Gmail, spam rate, auth | Cần xác minh domain |
Bạn có thể tham khảo thêm tài liệu chính thức của Google về email sender guidelines tại https://support.google.com/a/answer/81126. Đây là nguồn đáng tin để hiểu các yêu cầu mới của Gmail với người gửi số lượng lớn.
Nếu bạn đang cấu hình DNS cho email, nên lưu lại toàn bộ record quan trọng trong tài liệu nội bộ. Với hệ thống dùng dịch vụ tại VSIS, bạn có thể xem thêm các hướng dẫn liên quan tại tài liệu DNS, hướng dẫn email và trang dịch vụ VSIS.
Công cụ dòng lệnh nên biết
Nếu bạn quen terminal, vài lệnh cơ bản giúp kiểm tra nhanh mà không phụ thuộc giao diện web.
Kiểm tra MX:
dig MX example.com
Kiểm tra SPF:
dig TXT example.com
Kiểm tra DMARC:
dig TXT _dmarc.example.com
Kiểm tra DKIM theo selector:
dig TXT selector1._domainkey.example.com
Trong đó selector1 là selector do hệ thống gửi mail cung cấp. Với Google Workspace có thể là google, với Microsoft 365 thường là selector1 và selector2, còn các nền tảng email marketing sẽ có selector riêng.
Checklist nhanh khi dùng công cụ miễn phí
Bạn nên kiểm các mục sau trước:
- Domain có MX hợp lệ không.
- SPF có tồn tại và chỉ có một record SPF không.
- DKIM có ký thành công trên email thực tế không.
- DMARC có record tại
_dmarc.domain.comkhông. - IP gửi có reverse DNS hợp lý không.
- IP hoặc domain có nằm trong blacklist lớn không.
- Header email có hiển thị
spf=pass,dkim=pass,dmarc=passkhông.
Lưu ý, SPF pass không có nghĩa toàn bộ hệ thống đã tốt. Gmail và Outlook thường đánh giá kết hợp nhiều tín hiệu, gồm xác thực, lịch sử gửi, tương tác người nhận, tỷ lệ spam complaint và chất lượng nội dung.
Đọc báo cáo DMARC để biết ai đang mạo danh
DMARC là lớp chính sách nằm trên SPF và DKIM. Nó cho mailbox provider biết phải xử lý thế nào khi email dùng domain của bạn nhưng không vượt qua xác thực.
Một record DMARC cơ bản có dạng:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Trong đó:
v=DMARC1là phiên bản DMARC.p=nonelà chính sách chỉ theo dõi, chưa chặn.rualà địa chỉ nhận báo cáo tổng hợp.ruflà báo cáo forensic, hiện không phải provider nào cũng gửi.pctlà tỷ lệ áp dụng chính sách.
Bạn nên bắt đầu với p=none, sau đó đọc báo cáo một thời gian trước khi tăng lên quarantine hoặc reject. Nếu bật reject quá sớm, các hệ thống hợp lệ nhưng chưa cấu hình đúng có thể bị chặn.
Báo cáo DMARC cho bạn biết gì
DMARC aggregate report thường là file XML được gửi định kỳ. Nhìn thủ công khá khó đọc, nhưng nó chứa nhiều thông tin giá trị.
Các trường quan trọng:
- IP nào đang gửi mail với domain của bạn.
- Email có pass SPF không.
- Email có pass DKIM không.
- Alignment có đúng không.
- Mailbox provider đã xử lý theo chính sách nào.
- Số lượng email theo từng nguồn gửi.
Ví dụ, bạn có thể phát hiện một IP lạ đang gửi hàng nghìn email giả danh domain. Hoặc một dịch vụ bạn đang dùng gửi mail hợp lệ nhưng DKIM chưa align, khiến DMARC fail.
Nên làm gì khi thấy nguồn gửi lạ
Không phải IP lạ nào cũng là tấn công. Một số nền tảng gửi mail dùng nhiều dải IP, hoặc nhà cung cấp đổi hạ tầng mà bạn chưa cập nhật.
Bạn nên xử lý theo thứ tự:
- Xác định IP thuộc nhà cung cấp nào bằng WHOIS hoặc reverse DNS.
- Đối chiếu với danh sách dịch vụ đang dùng.
- Kiểm tra email mẫu nếu có.
- Nếu là dịch vụ hợp lệ, bổ sung SPF hoặc bật DKIM đúng cách.
- Nếu là nguồn giả mạo, giữ hoặc nâng chính sách DMARC.
- Theo dõi vài chu kỳ báo cáo trước khi chuyển sang
p=reject.
Nếu bạn dùng nhiều hệ thống gửi mail, nên lập bảng inventory gồm domain, subdomain, dịch vụ gửi, selector DKIM và người phụ trách. Tài liệu này giúp tránh tình trạng “không ai biết mail đó gửi từ đâu”.
Kiểm tra tên miền có nằm trong danh sách đen
Blacklist là danh sách các IP hoặc domain bị đánh dấu do gửi spam, phát tán malware, có hành vi đáng ngờ hoặc bị khai thác. Khi bị liệt kê, email của bạn có thể bị reject, đưa vào spam hoặc bị trì hoãn.
Không phải mọi blacklist đều có cùng mức ảnh hưởng. Một số danh sách rất quan trọng, một số danh sách ít mailbox provider sử dụng.
Cần kiểm tra IP hay domain
Bạn nên kiểm tra cả hai.
IP blacklist thường ảnh hưởng trực tiếp đến mail server gửi đi. Nếu bạn dùng shared hosting hoặc SMTP dùng chung, IP có thể bị ảnh hưởng bởi người dùng khác.
Domain blacklist liên quan đến uy tín tên miền, link trong nội dung, hoặc domain từng bị dùng cho spam. Trường hợp này khó chịu hơn vì đổi IP chưa chắc giải quyết được.
Nếu bạn dùng email marketing hoặc SMTP bên thứ ba, hãy kiểm tra thêm domain tracking. Nhiều hệ thống dùng subdomain như mail.example.com, news.example.com hoặc track.example.com.
Cách xử lý khi bị blacklist
Đừng vội gửi yêu cầu delist ngay. Nếu nguyên nhân gốc chưa được xử lý, domain hoặc IP có thể bị list lại nhanh hơn.
Checklist xử lý:
- Tạm dừng chiến dịch gửi số lượng lớn.
- Kiểm tra log gửi mail trong 24 đến 72 giờ gần nhất.
- Tìm tài khoản bị lộ mật khẩu hoặc script bị hack.
- Quét mã độc website, đặc biệt là WordPress plugin/theme lạ.
- Kiểm tra queue mail trên server.
- Đổi mật khẩu SMTP, bật 2FA nếu có.
- Vá lỗi form liên hệ, endpoint gửi mail, API key.
- Sau khi sạch mới gửi yêu cầu delist.
Nếu bạn tự quản trị VPS hoặc mail server, nên kết hợp kiểm tra bảo mật hệ thống. Bạn có thể xem thêm các tài liệu vận hành máy chủ tại hướng dẫn VPS hoặc trung tâm tài liệu VSIS.
Lưu ý với shared hosting
Shared hosting có lợi thế dễ dùng, nhưng IP gửi mail có thể dùng chung. Nếu một website khác trên cùng IP gửi spam, email của bạn cũng có thể bị ảnh hưởng.
Giải pháp tuỳ mức độ quan trọng:
- Dùng SMTP chuyên dụng thay vì mail PHP mặc định.
- Tách email giao dịch sang dịch vụ gửi riêng.
- Dùng subdomain riêng cho email marketing.
- Theo dõi blacklist định kỳ cho IP gửi.
- Không trộn email marketing với email giao dịch quan trọng.
Với hệ thống cần độ tin cậy cao như OTP, hoá đơn, thông báo thanh toán, bạn nên ưu tiên hạ tầng gửi mail có xác thực đầy đủ và log rõ ràng.
Theo dõi định kỳ thay vì kiểm một lần
Kiểm tra một lần chỉ cho bạn ảnh chụp tại thời điểm đó. Danh tiếng email thay đổi theo hành vi gửi, phản hồi người nhận, cấu hình DNS và cả tình trạng bảo mật hệ thống.
Một domain hôm nay sạch không có nghĩa tuần sau vẫn sạch. Chỉ cần một tài khoản SMTP bị lộ, một plugin WordPress bị hack hoặc một chiến dịch gửi sai tệp khách hàng, reputation có thể giảm rõ rệt.
Lịch kiểm tra đề xuất
Bạn có thể áp dụng lịch đơn giản sau:
| Tần suất | Việc cần làm | Ai nên làm |
|---|---|---|
| Hàng ngày | Xem bounce bất thường, complaint, queue mail | Người vận hành email |
| Hàng tuần | Kiểm tra blacklist, Google Postmaster, log gửi | Kỹ thuật hoặc marketing ops |
| Hàng tháng | Rà soát SPF, DKIM, DMARC, danh sách dịch vụ gửi | Sysadmin hoặc owner |
| Sau mỗi thay đổi DNS | Kiểm tra lại bằng dig, tool DNS và gửi mail test | Người thực hiện thay đổi |
| Sau mỗi chiến dịch lớn | Xem tỷ lệ mở, bounce, spam complaint | Marketing hoặc MMO team |
Nếu bạn gửi số lượng lớn, hãy lưu chỉ số theo thời gian. Khi có vấn đề, dữ liệu lịch sử giúp bạn biết danh tiếng giảm từ ngày nào và sau sự kiện nào.
Những chỉ số nên lưu
Không cần quá phức tạp, nhưng nên có tối thiểu:
- Tổng số email gửi mỗi ngày.
- Bounce rate.
- Spam complaint rate.
- Tỷ lệ vào inbox nếu có seed test.
- Tỷ lệ mở và click.
- Số lượng DMARC fail.
- Nguồn IP gửi chính.
- Trạng thái blacklist.
Bạn có thể dùng Google Sheet, dashboard nội bộ hoặc công cụ monitoring. Điều quan trọng là có người xem và có ngưỡng cảnh báo.
Cảnh báo tự động nên đặt
Nếu có điều kiện, hãy đặt alert cho các tình huống sau:
- Bounce tăng đột biến.
- Queue mail tăng bất thường.
- Số lượng gửi vượt mức bình thường.
- SPF, DKIM hoặc DMARC fail tăng.
- Có IP gửi mới xuất hiện trong DMARC report.
- Domain hoặc IP bị blacklist.
- Tỷ lệ spam complaint vượt ngưỡng.
Alert không cần quá nhiều, nhưng phải đủ sớm. Khi Gmail hoặc Outlook đã giảm trust mạnh, việc phục hồi thường mất nhiều ngày hoặc nhiều tuần.
Dấu hiệu sớm cho thấy danh tiếng đang xuống
Danh tiếng email thường không sụp ngay lập tức. Nó giảm dần qua nhiều tín hiệu nhỏ, nếu để ý bạn có thể xử lý trước khi bị ảnh hưởng nặng.
Mail bị delay nhiều hơn
Nếu log SMTP thường xuyên có trạng thái tạm hoãn như 4xx, đó là dấu hiệu cần kiểm tra. Mailbox provider có thể đang rate limit vì nghi ngờ lưu lượng gửi.
Bạn nên xem:
- Delay tập trung ở provider nào.
- Delay xảy ra sau chiến dịch nào.
- Có tăng volume đột ngột không.
- Có nhiều địa chỉ không tồn tại không.
Bounce rate tăng
Bounce có hai loại chính là hard bounce và soft bounce. Hard bounce do địa chỉ không tồn tại hoặc bị từ chối vĩnh viễn, còn soft bounce thường là lỗi tạm thời.
Nếu hard bounce tăng, danh sách email của bạn có vấn đề. Nếu soft bounce tăng ở một provider cụ thể, có thể reputation với provider đó đang xấu đi.
Tỷ lệ mở giảm bất thường
Open rate không còn chính xác tuyệt đối do cơ chế bảo vệ quyền riêng tư, nhưng vẫn có giá trị tham khảo. Nếu tỷ lệ mở giảm mạnh cùng lúc complaint hoặc bounce tăng, khả năng cao email đang vào spam nhiều hơn.
Bạn nên so sánh theo từng nhóm người nhận. Ví dụ Gmail giảm nhưng Yahoo bình thường, nghĩa là vấn đề có thể nằm ở reputation với Gmail.
Nhiều người báo không nhận được mail
Đừng bỏ qua phản hồi thủ công từ khách hàng. Nếu nhiều người cùng báo không nhận được OTP, reset password hoặc invoice, cần kiểm tra ngay header, log SMTP và trạng thái gửi.
Hãy yêu cầu người nhận kiểm tra spam, nhưng đừng dừng ở đó. Việc nhiều người phải tìm mail trong spam là tín hiệu xấu.
Xuất hiện nguồn gửi lạ trong DMARC
Đây là dấu hiệu quan trọng. Nếu DMARC report xuất hiện IP không thuộc hệ thống của bạn, cần xác minh ngay.
Nguồn gửi lạ có thể là:
- Dịch vụ hợp lệ nhưng chưa được ghi nhận.
- Script trên website bị khai thác.
- Tài khoản SMTP bị lộ.
- Kẻ xấu đang spoof domain.
- Forwarder làm SPF fail nhưng DKIM vẫn pass.
Không nên xoá hoặc bỏ qua báo cáo chỉ vì “mail vẫn gửi được”. DMARC là lớp quan sát giúp bạn phát hiện rủi ro trước khi người dùng bị ảnh hưởng.
Sai lầm phổ biến
Chỉ kiểm tra khi đã có sự cố
Nhiều đội chỉ kiểm tra email khi khách hàng báo lỗi. Lúc đó reputation có thể đã giảm, campaign đã hỏng, hoặc domain đã bị lợi dụng.
Cách tốt hơn là kiểm tra theo lịch. Chỉ cần 15 đến 30 phút mỗi tuần cũng giúp phát hiện sớm nhiều lỗi.
Có SPF là nghĩ đã đủ
SPF chỉ xác nhận IP gửi có được phép gửi thay mặt domain hay không. Nó không thay thế DKIM và DMARC.
Một hệ thống gửi mail khoẻ nên có cả ba:
- SPF đúng và không vượt giới hạn lookup.
- DKIM ký hợp lệ.
- DMARC có chính sách phù hợp và nhận báo cáo.
Tạo nhiều record SPF
Tên miền chỉ nên có một record SPF. Nếu có hai record SPF dạng v=spf1, nhiều receiver sẽ coi SPF là lỗi.
Thay vì tạo nhiều record, hãy gộp các nguồn gửi vào một record. Ví dụ:
v=spf1 include:_spf.google.com include:spf.example-smtp.com -all
Nhớ kiểm tra giới hạn 10 DNS lookup của SPF. Nếu dùng quá nhiều include, SPF có thể fail dù cú pháp nhìn có vẻ đúng.
Bật DMARC reject quá sớm
Chính sách reject rất hữu ích khi bạn đã kiểm soát nguồn gửi. Nhưng nếu bật quá sớm, mail hợp lệ từ CRM, website, plugin hoặc helpdesk có thể bị chặn.
Lộ trình an toàn thường là:
p=noneđể quan sát.- Sửa toàn bộ nguồn gửi hợp lệ.
- Chuyển sang
p=quarantinevớipctthấp. - Tăng dần tỷ lệ.
- Chuyển sang
p=rejectkhi dữ liệu ổn định.
Dùng chung domain cho mọi loại email
Email giao dịch và email marketing có rủi ro khác nhau. Nếu bạn gửi campaign lớn tới danh sách kém chất lượng bằng cùng domain gửi OTP, email quan trọng cũng có thể bị ảnh hưởng.
Cách tách hợp lý:
- Domain chính cho giao tiếp doanh nghiệp.
- Subdomain cho email giao dịch, ví dụ
notify.example.com. - Subdomain riêng cho marketing, ví dụ
news.example.com. - Tracking domain riêng, có kiểm soát.
Không kiểm tra header email thực tế
Cấu hình DNS nhìn đúng chưa chắc email thực tế đã pass. Bạn cần gửi email test đến Gmail hoặc Outlook, sau đó xem header.
Trong Gmail, bạn có thể chọn “Show original” để xem SPF, DKIM, DMARC. Nếu thấy pass nhưng mail vẫn vào spam, hãy kiểm tra thêm nội dung, link, danh sách người nhận và lịch sử gửi.
Câu hỏi thường gặp
Bao lâu nên kiểm tra sức khoẻ tên miền gửi mail một lần?
Nếu gửi ít, bạn nên kiểm tra ít nhất mỗi tháng và sau mỗi lần thay đổi DNS hoặc đổi dịch vụ gửi mail. Nếu gửi nhiều, nên kiểm tra hàng tuần, riêng bounce và complaint nên xem hằng ngày.
Với domain quan trọng cho OTP, hoá đơn hoặc thông báo tài khoản, nên có cảnh báo tự động cho blacklist, DMARC fail và volume bất thường.
SPF, DKIM, DMARC cái nào quan trọng nhất?
Cả ba đều quan trọng và bổ sung cho nhau. SPF kiểm tra server gửi, DKIM xác minh chữ ký nội dung, còn DMARC kiểm tra alignment và đưa ra chính sách xử lý.
Nếu chỉ chọn thứ tự triển khai, bạn nên làm SPF và DKIM trước, sau đó bật DMARC ở mức p=none để quan sát. Khi chắc chắn các nguồn gửi hợp lệ đã pass, mới nâng chính sách.
Domain mới mua có gửi mail marketing ngay được không?
Không nên gửi volume lớn ngay. Domain mới chưa có lịch sử tốt, nếu gửi đột ngột hàng nghìn email, mailbox provider dễ nghi ngờ.
Bạn nên warm up dần, bắt đầu với danh sách chất lượng, tăng volume từ từ và theo dõi bounce, complaint, open rate. Đồng thời đảm bảo SPF, DKIM, DMARC đã đúng trước khi gửi.
Bị blacklist có cần đổi domain không?
Không nên đổi domain ngay nếu chưa biết nguyên nhân. Nếu website bị hack hoặc danh sách email bẩn, đổi domain chỉ làm vấn đề lặp lại.
Trước tiên hãy dừng gửi, kiểm tra log, xử lý nguồn spam, làm sạch danh sách và gửi yêu cầu delist. Chỉ cân nhắc đổi domain khi domain bị hỏng reputation nặng, kéo dài và có kế hoạch chuyển đổi cẩn thận.
DMARC report gửi về toàn file XML, đọc thế nào?
Bạn có thể dùng công cụ phân tích DMARC để chuyển XML thành bảng dễ đọc. Nếu chưa dùng tool, hãy tập trung vào IP gửi, kết quả SPF, DKIM, DMARC và số lượng email.
Mục tiêu ban đầu không phải đọc từng dòng XML, mà là trả lời được câu hỏi: ai đang gửi mail bằng domain của bạn, nguồn nào hợp lệ, nguồn nào đáng ngờ.
Mail đã pass SPF, DKIM, DMARC mà vẫn vào spam là vì sao?
Xác thực đúng chỉ là điều kiện nền tảng. Mail vẫn có thể vào spam nếu nội dung kém, danh sách người nhận không chất lượng, tỷ lệ complaint cao, gửi quá dày hoặc link trong email có reputation xấu.
Bạn cần xem cả header, nội dung, lịch sử gửi, tương tác người nhận và trạng thái reputation trong postmaster tools.
Tóm tắt nhanh
- Kiểm tra sức khoẻ tên miền gửi mail nên làm định kỳ, không chỉ khi có sự cố.
- SPF, DKIM và DMARC là bộ ba nền tảng để xác thực email và chống giả mạo.
- DMARC report giúp bạn biết ai đang gửi mail bằng domain của bạn, kể cả nguồn giả mạo.
- Cần kiểm tra cả domain blacklist và IP blacklist, đặc biệt nếu dùng shared hosting hoặc SMTP dùng chung.
- Nên tách email giao dịch và email marketing bằng subdomain để giảm rủi ro lan truyền reputation xấu.
- Dấu hiệu sớm cần chú ý gồm delay, bounce tăng, open rate giảm, complaint tăng và nguồn gửi lạ trong DMARC.
- Đừng bật DMARC
rejectquá sớm, hãy quan sát vớip=none, sửa lỗi rồi nâng chính sách từng bước.



