3

I just started receiving DMARC aggregate reports. I am trying to understand what it means for a Source IP to fail SPF. Does this mean that the domain that failed the SPF tried to send an email on behalf of my domain? (essentially spoof my domain?). If that is not correct, then is there a way to use this report to find out which domains are sending email on behalf of my domain?

Thanks

Dave
  • 31
  • 1

3 Answers3

1

When setting up the SPF policy you are basically listing out the domains, subdomains and IP addresses that are allowed to send email for your domain. When the aggregate report states that the source IP address failed, it means that the mail was received from an IP address that did not appear in the list of IP addresses that are authorized to send email for your domain. So, as you said, somebody tried to spoof your domain name in the email, but SPF caught it because the IP address from which the mail came was not authorized to send email for your domain. It is most probably spam.

Quickmist
  • 19
  • 2
1

To answer you question: DMARC is designed not only to make sure spoofers are unable to use your domain in an unauthorized way, but also allow authorized senders to show that they are legit.

SPF can fail even on legitimate emails because of a number of reasons. The most common being forwarding.

Background: The DMARC report contains several sections for each record. One is the <policy_evaluated>, which tells you how well the sender authenticated in alignment with your domain, used in the header_from address.

Then there is the section <auth_results>, which will include an <spf> section as well and possibly a <dkim> section. Here the SPF result may even be pass while the policy evaluated result for SPF may fail, meaning the sender successfully authenticated the domain used in the bounce / envelope_from address, which can be different from the header_from address which the recipient is shown in the email client.

A common scenario in which you'll see failed SPF authentication (in both policy_evaluated and auth_results) on legit emails, is forwarding. If the bounce / envelope from address is not rewritten while forwarding, the forwarding server's IP address will likely not be present in your SPF record.

In this case DKIM is a more resilient authentication mechanism. It survives forwarding as long as the signed header fields are left untouched.

Here is an example aggregate report where fwd.me forwarded an email from example.com while rewriting the bounce address to their domain, on which consequently the SPF check passed, because the sending IP 4.4.4.4 was included in the SPF record for fwd.me. The bounce / envelope_from domain is not aligned with the header_from domain and so it fails the DMARC check for SPF. Because the original DKIM signing survived the forwarding, the email was not rejected.

<record> <row> <source_ip>4.4.4.4</source_ip> <count>44</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim> <domain>example.com</domain> <result>pass</result> </dkim> <spf> <domain>fwd.me</domain> <result>pass</result> </spf> </auth_results> </record>

Reinto
  • 223
  • 1
  • 6
0

As @Quickmist says the email in the report failed SPF as it was recived from an address not in your SPF record. If you look in the Aggregate report it will tell you where it was recieved from:

<record> 
 <row> 
  <source_ip> (where it came from)</source_ip>
 ...
 </row>
 ...
 <auth_results>
  <spf>
   <domain> (your domain) </domain>
   <result>fail</result>
  </spf>
 ...
 </auth_results>
</record>

by looking up the Source IP you can work out if it should be added to your SPF record, or if it is somone trying to spoof your domain.

EnviableOne
  • 157
  • 8