DMARC reports are suddenly showing an enormous increase of spoofed/threat email.
We have dmarc implemented and I usually collect and review the reports weekly. About 3 weeks ago, the number of threat reports massively jumped and remains alarmingly high. Looking at a 2 month period: October-November, 7k emails passed dmarc, 70k have been reported as threats. This all looks like someone external has tried to use my domain and is failing the spf and dkim checks and I am getting the reports about it. I expect dmarc is working as it should but the volume of emails and the sudden increase around 3 weeks ago is what has got be concerned. Unfortunately I have had no reports from humans in that time of fake email coming from my domain. I do not even know the content of the emails or the recipients. All I know from dmarc is that they exist. My dmarc policy is set to quarantine rather than reject so conceivably people are still seeing the emails. I would appreciate any advice from the email experts here.
Paul MacDonald
Not an e-mail expert (or security expert), but I see these from time-to-time as well. I always figure my e-mail addresses got sold in some batch and script-kiddies were trying out their bought scripts. It usually dies down after 5 or 7 days (or they find an easier target).
I expect dmarc is working as it should
That's an awfully large volume, which could be in part due to a issue on your end.
Are you receiving and reviewing DMARC reports from receiving servers?
If not, you should.
dmarcian has a XML to Human converter to help you read the reports
https://us.dmarcian.com/xml-to-human-converter/
You might even want to consider signing up
ASKER
I use dmarcian but easydmarc is also fantastic. Always on the lookout for new tools however. If I was a programmer I would write something. The large volume and sudden spike is what got me. It may in part be because of my company. Have attached a screenshot of what I saw 
DMARC either works 100% or 0%, as DMARC reporting is very simple.
Based on the report you produced, DMARC is working exactly as it should. Some site(s) are sending forged email on behalf of your site, at larger than normal volume, so you'll see a jump in DMARC reports.
That is if the problems really are real threats.
Many brain dead systems (Infusionsoft is the worst) tend to constantly add new sending IP ranges to their infrastructure without adding these new IP ranges to their internal SPF records, which can cause a massive spike in rejected mail till the SPF record is fixed, which can take a very long time.
For best assistance, provide 30 days of DMARC aggregate reports for analysis, or you can run these through some online tool... like Dmarcian's DMARC parser for more info.
Checking for broken mailing systems is fairly easy. Look for IPs which fail SPF at 100% + pass DKIM at 100%, which is an indication some broken mail system has started sending email out some IPs which don't occur in their SPF record.
The way I fix this is to process DMARC forensic reports which generate every 1-2 hours (for most Mailbox Providers), then test the failing IPs + for IPs which are missing from the SPF records, I host my on SPF record... say for Infusionsoft... then continually add IP net blocks on a realtime basis whenever this problem occurs... generally several times/month...
Based on the report you produced, DMARC is working exactly as it should. Some site(s) are sending forged email on behalf of your site, at larger than normal volume, so you'll see a jump in DMARC reports.
That is if the problems really are real threats.
Many brain dead systems (Infusionsoft is the worst) tend to constantly add new sending IP ranges to their infrastructure without adding these new IP ranges to their internal SPF records, which can cause a massive spike in rejected mail till the SPF record is fixed, which can take a very long time.
For best assistance, provide 30 days of DMARC aggregate reports for analysis, or you can run these through some online tool... like Dmarcian's DMARC parser for more info.
Checking for broken mailing systems is fairly easy. Look for IPs which fail SPF at 100% + pass DKIM at 100%, which is an indication some broken mail system has started sending email out some IPs which don't occur in their SPF record.
The way I fix this is to process DMARC forensic reports which generate every 1-2 hours (for most Mailbox Providers), then test the failing IPs + for IPs which are missing from the SPF records, I host my on SPF record... say for Infusionsoft... then continually add IP net blocks on a realtime basis whenever this problem occurs... generally several times/month...
ASKER
The volume is significantly high for us. We use O365 Exchange Online and can report on how many messages are sent and the spike isn’t coming from us. We do use email marketing but have a separate domain for that and use a separate company (constant contact) not our own email server.
Additionally we have Messagelabs wrapped around O365. Our emails are always signed and aligned for both spf and dkim. I have reported to ML and had confirmation that all their external IP's are including in there SPF. As for as checking the failed IP’s, these are pretty much all coming from some sketchy countries.
If this wasn’t an external spam campaign using my domain, is there any way dmarc could be exploited or misinterpreted to generate information like this? If not I guess this is genuine and there isn’t anything I can do about it. Also, is it worth modifying the dmarc record to reject now? There is no possibility that our domain is used anywhere outside of our tenant for legitimate reasons. I have left it at quarantine because reports of spoofing were always low but I think it might be appropriate to reject now.
Additionally we have Messagelabs wrapped around O365. Our emails are always signed and aligned for both spf and dkim. I have reported to ML and had confirmation that all their external IP's are including in there SPF. As for as checking the failed IP’s, these are pretty much all coming from some sketchy countries.
If this wasn’t an external spam campaign using my domain, is there any way dmarc could be exploited or misinterpreted to generate information like this? If not I guess this is genuine and there isn’t anything I can do about it. Also, is it worth modifying the dmarc record to reject now? There is no possibility that our domain is used anywhere outside of our tenant for legitimate reasons. I have left it at quarantine because reports of spoofing were always low but I think it might be appropriate to reject now.
Saying... "The volume is significantly high for us" is... let's see... an inaccurate way of thinking.
Better to look at your DMARC reports to see if...
1) DMARC is correctly reporting forgery attempts. If this is true, then DMARC is working.
2) DMARC is reporting real problems like Infusionsoft adding a range of sending IPs without adding these to their SPF records. If this is true, DMARC is working + Infusionsoft is broken. Fix: Contact Infusionsoft to fix their tech. (Good luck with this. Normally Infusionsoft will tell you they're smart + you're stupid, then just ignore your request. Be prepared for this nonsense. Also, you may have to fix this yourself as I do, by running your own custom SPF infrastructure to patch all mail sending problems.)
3) DMARC is broken. In this case, you'll fix your own SPF or DKIM DNS records or more likely your DKIM message signing.
Summary: Analyze your DMARC records to determine which of #1-#3 is occurring, then take action.
Tip: Email is far more complex than most people imagine. It's a wonder any email gets delivered at all. If you can't figure out which of #1-#3 is occurring, then best to hire someone familiar with this type of debugging... as DMARC debugging is complex + tedious.
Above: As I said above...
For best assistance, provide 30 days of DMARC aggregate reports for analysis, or you can run these through some online tool... like Dmarcian's DMARC parser for more info.
Better to look at your DMARC reports to see if...
1) DMARC is correctly reporting forgery attempts. If this is true, then DMARC is working.
2) DMARC is reporting real problems like Infusionsoft adding a range of sending IPs without adding these to their SPF records. If this is true, DMARC is working + Infusionsoft is broken. Fix: Contact Infusionsoft to fix their tech. (Good luck with this. Normally Infusionsoft will tell you they're smart + you're stupid, then just ignore your request. Be prepared for this nonsense. Also, you may have to fix this yourself as I do, by running your own custom SPF infrastructure to patch all mail sending problems.)
3) DMARC is broken. In this case, you'll fix your own SPF or DKIM DNS records or more likely your DKIM message signing.
Summary: Analyze your DMARC records to determine which of #1-#3 is occurring, then take action.
Tip: Email is far more complex than most people imagine. It's a wonder any email gets delivered at all. If you can't figure out which of #1-#3 is occurring, then best to hire someone familiar with this type of debugging... as DMARC debugging is complex + tedious.
Above: As I said above...
For best assistance, provide 30 days of DMARC aggregate reports for analysis, or you can run these through some online tool... like Dmarcian's DMARC parser for more info.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for your help. I went through and checked the report and none of the IP's used are from Messagelabs. This is an external party send spam as my domain. DMARC is in place and in theory this should help recipients identify mail as spam or real.
You said, "DMARC is in place and in theory this should help recipients identify mail as spam or real."
DMARC works differently than this.
DMARC suggests to Mailbox Providers how stringently they should enforce SPF + DKIM failures.
No mail recipient will every interact with a mail message based on any DMARC setting, only Mailbox Providers.
Said other way, only Google operates on DMARC settings, never Google users like foo@gmail.com or any other Gmail user.
DMARC works differently than this.
DMARC suggests to Mailbox Providers how stringently they should enforce SPF + DKIM failures.
No mail recipient will every interact with a mail message based on any DMARC setting, only Mailbox Providers.
Said other way, only Google operates on DMARC settings, never Google users like foo@gmail.com or any other Gmail user.
as stated above, this is only meaningful if you setup an additional SPF record... which you probably already did. if needed, feel free to ask for help in this thread