DMARC -- understanding aggregate reports
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.
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.