Các quản trị viên của Email riêng nghiêm trọng cho doanh nghiệp Nó thường phải đối mặt với rất nhiều vấn đề và thách thức. Từ sóng của THƯ RÁC bị chặn bởi các bộ lọc cụ thể, sự bảo mật của thư từ Trong máy chủ email cục bộ và máy chủ từ xa, Cấu hình Và Giám sát các dịch vụ SMTPThì NHẠC POPThì Imap, cộng với nhiều và nhiều chi tiết khác về Cấu hình SPF, DKIM và DMARC Để tuân thủ các thực tiễn tốt của vận chuyển email an toàn.
nội dung
Nhiều vấn đề của Lô hàng tin nhắn e-mail hoặc Người nhận hàng đến / từ các nhà cung cấp ATI, xảy ra do cấu hình không chính xác của khu vực DNS, những gì về dịch vụ e-mail.
Để từ một tên miền, các email có thể được gửi, nó phải là Máy chủ trên máy chủ email được cấu hình đúng, một lần nữa Tên miền để có các khu vực DNS vì SPFThì MXThì DMARC VÀ Dkim đặt chính xác trong trình quản lý DNS txt của miền.
Trong bài viết hôm nay, chúng tôi sẽ dừng lại ở một vấn đề khá phổ biến Máy chủ e-mail riêng cho doanh nghiệp. Không thể gửi tin nhắn e-mail đến tài khoản Gmail, Yahoo! hoặc iCloud.
Các tin nhắn được chuyển đến @gmail.com được tự động bị từ chối. “Gửi thư không thành công: trả lại tin nhắn cho người gửi”
Gần đây tôi đã gặp một vấn đề trên một khu vực e-mail của một công ty, từ đó tin nhắn e-mail đến các công ty và cá nhân khác được gửi thường xuyên, một số trong số họ có địa chỉ @gmail.com. Tất cả các tin nhắn được chuyển đến tài khoản Gmail ngay lập tức trả lại cho người gửi. “Gửi thư không thành công: trả lại tin nhắn cho người gửi”.
Thông báo lỗi được trả về máy chủ email trên Exim Trông như sau:
1nSeUV-0005zz-De ** [email protected] R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [142.x.x.27] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked. Please visit\n550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.26 information. d3-20020adff843000000b001f1d7bdaeb7si6107985wrq.510 - gsmtpTrong kịch bản này không có một cái gì đó rất nghiêm trọng, chẳng hạn như Bao gồm tên miền của vận chuyển hoặc người gửi IP trong danh sách thư rác toàn cầu hoặc o Lỗi cấu hình chính các dịch vụ e-mail trên Sevrer (Exim).
Ngay cả khi nhiều người khi tôi thấy tin nhắn này đi cùng với suy nghĩ ngay lập tức để spam hoặc lỗi cấu hình SMTP, vấn đề được tạo ra bởi khu vực DNS txt của miền. Hầu hết thời gian, DKIM không tồn tại được cấu hình trong khu vực DNS hoặc không được thông qua chính xác trong Trình quản lý DNS. Thường gặp phải vấn đề này cho những người sử dụng Cloudflare Là người quản lý DNS và quên vượt qua DNS txt: mail._domainkey .Dkim) DMARC Và SPF.
Khi anh ấy nói với chúng tôi trong thông điệp từ chối từ Gmail, tính xác thực và xác thực của người gửi, đã thất bại. “Thông báo này không có thông tin xác thực hoặc không thành công.”. Điều này có nghĩa là tên miền không có cấu hình DNS TXT để đảm bảo độ tin cậy cho máy chủ e-mail của người nhận. Gmail, trong kịch bản của chúng tôi.
Khi thêm một tên miền web với dịch vụ e-mail hoạt động trên CPANEL hoặc Vestacp, các tệp trong khu vực DNS của miền tương ứng cũng tự động được tạo. Khu vực DNS chứa bao gồm cấu hình dịch vụ e-mail: MXThì SPFThì DkimThì DMARC.
Trong tình huống chúng tôi chọn tên miền sẽ ở trên người quản lý DNS Cloudflare, khu vực DNS của tài khoản lưu trữ của miền tương ứng, phải được sao chép trên đám mây, để khu vực e-mail hoạt động chính xác. Đó là vấn đề trong kịch bản trên. Trong trình quản lý DNS TERT, không có đăng ký DKIM, mặc dù cô tồn tại trên trình quản lý DNS của máy chủ cục bộ.
DKIM là gì và tại sao việc từ chối e-mail là gì nếu chúng ta không có tính năng này trên e-mail?
DomainKeys được xác định thư (DKIM) Nó là một giải pháp tiêu chuẩn để xác thực tên miền e-mail, thêm vào Chữ ký kỹ thuật số cho mỗi tin nhắn được vận chuyển. Các máy chủ đích có thể kiểm tra qua DKIM nếu tin nhắn đến từ luật của người gửi chứ không phải từ một khu vực khác sử dụng danh tính của người gửi làm mặt nạ. Về ý nghĩa của tất cả, nếu bạn có tên miền ABCDQWERTY.com Không có DKIM, tin nhắn e-mail từ các máy chủ khác có thể được vận chuyển bằng tên miền của bạn. Đó là nếu bạn muốn có một vụ trộm danh tính, theo thuật ngữ kỹ thuật được gọi Email giả mạo.
Một kỹ thuật phổ biến khi các tin nhắn e-mail của e-mail được gửi đi lừa đảo Và thư rác.
Ngoài ra thông qua DKIM có thể được đảm bảo rằng, Nội dung tin nhắn không được thay đổi sau khi được gửi bởi người gửi.
Có DKIM đặt chính xác trên các severis máy chủ của hệ thống e-mail và trong khu vực DNS, khả năng tin nhắn của bạn sẽ đến được với người nhận hoặc không đến.
Một ví dụ về DKIM là:
mail._domainkey: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGfdSIb3DQEBAQUAA4GN ... ocqWffd4cwIDAQAB"Tất nhiên giá trị DKIM có được bởi Thuật toán RSA CRIPATRE Nó là duy nhất cho mỗi tên miền và có thể được tái sinh từ máy chủ máy chủ của dịch vụ e-mail.
Đã cài đặt DKIM và đặt chính xác DNS txt Người quản lý, rất có thể giải quyết vấn đề của các tin nhắn được trả về tài khoản Gmail. Ít nhất là cho lỗi “Gửi thư không thành công”:
“Lỗi SMTP từ máy chủ thư từ xa sau khi kết thúc dữ liệu: 550-5.7.26 Thông báo này không có thông tin xác thực hoặc không thể kiểm tra xác thực n550-5.7.26. Để bảo vệ tốt nhất người dùng của chúng tôi khỏi spam, thông báo n550-5.7.26 đã bị chặn.”
Giống như một bản tóm tắt ngắn gọn, DKIM thêm một chữ ký kỹ thuật số cho mỗi tin nhắn được gửi, cho phép các máy chủ đích xác minh tính xác thực cho người gửi. Nếu tin nhắn đến từ công ty của bạn và địa chỉ của bên thứ ba đã không được sử dụng, để sử dụng danh tính của bạn.
Gmail (Google) Có thể Tự động từ chối tất cả các tin nhắn mà đến từ các lĩnh vực không có một ngữ nghĩa kỹ thuật số DKIM như vậy.
SPF là gì và tại sao nó quan trọng đối với việc giao hàng email an toàn là gì?
Giống như dkim, và SPF có mục đích ngăn chặn Mesajele lừa đảo Và Email giả mạo. Theo cách này, các tin nhắn được gửi đi sẽ không còn được đánh dấu là thư rác.
Khung chính sách của người gửi (SPF)Đây là một phương pháp xác thực tiêu chuẩn của miền mà từ đó các tin nhắn được gửi. Đầu vào SPF được đặt trong Người quản lý DNS TXT của miền của bạn và trong lối vào này sẽ được chỉ định tên miền, IP hoặc các khu vực có quyền gửi tin nhắn trong e-mail bằng tên miền hoặc tổ chức của bạn.
Một miền không có SPF có thể cho phép những người gửi thư rác gửi tin nhắn e-mail từ các máy chủ khác, Sử dụng làm mặt nạ của bạn tên miền của bạn. Bằng cách này, họ có thể lan truyền Thông tin sai hoặc Dữ liệu nhạy cảm có thể được yêu cầu Thay mặt tổ chức của bạn
Tất nhiên, tin nhắn có thể được gửi thay mặt bạn trên các máy chủ khác, nhưng chúng sẽ được đánh dấu là thư rác hoặc bị từ chối, nếu máy chủ hoặc tên miền đó không được chỉ định trong đầu vào SPF TXT của miền của bạn.
Giá trị SPF trong trình quản lý DNS trông giống như biểu mẫu:
@ : "v=spf1 a mx ip4:x.x.x.x ?all"Ở đâu “IP4” Đại diện cho IPv4 của máy chủ email của bạn.
Làm thế nào để chúng tôi đặt SPF cho nhiều khu vực hơn?
Nếu chúng tôi muốn cho phép các trường khác gửi tin nhắn email thay mặt cho khu vực của chúng tôi, chúng tôi sẽ chỉ định chúng có giá trị “include” trong spf txt:
v=spf1 ip4:x.x.x.x include:example1.com include:example2.com ~allĐiều này có nghĩa là từ tên của chúng tôi, miền e-mail có thể được gửi tin nhắn e-mail từ example1.com và example2.com.
Đó là một bản ghi rất hữu ích nếu chúng ta có một ví dụ Tạp chí trực tuyến trên địa chỉ “Ví dụ1.com“, nhưng chúng tôi muốn các tin nhắn từ cửa hàng trực tuyến đến khách hàng rời khỏi Địa chỉ miền công ty, đây là “Ví dụ.com“. TRONG SPF txt vì “Ví dụ.com”, rằng chúng ta cần chỉ định với IP và “Bao gồm: Ví dụ1.com”. Để các tin nhắn có thể được chuyển từ tên của tổ chức.
Làm thế nào để chúng tôi đặt SPF cho IPv4 và IPv6?
Chúng tôi có một máy chủ email cả với IPv4 cũng như với IPv6, điều rất quan trọng là cả hai IP đều được chỉ định trong SPF TXT.
v=spf1 ip4:196.255.100.26 ip6:2001:db8:8:4::2 ~allTiếp theo, sau “IP” Chỉ thị có thể được sử dụng “include” Để thêm các lĩnh vực được ủy quyền cho lô hàng.
Điều này có nghĩa là gì “~all“Thì “-all” Và “+all” ale spf?
Như tôi đã nói ở trên, nhà cung cấp (ISP) vẫn có thể nhận được tin nhắn e-mail thay mặt cho tổ chức của bạn. Ngay cả khi chúng được gửi từ miền hoặc IP không được chỉ định trong chính sách SPF. Nhãn “tất cả” Nói với các máy chủ đích làm thế nào để xử lý các tin nhắn này từ các lĩnh vực khác không được ủy quyền và gửi tin nhắn thay mặt cho bạn hoặc tổ chức.
~all : Nếu tin nhắn được nhận từ một miền không được liệt kê trong SPF TXT, các tin nhắn sẽ được chấp nhận trên máy chủ đích, nhưng chúng sẽ được đánh dấu là thư rác hoặc đáng ngờ. Các bộ lọc chống thư rác của các hoạt động tốt của người nhận sẽ phải chịu các bộ lọc chống thư rác.
-all : Là thẻ nghiêm ngặt nhất được thêm vào đầu vào SPF. Nếu tên miền không được liệt kê, tin nhắn sẽ được đánh dấu là trái phép và sẽ bị nhà cung cấp từ chối. Nó sẽ không được giao ngay cả trong thư rác.
+all : Rất hiếm khi được sử dụng và không được khuyến nghị, thẻ này cho phép người khác gửi tin nhắn e-mail thay mặt cho hoặc tổ chức của bạn. Hầu hết các nhà cung cấp tự động từ chối tất cả các tin nhắn e-mail đến từ các khu vực có SPF TXT “+all“. Chính xác là vì tính xác thực của người gửi không thể được xác minh, ngoại trừ sau khi kiểm tra “Tiêu đề email”.
Bản tóm tắt: Khung chính sách của người gửi (SPF) có nghĩa là gì?
Ủy quyền thông qua khu vực DNS TXT / SPF, IPS và tên miền có thể gửi tin nhắn email từ trường hoặc công ty của bạn. Đồng thời, nó áp dụng các hậu quả được áp dụng cho các tin nhắn được gửi từ các trường trái phép.
DMARC có nghĩa là gì và tại sao nó quan trọng đối với máy chủ e-mail?
DMARC .Báo cáo xác thực tin nhắn dựa trên tên miền và sự phù hợp) liên quan chặt chẽ đến các tiêu chuẩn chính sách SPF Và Dkim.
Dmarc este a hệ thống xác nhận hình thành để bảo vệ Tên miền e-mail của bạn của hoặc công ty của bạn, về các thực tiễn như giả mạo email và lừa đảo lừa đảo.
Sử dụng các tiêu chuẩn SPF (Khung chính sách của người gửi) và tiêu chuẩn DKIM (khóa miền được xác định) thêm một tính năng rất quan trọng. báo cáo.
Khi chủ sở hữu tên miền xuất bản DMARC trong khu vực DNS TXT, anh ta sẽ có được thông tin về người gửi tin nhắn e-mail thay mặt cho hoặc của công ty sở hữu tên miền được bảo vệ với SPF và DKIM. Đồng thời, những người nhận tin nhắn sẽ biết và làm thế nào các thực tiễn tốt này được theo dõi bởi chủ sở hữu của người gửi.
Tích hợp DMARC trong DNS TXT có thể là hình thức:
V=DMARC1; rua=mailto:[email protected]; ruf=mailto:[email protected]; p=none; sp=none; fo=0;Trong DMARC, bạn có thể đặt một số điều kiện để báo cáo các sự cố cũng như các địa chỉ e-mail để tiếp cận các phân tích và báo cáo. Nên sử dụng các địa chỉ e-mail chuyên dụng cho DMARC vì khối lượng tin nhắn nhận được có thể là đáng kể.
Thẻ DMARC có thể được đặt theo chính sách do bạn hoặc tổ chức áp đặt:
v – Phiên bản của giao thức DMARC hiện có. p – Áp dụng chính sách này khi bạn không thể kiểm tra DMARC cho tin nhắn email. Có thể có giá trị: “none“Thì “quarantine” hoặc “reject“. Nó được sử dụng “none” Để có được báo cáo về luồng tin nhắn và nguồn.rua – Đây là danh sách các URL mà ISP có thể gửi phản hồi ở định dạng XML. Nếu chúng tôi thêm địa chỉ email vào đây, liên kết sẽ có biểu mẫu: “rua=mailto:[email protected]” .ruf – Danh sách các URL mà ISP có thể gửi báo cáo về các sự cố và hành vi phạm tội mạng được thực hiện thay mặt cho tổ chức của bạn. Địa chỉ sẽ có biểu mẫu: “ruf=mailto:[email protected]“. rf – Định dạng báo cáo tội phạm mạng. Có thể là hình thức “afrf” hoặc “iodef“. pct – Cho biết nhà cung cấp Internet / ISP chỉ áp dụng chính sách DMARC cho một tỷ lệ phần trăm tin nhắn không thành công nhất định. Ví dụ, chúng ta có thể có: “pct=50%” hoặc chính sách “quarantine” Và “reject“. Sẽ không bao giờ được chấp nhận “none“. adkim – Cụ thể “Chế độ căn chỉnh” Đối với chữ ký kỹ thuật số DKIM. Điều này có nghĩa là chữ ký số của đầu vào DKIM với miền được kiểm tra. adkim có thể có các giá trị: r .Relaxed) hoặc s .Strict). aspf – Theo cách tương tự như trong trường hợp của adkim được chỉ định “Chế độ căn chỉnh” Cho SPF và hỗ trợ các giá trị tương tự. r .Relaxed) hoặc s .Strict). sp – Chính sách này áp dụng để cho phép các tên miền phụ xuất phát từ lĩnh vực tổ chức, sử dụng giá trị của miền. Điều này tránh việc sử dụng các chính sách riêng cho từng khu vực. Nó thực tế là một “thẻ đại diện” Đối với tất cả các loại phụ. ri – Giá trị này đặt khoảng thời gian mà tại đó các báo cáo XML sẽ được nhận cho DMARC. Hầu hết thời gian, báo cáo là tốt hơn để làm hàng ngày. fo – Tùy chọn cho báo cáo gian lận. “Tùy chọn pháp y“. Họ có thể có các giá trị “0” Để báo cáo sự cố khi thất bại cả SPF và DKIM hoặc giá trị “1” Đối với kịch bản trong đó SPF hoặc DKIM không tồn tại hoặc không kiểm tra.
Vì vậy, để chắc chắn rằng tin nhắn email hoặc công ty của bạn đến người nhận hộp thư đến, bạn cần tính đến ba tiêu chuẩn này của “Thực hành tốt cho các tin nhắn e-mail lô hàng“. DkimThì SPF Và DMARC. Tất cả ba tiêu chuẩn này có liên quan đến DNS TXT và có thể được quản lý bởi người quản lý DNS của trường.
1 suy nghĩ về "Cách chúng tôi định cấu hình khu vực DNS TXT cho SPF, DKIM và DMARC và cách chúng tôi tránh các tin nhắn email kinh doanh bị từ chối bởi Gmail – Gửi thư không thành công”