DMARC -- understanding aggregate reports

Question

TL;DR
I get a lot of DMARC feedback from accounts/websites I don't have contact with and want some clarity on if I should be taking any action or if these feedback reports are informative of any serious issues?

I run a WHM server and use SPF and DKIM (and _DMARC), all emails are sent from the same domain server.

An example DNS setup for my _DMARC (and DKIM and SPF):

mydomain.co.uk     14400 IN TXT "v=spf1 mx a ip4:11.22.33.44 ip4:11.22.33.55 ~all"

default._domainkey 14400 IN TXT "v=DKIM1; k=rsa; p=<code>;

_dmarc             14400 IN TXT "v=DMARC1; p=quarantine; sp=none; 
                                rua=mailto:[email protected]!90m; 
                                ruf=mailto:[email protected]; 
                                rf=afrf; pct=100; ri=86400"

and as far as I can tell this is set up and works as expected.

however, I get quite a few automatic messages from various domains across the world wide web, which have nothing to do with my domain. I am the only person using emails from my domain, no one else is emailing from my domain.

For example, this morning I received a DMARC aggregate report from Comcast stating:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
    <version>1.0</version>
    <report_metadata>
        <org_name>comcast.net</org_name>
        <email>[email protected]</email>
        <report_id>v1-1483425166-mydomain.co.uk</report_id>
        <date_range>
            <begin>1483315200</begin>
            <end>1483401600</end>
        </date_range>
    </report_metadata>
    <policy_published>
        <domain>mydomain.co.uk</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>quarantine</p>
        <sp>none</sp>
        <pct>100</pct>
        <fo>0</fo>
    </policy_published>
    <record>
        <row>
            <source_ip>72.167.218.164</source_ip>
            <count>1</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>fail</dkim>
                <spf>fail</spf>
            </policy_evaluated>
        </row>
        <identifiers>
            <header_from>mydomain.co.uk</header_from>
        </identifiers>
        <auth_results>
            <spf>
                <domain>bounce.secureserver.net</domain>
                <scope>mfrom</scope>
                <result>pass</result>
            </spf>
        </auth_results>
    </record>
</feedback>

No I don't recognise any of the details set out here aside from my domain, the IP address give in <source_ip> is not my IP address and I am unaware of having any contact at all with Comcast.

Basically, I get quite a lot of these notices and I can't find any feedback as to tell me if they're just informative and can be forgotten about (in which case what's the point of them?) or if I can do something with my server to improve the failings that the notice informs me of.

SO:

• Are these reports something that can be acted upon?
• How Should DMARC reports such as these be acted upon at my end?
• Are these reports indicators of any form of account compromise
• can/does the number of these reports [potentially] reflect badly upon my domain name to the rest of the 'web?

It may be worth noting I suspect the answer to the last two bullets to both be "No", But I'm not an expert on these.

---

I have already read this post as well as the DMARC FAQ and this topic, but there's not much info. on how we're meant to react to aggregate reports. I am aware that "failed" DMARC reports can be caused by mail forwarding programs, although I hope to negate this possibility with my SPF ~all.

Overall I think I shouldn't need to worry about these reports but I would like a second opinion due to what I perceive as the regularity and (I think) relatively significant number of aggregate reports I'm receiving.

Answer 1

Are these reports something that can be acted upon?

Yes, but most of the information will hopefully be confirming all is OK with your configuration.

How Should DMARC reports such as these be acted upon at my end?

Typically these reports would be processed by an automated system which turns this data into pretty reports with graphs, statistics and issues requiring attention. If you've not seen this type of system then perhaps you should check out dmarcian.com which provides a free basic service which would help you get started and understand what you can and can't do or see. For this to work you would have to use an email address they supply you in your DMARC record.

Are these reports indicators of any form of account compromise?

No, they are just reports of all activity from DMARC-capable servers that have processed messages claiming to be from your domain name, essentially telling you they got a message, where it came from and what they did with it and why.

Can/does the number of these reports [potentially] reflect badly upon my domain name to the rest of the web?

No, these reports are only sent to the email address supplied in the DMARC record and not published to the web. The only real potential for a negative impact is if you setup your SPF and/or DKIM wrong and end up getting lots of messages rejected/blocked, but then at least with DMARC you would know about it.

Answer 2

As a reply to your example: Many DMARC failures can be traced back to forwarding and mailing lists, for example with Google Groups for Business. However in the report it is showing us the email was sent from a host, part of secureserver.net. The SPF was checked on the return-path of bounce.secureserver.net and passed.

Most likely this was a bounce message from your anti-SPAM or inbound SMTP service, sent back to the original email sender, that tried to send you an email. The bounce will be sent on your behalf with an altered return-path. SecureServer.net is part of GoDaddy, are you hosting with GoDaddy or affiliate?

As a reply to your statement:

I am aware that "failed" DMARC reports can be caused by mail forwarding programs, although I hope to negate this possibility with my SPF ~all.

DMARC will only evaluate to Pass if either SPF or DKIM checks result in a pass, in alignment with your From address domain. So I'm not sure what you mean with that the ~all negates the problem.

Forwarders usually rewrite the return-path to their own bounce address, making it fail alignment with the originating domain. Th ARC protocol is still in draft, but should negate this forwarding problem for SPF alignment with DMARC for trusted forwarders. Also, DKIM signatures most often remain in tact, unless signed fields are modified by the forwarder. So DMARC can still pass based on DKIM.

One last thing:

In your DMARC policy, you publish an sp=none policy for all subdomains, which would otherwise inherit the p=quarantine policy. This results in that anyone out to spoof your domain can simply choose any subdomain to use, for example app.mydomain.co.uk. Perhaps this is a desired setup, but I just wanted to point it out.

Answer 3

You may parse and display DMARC reports via this tools:

• https://github.com/techsneeze/dmarcts-report-parser
• https://github.com/techsneeze/dmarcts-report-viewer

Also see https://dmarc.org/resources/deployment-tools/, the "Report Parsing and Display" section.