Checking DMARC Non-compliance, 4 Examples

Question

We have set up DMARC and have been getting reports (policy is still set as "none"). I loaded them up in the DMARC XML-to-Human Converter (dmarcian.com) and most look great and 100% compliance. But we have gotten some from Google that showed up as Forwarder and some of those did not have DMARC compliance. I want to figure out if some of those are legit and things we need to work on, or they are correctly identified as non-compliant and would be rejected if we set policy to "reject".

I see dmarcian.com shows them as Gmail / Apps Forwarding.

In the XML, I see policy_evaluated shows a pass/fail for DKIM And SPF. Also auth_results shows a result for both as well. What are each of these? Why are they different sometimes? Is there no overall DMARC compliance tag? Which ones indicate DMARC compliance... the policy_evaluated?

In the 3 examples below, the source_ip is not our mail server's IP like for the rest of them. I've found it's actually Google's IP on these, except Example 4..

Example 1 Here is one example that looks bad, right? fail, fail in policy_evaluated. I don't recognize the other domain at all, except gappssmtp.com must be Google Apps I'm guessing.

  <record>
    <row>
      <source_ip>209.85.220.69</source_ip>
      <count>24</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
        <reason>
          <type>local_policy</type>
          <comment>arc=pass</comment>
        </reason>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>someotherdomain-com.notourselector.gappssmtp.com</domain>
        <result>pass</result>
        <selector>notourselector</selector>
      </dkim>
      <spf>
        <domain>someotherdomain.com</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>

Example 2 How about this? The otherdomain I actually recognize is the same domain as someone that we email with currently. Does this mean that they are trying to send as our domain or what? Or they forwarded an email they originally received from us (explaining why DKIM passed). But why does it show up here? I saw another one like this with a different domain matching that of someone we email with as well.

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>7</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ourdomain.com</domain>
        <result>pass</result>
        <selector>ourselector</selector>
      </dkim>
      <spf>
        <domain>someotherdomain.com</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>

Example 3

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
        <reason>
          <type>local_policy</type>
          <comment>arc=pass</comment>
        </reason>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ourdomain.com</domain>
        <result>fail</result>
        <selector>ourselector</selector>
      </dkim>
      <spf>
        <domain>gmail.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

Example 4 I found this source_ip is associated with the domain that appears in the email address of someone we email with.

<record>
    <row>
      <source_ip>64.239.243.200</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ourdomain.com</domain>
        <result>pass</result>
        <selector>ourselector</selector>
      </dkim>
      <spf>
        <domain>ourdomain.com</domain>
        <result>neutral</result>
      </spf>
    </auth_results>
  </record>

Any help digesting these is greatly appreciated!

Answer 1

Congratulations on implementing DMARC. It looks like you are taking a measured approach.

It is not uncommon for people to use email addresses that are forwarded to real mail boxes. Google will be aware of the servers for some of these and may deliver them to the user's mailbox anyway. This is likely what happened with examples 2, 3, and 4. Over time you will see multiple records that are alike other than the report time.

Based om my records Google will report a reason of "forwarded" for mail it identifies as legitimately forwarded. Other domains may also report forwarded email as such, but I don't have any such reports.

If users have mail from their forwarder being incorrectly sent to spam, there are various options available. This is one case where they may want to whitelist your domain when recieved from their forwarder. The server should learn that you aren't sending spam if your mail gets refiled in the inbox repeatedly.

Some spammers will try to forge your identity in spite of DMARC. As DMARC is not yet frequently deployed, many mail servers will process email without reference to your policy. If they don't sanitize there recipient lists to remove addresses handled by providers that have implemented DMARC you will get reports like Example 1. (If you don't require the use of your authorized servers to send email from your domain, you can get reports like this.)

However, in this case example 1 appears to have originated within the Google network. DNS indicates the IP address belongs to Google. A whois lookup on the domain indicates its nameservers are in the domain "googledomains.com". The addition of a reason to the record indicates that there is a local policy that permits this email.

You may want to check the IP addresses that are reported against various DNS blacklists. They may also be listed in a DNS whitelist. If you store the data in a database, you may be able to automate the DNS lookups.