DMARC: Không thành công SPF, Pass DKIM, IP nguồn: không phải của tôi!

8

Đây là một trong những kỳ lạ:

<record>    
    <row>   
      <source_ip>65.20.0.12</source_ip> 
      <count>2</count>  
      <policy_evaluated>    
        <disposition>none</disposition> 
        <dkim>pass</dkim>   
        <spf>fail</spf> 
      </policy_evaluated>   
    </row>  
    <identifiers>   
      <header_from>mydomain.co.uk</header_from> 
    </identifiers>  
    <auth_results>  
      <dkim>    
        <domain>mydomain.co.uk</domain> 
        <result>pass</result>   
      </dkim>   
      <spf> 
        <domain>mydomain.co.uk</domain> 
        <result>fail</result>   
      </spf>    
    </auth_results> 
  </record>

Tôi sử dụng kết hợp các máy chủ của riêng tôi và google để gửi thư. IP nguồn không phải là của tôi hay của Google - làm thế nào họ có thể vượt qua DKIM?

Các báo cáo đến từ Yahoo. IP dường như là một máy chủ thư cho btiNET.com được quản lý bởi cpcloud.co.uk (Critical Path Inc.) - tôi biết có một số điều kỳ lạ giữa chúng trong quá khứ với SPF, v.v. ?

IP chỉ có trong các báo cáo DMARC của Yahoo. Ngày tôi nhận được báo cáo là 1 ngày trước các email được gửi đến người dùng bti Internet.

Có đơn giản như tôi đang gửi email đến tài khoản bt không, nó có được chuyển tiếp / chuyển hướng / phẫn nộ đến yahoo không và điều đó đánh dấu sự thất bại?

yahoo spf dkim

— nedge2k
nguồn

1

Đừng quên rằng Internet BT đã thuê ngoài việc cung cấp email của họ cho Yahoo. Điều đó có thể giải thích hành vi.

— Andrew Leach

Tôi cũng thấy vấn đề tương tự trên một số tên miền của mình và không biết tại sao cpcloud.co.uk lại xuất hiện dưới dạng nguồn. Tôi tự hỏi liệu có lẽ họ đã ủy quyền lưu lượng SMTP không được mã hóa từ người dùng đằng sau các kết nối băng thông rộng BT nhà. Thật không may, phần lớn các nhà cung cấp dịch vụ lưu trữ email cho phép cả khách hàng truy cập được mã hóa và không được mã hóa, để lại tự động phát hiện phần mềm / thiết bị / thiết bị của người dùng cuối thường chọn cấu hình không được mã hóa.

— richhallstoke

6

Xin lỗi, quên đăng giải pháp này!

Vì vậy, đó là một điều chuyển tiếp như nghi ngờ nhưng quy tắc SPF của tôi trong DNS quá nghiêm ngặt và không cho phép chuyển tiếp - do đó SPF không thành công. Thay đổi từ -all thành ~ tất cả đã sắp xếp nó.

— nedge2k
nguồn

Tôi có bản ghi SPF TXT được đặt thành ~ tất cả, nhưng vẫn nhận được cùng một lỗi dmarc từ yahoo. "v = spf1 bao gồm: _spf.google.com ~ tất cả"

— Swatantra Kumar

5

Hai điều cần xem xét:

Chuyển tiếp email xảy ra trên internet. Đây có thể là trường hợp ai đó chạy máy chủ @ example.org của riêng họ nhưng sau đó chuyển tiếp tất cả email đến Yahoo (cuối cùng hạ cánh trong hộp thư @ yahoo.com). Mọi người làm điều này mọi lúc - vì họ thích giao diện người dùng của điểm đến cuối cùng tốt hơn hoặc dễ quản lý hơn.
DKIM có thể tồn tại chuyển tiếp nếu nội dung của tin nhắn vẫn còn nguyên. Không có gì lạ khi thấy các tin nhắn chuyển qua DKIM chảy ra từ những nơi kỳ lạ trên internet trước khi được DMARC báo cáo.

Trong ví dụ của bạn, sự hiện diện của chữ ký chuyển DKIM từ một nguồn IP không xác định là một tín hiệu rất mạnh cho thấy hàng dữ liệu này thể hiện email chuyển tiếp.

— Tim Draegen
nguồn

0

Tôi có điều này cũng như với một trong những khách hàng của tôi. Tôi có quyền kiểm soát máy chủ thư miền (Exchange) (với DKIM được thêm bởi dkim-exchange) và máy chủ thông minh (Postfix) và chúng tôi nhận được một hoặc hai email mỗi ngày luôn đến qua máy chủ 65.20.0.12. Tôi đã kiểm tra các quy tắc và nhật ký và không ai trong nội bộ chuyển tiếp tin nhắn của họ đến bất cứ đâu, vì vậy điều duy nhất tôi có thể nghĩ là đây là một email gửi đến một khách hàng / nhà cung cấp đang gửi tin nhắn từ tài khoản BT của họ tới Yahoo của họ tài khoản, có thể mà không biết. Dù bằng cách nào, tôi vẫn để SPF cho tên miền như hiện tại và để Yahoo trả lại các email, vì có thể theo cách đó cuối cùng sẽ có người chú ý và hỏi tôi.

— Marco
nguồn