2

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.

enter image description here

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!

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.

  • Thanks. So 2,3,4 were maybe just forwarded automatically to a different address on the recipient's side? We shouldn't care about those, right? For example 1, was that originally sent from a Google server and not ours? I don't believe we send anything that way. Is it good/bad/correct/incorrect? – mikato Mar 15 '18 at 19:32
  • @mikato I don't see antthing to worry about in these messages, Example 1 may be from an application which knows the email address of someone in your domain, who sent a notification of some kind to another email address handled by the Google email servers. (It would be better if this was a Reply-To address, with an application (no-reply) address as the sender. (Its better than using the recipient as the sender, which is all too common.) – BillThor Mar 17 '18 at 5:03
  • Thanks Bill. Here's another. IP 209.235.156.168 (resolves to carrierzone.com), 25 count, both DKIM and SPF fail. That seems to be related to Earthlink. So is it maybe forwarding emails from us in some way and leaving off the DKIM signing? We do email to people with earthlink.net addresses so could they be legit messages that would be stopped if we turned on reject? Thanks – mikato Mar 30 '18 at 22:25
  • @mikato It could be a forwarder, but other than its name and rDNS, the server fails all my tests for an email server. Additionally, it does not accept mail traffic. It is not listed an email server in the SPF data for earthlink.net. – BillThor Mar 30 '18 at 23:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.