When browsing the dashboard pages of DMARCwise, you’ll frequently see statistics that refer to weekly or monthly periods, or the ability to filter reporting data by a date interval (e.g. previous 7 days, previous 30 days, from day X to day Y, etc.).
Filtering DMARC and TLS reporting data by date is trickier than it seems. In fact, reports can theoretically cover any time interval of a day, multiple full days or multiple partial days, so it’s not always immediately clear or possible to determine to which day a report refers to.
For example, a DMARC report may signal that 1,000 messages were handled in a certain way between 10:00 of 1 March and 10:00 of the next day, 2 March. Should this data be attributed to 1 March or 2 March?
This is a scenario we often encounter in practice, given that email infrastructure runs in a wide variety of timezones and often sends reports according to the local start and end of the day.
Unfortunately, DMARC and TLS reports do not contain any timezone information and instead use UTC (Coordinated Universal Time), preventing to go back and accurately match the UTC range to the actual intended day.
Similarly, some reporters intentionally use intervals not aligned to a calendar day for operational reasons, such as staggering report generation throughout the day.
The result is that in extreme cases, a report’s UTC date range is compatible with two different local days, yet filtering by date requires assigning each report to exactly one.
Reporting day
To solve this, the tradeoff we’ve made is to attribute each report to the midpoint between the beginning and end of the interval.
The UTC date of this midpoint, which we call the reporting day, is more reliable than using the start or end of the range: it is the timestamp most likely to fall on their actual local reporting day.
The following table illustrates how the reporting day is calculated in a few practical cases, assuming that the reporter is sending reports according to their local start and end of the day:
| Reporter timezone | Report range (UTC) | Reporting day |
|---|---|---|
| UTC | 1 March 00:00 → 2 March 00:00 | 1 March ✅ |
| UTC+1 | 1 March 23:00 → 2 March 23:00 | 2 March ✅ |
| UTC−5 | 1 March 05:00 → 2 March 05:00 | 1 March ✅ |
| UTC+12 | 1 March 12:00 → 2 March 12:00 | 2 March ✅ |
The UTC+12 row illustrates the ambiguous case mentioned above: a report spanning 1 March 12:00 to 2 March 12:00 UTC is compatible with both a UTC+12 sender (New Zealand, Fiji) reporting their local 2 March, and a UTC-12 sender reporting their local 1 March.
The midpoint lands exactly on midnight, and since UTC-12 covers only uninhabited territory with no real email infrastructure, DMARCwise attributes the report to 2 March, the correct day for UTC+12 senders.
The same approach works naturally for intra-day intervals, where the midpoint falls well within the day:
| Report range (UTC) | Reporting day |
|---|---|
| 1 March 08:00 → 1 March 09:00 | 1 March ✅ |
| 1 March 14:00 → 1 March 20:00 | 1 March ✅ |
| 1 March 22:00 → 2 March 00:00 | 1 March ✅ |
How well does this work?
In practice, we believe this heuristic works well for the vast majority of reports. The midpoint is the date that most reliably reflects what the reporter intended, regardless of the interval convention they use.
Since DMARC reports contain no ground truth about the reporter’s intent, we can only estimate accuracy based on timezone data, and by that measure, more than 99% of reports are attributed to the expected day, with the remaining edge cases concentrated in a handful of small Pacific islands and non-standard report durations.
When report intervals span more than 24 hours, we attribute the report to the central day of the interval, which remains a reasonable approximation. Similarly, zero-duration reports (where start and end are identical) are attributed to the UTC date of the start time directly. According to our data, these edge cases together occur in around 0.1% of all reports.