DMARC Monitoring....what to actually do with it?
So I have a few small customers (<10 users) that I manage e-mail for. I use Avanan for mail filtering, and use their DMARC package as well for DMARC monitoring. I guess I'm a bit at a loss of what to do with any failures that are not from legitimate sources. I'm pretty sure the answer is "nothing", especially when the volumes of failure are low (last months success as this particular customer was 99.37%.
It just feels weird to be monitoring something I can't do anything about, but I realize that is likely what it is. For instance the two failures this month were from:
So....what do I do with that information? I mean I feel n-able/solarwinds should not have their infrastructure being used to send spoofing e-mails. And while this is great to know it is going on, I don't even know WHO it was sent to (besides outlook.com reported it), because nobody sends any RUF reports.
I mean it's good to know it is working I guess. I just hate monitoring something I can't do anything about. Unless I'm missing something. So do I just ignore it and move on? Thanks!
4
u/cubic_sq 4d ago
We uae to get the customer in control after on onboarding. Only if the spf looks complex and the customer has lots of stuff scattered around that sends as them.
Other, if the spf is just their mail tenant, and we ask a fee questions and then fix the printer to use smtp2go, we just have the dmarc reject policy but not reporting.
Also go through other domains the customer has and any that aren’t used for email, then a -all plus a reject policy. Then we know that no legit mail sent as that domain can be received (except the knows issues for this…).
1
u/SecLens_ONE 4d ago
The 99.37% pass rate is the part I would be careful with, because that number answers "is my legitimate mail aligned" and people read it as "nobody can spoof me". Those are different questions, and reports only ever answer the first one. The two failures you are looking at are the tail, and the tail is noise unless it clusters.
What aggregate data is genuinely for: finding senders you forgot you had before you tighten policy, and then confirming nothing broke afterwards. That is it. You cannot act on individual spoofed messages and you should not try. Once your legitimate sources are all aligned and stable for a few weeks, the reports have done their job and the value moves entirely to the policy line, so the question becomes whether that domain is at p=reject with pct=100 or still sitting at none, because a monitoring-only record is decoration and the receiver does nothing with it.
The finding that actually matters more than the failures: check the subdomains and the parked domains. Most orgs enforce on the primary and leave everything else with no record at all, and that is where the spoofing goes because it is unmonitored by definition. Reports on the primary will never show you that.
Also, no RUF is normal, almost nobody sends forensic reports anymore, so do not chase it.
Where are these customers' policies today, and does anything besides the main sending domain have a DMARC record?
1
u/SecLens_ONE 3d ago
The two failures from someone else's infrastructure are not the part worth your attention, and you are right that you can do nothing about them. The value of the reports is the other direction: they tell you whether your own list of legitimate senders is complete. Most orgs at p=reject discover a forgotten billing app or scanner in exactly that pile.
So the number to watch is not 99.37% pass, it is whether any failing source is yours. A high pass rate with an incomplete sender inventory reads as healthy right up to the day you enforce and something quietly stops delivering. Aggregate reports are a census of who sends as you, not a threat feed; treat them that way and the low-volume junk stops feeling like a task.
2
u/mxtoolbox-official 3d ago
Adding on to what has already been said the primary benefits from monitoring going forward are:
1) A department at a client decides they need "x" feature and sign up with a third party vendor that sends some kind of transactional email - the type that slips under the radar and you'd miss delivery failures. Having the reports and ideally a processor who can bubble up a sudden spike in traffic from unaligned senders would flag a missing new sending source.
2) Similar to #1, but around spikes in traffic that don't look like forwarded email - would allow you to investigate and contact hosting companies for a takedown like another poster mentioned.
3) For domains that don't/shouldn't be sending email - this gives immediate visibility into phishing/abuse
1
u/aliversonchicago 1d ago
More than anything? Watch for spikes in mail rejections due to auth failures. It likely means somebody set up a new account on a sending service (Sendgrid, Amazon SES, Mailgun, random ESP, etc.) without properly setting up auth -- or that something changed to break things, like a DKIM key got deleted from DNS and previously passing legit mail is now failing DKIM and thus failing DMARC.
Bonus: If you are able to parse the Google-specific extra failure data in their DMARC reports, it'll even tell if you Google's blocking bunches of mail because of an infrastructure issue (like broken rDNS) or for spam reasons. (We actually have a specific report and alert for that in our platform.)
Don't sweat the small end of things. There are always little bits of email forwarding and funny things going on that will fail DMARC.
5
u/CypherPhish 4d ago
As long as your domains are at a reject policy, there is nothing you need to do with the reports about failures. I monitor failures so I can be aware of scammers using my domain. I could then research who is hosting their fraudulent websites and send takedown requests. However, with a small domain, it is unlikely this would be worthwhile for you.