Showing results for 
Search instead for 
Did you mean: 
Cisco Secure Email Support Community

Product Support Talos Support Cisco Support Reference + Current Release
Gateway Reputation Lookup Open a support case Secure Email Guided Setup
Gateway: 14.0.1-033
Cloud Gateway Email Status Portal Support & Downloads
Email and Web Manager: 14.1.0-227
Email and Web Manager Web & Email Reputation Worldwide Contacts Product Naming Quick Reference
Reporting Plug-in:
Encryption Bug Search
Encryption Plug-in:
Cloud Mailbox Notification Service
Outlook Add-in(s): More info


get ESA to report DMARC on UTC timeframe as recommended by RFC ?

The RFC for DMARC strongly recommends that reports covering a 24-hour span (which the IronPort's reports sort of do) contain data based on a 24-hour UTC timeframe. (midnight UTC to midnight UTC)

"Aggregate reports are most useful when they all cover a common time period." as specified in the RFC. 


It's useful for the ESA's general logs to be in my local time zone, but the DMARC config should allow for collation+reporting of data on they expected universal timeframe.  As it is, since I'm in a TZ with one of several versions of DST, I have to readjust the report schedule a couple times a year to be close to the expected cadence.


Screen Shot 2021-10-22 at 00.41.36.png


Since report generation might be a performance hit, it's completely reasonable that "Schedule for report generation" be the local time that the job fires.  But the data that is sent should really only be for the prior UTC day.



Hi Tomki,


we have been a DFMARC reporter for 3+ years now using the ESA DMARC features. We never did get any feedback or complains about our reports and they have been processed by the largest DMARC aggregators. 


While it would be nice to be fully compliant, i think the easiest way to overcome thiis issue is by using a good NTP time source and apply the correct timezone and offset. You will be fine withouit manual edits.



Hi Marc,

I currently run support at one of those largest DMARC aggregators (dmarcian), and I used to do the same for one of the others (agari).  I can tell you that this is a problem which should be addressed.

I have not attempted to reach out to owners of individual IronPort implementations, because the problem is purely an implementation bug as far as I can see.  The resolution you can apply is pretty limited, and there are still failure aspects.



- if you have 6 ESAs, there is a good chance that you have some in at least one different timezone either for failsafe purposes, or for office differentiation. (I know this is commonly the case, I used to work at IronPort as well)  You're likely using CCM, so your DMARC configuration is homogeneous.  ESAs in varying timezones are usually set to use time settings for that timezone.. This company is based on East Coast of the USA, the configuration says to send DMARC data at 19:00 (your native time, equating to 23:00 UTC now, but will be 22:00 during DST). This means that the 3 ESAs in a datacenter on the West Coast of the USA will report DMARC data at 19:00 Pacific time, which is actually 03:00 on the following day.  DMARC aggregate reports for traffic sent from one portion of the infrastructure will be offset from data from the other portion(s). This problem is publicly observable here: Providers which show to have data on a given date long the end of that UTC day are usually reporting at an end time very early in the morning, and have skewed reporting for traffic into the wrong day. Since ESAs do not support the ri tag for varying report interval, that is not a factor for ESA based environments such as or  Plenty of variance in the 3800+ misconfigured IPHMX hosts in that list as well.

- a second factor in the lack of proper UTC alignment for the ESA reporting is that the time an admin configures for report generation simply kicks off a collation script, which iteratively collects data for domains in some sort of sequence. This means that maybe the first domain report generated has a report timespan of Mon, 05 Jul 2021 23:00:00 UTC to Tue, 06 Jul 2021 23:00:00 UTC. 

The next report (or 10th) will be Mon, 05 Jul 2021 23:00:04 UTC to Tue, 06 Jul 2021 23:00:04 UTC
Once the ESA reaches its limit of 1000 reports the report window is quite different, something like this isn't a stretch based on some I've seen: Mon, 05 Jul 2021 23:15:38 UTC to Tue, 06 Jul 2021 23:15:38 UTC

There are some obvious and less obvious reporting problems attributable to the sliding report window, but my mention of it here is more to elaborate on the point that not having a stable and universal window that reports are generated *for* is problematic.




Recognize Your Peers
Content for Community-Ad