Is a DMARC Analyzer service necessary?

[HCHTech]

Should I sign up for yet another service to turn the zipped RUA & RUF DMARC reports into readable data that is actionable?

• I'm not sure that this matters enough to pay for and then try to sell my clients on. What am I really monitoring here? What actions are warranted when emails fail?
• There don't appear to be any free & self-hosted solutions
• Any multiple-client solutions I found start at $100/mo and go up from there

When I setup DMARC for a client, I do p=none and then listen for complaints for a week, then p=quarantine and then manually look at the reports (using MXToolbox's report uploader) for a while. If there aren't any failures, then we change to p=reject and we're done.

Sudden DMARC failures are basically an indicator that domain is being phished. But with p=reject what further action would be indicated? I wouldn't be exactly keen to tell clients they should be notifying all of their clients to be on the lookout for malicious emails that appear to be from them. If anything this looks like a failure on our part. In point of fact, probably everyone should be reminding their clients that this is a common infection vector and to always be suspicious! I suppose it might indicate that it's time to change passwords and look for bogus forwarding orders, something like that - but I don't want to overreact. I certainly don't want to pay for the privilege of being seen as the boy who cried wolf by my clients.

Maybe I'm missing the point and should be seeing this as another opportunity for recurring revenue?

What are others doing?

 

[nlinecomputers]

I don’t. I used to set up notifications and I still get those but they go into a folder that I never look at anymore.

All the tools we set up are only as good as the Recipient’s spam filtering. You can alert the world that your email only comes from your mx server and that it is digitally signed but if they don’t bother to check? And the phishing is getting smart. I can set up an email domain that is similar to yours, and has SPF, DKIM, and Dmarc. So all the spam filters pass it through because, technically, it’s all correct. But it’s only misspelled by one letter that’s easy for humans to miss.

 

[Sky-Knight]

I stetup notifications that go into a shared mailbox I never look at unless I have a problem. The logging is handy sometimes.

 

[nlinecomputers]

I stetup notifications that go into a shared mailbox I never look at unless I have a problem. The logging is handy sometimes.

Such as? I’ve yet to had an issue that I thought it would solve. The only times I have had emails not being delivered were issues on the receiving side that I had no control over. Best I can do is call them and try and talk with their IT department/contractor or son of the owner who knows computers(#FML)

 

[HCHTech]

All the tools we setup are only as good as the Recipient’s spam filtering.

It's definitely true. At least I feel like I'm "part of the solution" instead of "part of the problem" when I go through the whole SPF/DKIM/DMARC setup with a client.

Which brings up another point. Are you recommending your clients block incoming mail that doesn't have all of the SPF/DKIM/DMARC ducks in a row? I mean, it's a bit hypocritical to say "you gotta do this" for outgoing mail but hold back on incoming. I know the O365 defaults don't do it, and also that O365 treats p=reject as if it were p=quarantine for incoming mail. Now, from a practical standpoint, our clients can't force THEIR clients to setup their email correctly by blocking messages. That just makes them seem hard to work with and gives their clients a reason to find another vendor. I'm not going to be the one that tries to sell that scenario to my clients.

 

[putz]

Are you recommending your clients block incoming mail that doesn't have all of the SPF/DKIM/DMARC

Yes, a DKIM/SPF/DMARC failure for incoming email results in automatic quarantine at minimum, or it follows whatever the senders dmarc policy is set to (assuming they have one configured). Too many senders have poor email configurations with their domains it's ridiculous. These records are there for a reason so always enforce them.

 

[nlinecomputers]

DMARC fails will be marked as spam. Missing records can’t be rejected as still too many services don’t have it setup and my clients would not get legitimate emails. Thought this has vastly improved in the past few years.

 

[YeOldeStonecat]

I just have the record set to _dmarc v=DMARC1; p=quarantine

Used to do a few clients to send report emails...but...it's just noise I don't want to waste time on. My clients all have SPF and DKIM set up properly. If my client uses ANY other service to send emails, I also have those setup properly with DNS. If ANY other service tries to send emails on behalf of my client, I have not authorized it, so it better get quarantined because it's not legit. And I don't need to get alert emails because of that, I don't want them. I want that email to fail, period.

 

[Sky-Knight]

Such as? I’ve yet to had an issue that I thought it would solve. The only times I have had emails not being delivered were issues on the receiving side that I had no control over. Best I can do is call them and try and talk with their IT department/contractor or son of the owner who knows computers(#FML)

Precisely, it documents issues on the other side you have no control over, so you can give your client your due diligence, while also getting the ticket off your desk.

But I must admit I'm rapidly getting to Stonecat's position... it's largely noise. So yeah I'll probably go back and make all of them

v=DMARC1; p=reject; adkim=s; aspf=s; pct=100

soon.

*Edit* I just did the above, no more reports for me.

 

[HCHTech]

Here is an interesting article about RUA and RUF reports that seems to agree with you.

• RUA reports don't give enough data to do much other than note that there was an email that wasn't delivered. They don't say who sent it, they only show that SPF, DKIM or DMARC failed. A report with a list of 50 emails with 1 failure has no actionable data.
• RUF reports are not consistent, and apparently many providers just don't send them.
• RUF reports give detailed information, but it is in plain text so can be a security risk in and of itself.
• RUF reports are sent individually when an email is rejected

I guess where I'm coming down on this is that the reports have limited value when DMARC is first configured - more of a "Did I do it right" analysis. After you are satisfied that yes, you did it right, then you might as well turn the reports back off.

 

[Sky-Knight]

Here is an interesting article about RUA and RUF reports that seems to agree with you.

• RUA reports don't give enough data to do much other than note that there was an email that wasn't delivered. They don't say who sent it, they only show that SPF, DKIM or DMARC failed. A report with a list of 50 emails with 1 failure has no actionable data.
• RUF reports are not consistent, and apparently many providers just don't send them.
• RUF reports give detailed information, but it is in plain text so can be a security risk in and of itself.
• RUF reports are sent individually when an email is rejected

I guess where I'm coming down on this is that the reports have limited value when DMARC is first configured - more of a "Did I do it right" analysis. After you are satisfied that yes, you did it right, then you might as well turn the reports back off.

I used them to stabilize ingress mail for a few clients, but yes this matches my experience. I just never turned them off because it felt like giving up a diagnostic tool. But when I came to this thread yesterday I realized I have mailboxes with a half a decade or so of these mails piled up and they're basically all unread. Which demotes this entire process to the level of hoarding mail almost. So yeah, I turned them all off.