Skip to content 
DMARC reports offer an effective way of detecting spoofing attacks at an early stage and making informed decisions about the authentication of your domain. If you regularly analyze DMARC reports, you can verify sender identities and reliably exclude unauthorized email senders.
Key points
- DMARC reports helps to detect spoofing attempts at an early stage.
- SPF- and DKIM-results provide valuable clues for legitimate or fraudulent senders.
- A clearly defined policy_evaluated-field shows whether and how attacks were fended off.
- The Source IP provides information about possible sources of threats outside your domain.
- Tools for Automated evaluation make DMARC reports accessible even to less experienced users.
What DMARC reports contain and why they are helpful
DMARC reports consist of machine-readable XML files that document SPF and DKIM results for each email send attempt. They also contain information about IP addresses, domains used and measures applied. I can use these reports to identify which emails are legitimate - and which are suspected spoofing attempts. Violations of expected SPF/DKIM values or incorrectly configured domain alignment are particularly useful. This information helps me to initiate targeted technical and organizational measures. In order to exploit the actual benefits of this data, it is worth developing a basic understanding of the type of information contained in DMARC reports. Because in many cases, the added value is in the detail: for example, repeated misconfigurations in the DNS records can be a warning that certain senders or applications are not correctly integrated. With each analysis, I build up more knowledge about my own email infrastructure and better understand which senders actually belong to my legitimate network. In larger companies in particular, where several autonomous departments and external service providers send emails on behalf of the main domain, the complexity can quickly increase. DMARC reports are then a central source of information to make the various mail origins visible. This prevents me from falling victim to unprepared spoofing attacks and gives me the opportunity to intervene at an early stage and isolate unauthorized senders.Distinguishing between aggregated and forensic reports
DMARC reports can be roughly divided into two types: Aggregated reports provide overview data on many transactions and are sent daily - they are ideal for long-term analysis. Forensic reports, on the other hand, provide individual analyses of failed authentications - a critical tool for real-time threat detection. Both types fulfill different functions and should be considered in parallel. While aggregate reports reveal patterns, forensic DMARC reports provide concrete evidence of individual incidents. This makes the combination of both formats particularly effective. However, it should be noted that forensic reports are often not made available to the same extent as aggregated reports. Data protection regulations or technical restrictions often limit the level of detail, meaning that some transactions only contain rudimentary information. Nevertheless, it is worth requesting and actively evaluating forensic reports because they can also uncover targeted attacks that are only noticeable as statistical anomalies in the aggregated data. Forensic reports are a valuable tool for taking prompt countermeasures, especially in acute cases of suspicion, such as when a specific IP address becomes conspicuous. In order to exploit the strengths of both approaches, it makes sense to set up automated evaluation processes that use both aggregated and forensic data. This gives me an overall view and at the same time allows me to go into depth when it comes to specific suspected cases.
The most important data fields at a glance
This table shows the typical fields of a DMARC aggregate report and their meaning:| Field | Meaning |
|---|---|
| source_ip | Sending IP address - important for tracing external senders |
| policy_evaluated | Indicates whether a message has been accepted, quarantined or rejected |
| spf / dkim | Test results of the two authentication methods |
| identifier alignment | Indicates whether the sending domain is correctly matched with the From field |
Targeted detection of suspicious activities
I regularly carry out DMARC checks using the reports. If the source IP addresses appear suspicious, I first check whether they are authorized systems (e.g. partner mail servers). If unknown IPs appear that repeatedly send emails in the name of my domain, there are many indications of spoofing attempts. Geographically unexpected server locations can also look suspicious - especially if queries are sent from regions with no business connection. The DMARC Reports report then automatically initiates appropriate protective measures. The origin of the IP in particular plays a decisive role in the assessment. If you only do business in Europe, for example, you should be suspicious if an IP address from South East Asia suddenly starts sending masses of emails. It is often possible to identify such cases as legitimate service providers that have set up shop in distant regions. However, conscientious scrutiny is essential to prevent cybercriminals from slipping through in the first place. In addition to pure IP analysis, it is also worth taking a look at how often SPF, DKIM or alignment fail. Multiple failed signatures from the same source are a strong indication of a spoofing or phishing attempt. I achieve maximum security through systematic documentation: I log all conspicuous sources, compare them with whitelists of existing legitimate senders and, if necessary, block access for unauthorized IPs.
Re-evaluate SPF, DKIM and alignment
Many problems in DMARC reports are caused by incorrectly set SPF or DKIM records. I therefore regularly check my DNS records and use validation tools to avoid errors. Particularly relevant: SPF and DKIM results alone are not enough. The decisive factor is the so-called Alignment - i.e. the correspondence between the domains used in the verification procedures and the visible From sender. A message is only recognized as fully authenticated if this is correct. This can be easily checked using tools such as the E-mail authentication guide. Anyone who uses external service providers for sending emails - such as newsletter platforms or CRM systems - should ensure that these service providers also use correct SPF and DKIM setups. A frequent source of errors is the incomplete integration of these third-party providers into your own infrastructure. If their IP address is missing from the SPF record or no suitable DKIM key is stored, authentication fails. The result: senders are classified as potentially fraudulent, even though they are actually acting legitimately. There are also different alignment modes, such as "relaxed" or "strict". In many cases, the "relaxed" mode is sufficient to prevent legitimate email traffic from being blocked. However, if you have particularly high security requirements or have already been the victim of spoofing attacks, you should consider switching to "strict". Although this potentially reduces the tolerance for the smallest deviations, it also prevents attackers from getting through with only minimally modified domains.Determine processing strategy
I start every new domain configuration with DMARC in monitoring mode ("policy=none"). This gives me a feel for who is sending emails on behalf of my domain. In the next stage, I switch to "quarantine" to isolate potentially spoofed emails in the spam folder. If no more legitimate senders fall through and there are no spoofing attempts, I use "reject" as the final protection mechanism. This triad of monitoring, protection and rejection forms a secure framework for preventing abuse. Depending on the size of the company and the risk assessment, it may make sense to stay in an intermediate stage for longer. For example, "quarantine" can already provide sufficient protection for many companies, because forged messages have typically been moved to the spam folder and therefore no longer pose a direct risk. At the same time, misconfigurations can still be rectified without important messages being completely rejected. The step to "reject" should therefore be well prepared by carefully including all legitimate senders and monitoring their configuration. Seamless communication with all stakeholders is also important before imposing penalties for incorrect DKIM/SPF entries. After all, if there are limited IT resources available internally or at external partners, it can take some time to set up all entries correctly. A transparent exchange clarifies misunderstandings and prevents important emails from suddenly being blocked.
Evaluate DMARC reports automatically
At first glance, the XML structure of DMARC reports seems daunting. Instead of analyzing each report manually, I use analysis platforms that convert these reports into graphical dashboards. This allows me to see at a glance which IP addresses are more likely to be negative or when SPF errors increase. For companies with higher mail volumes, I recommend automated tools such as parser portals or integrated security services. The Integration with a spam protection gateway is helpful here. Automation can go far beyond simply reading the reports. For example, some advanced systems offer the option of automatically blacklisting suspicious IP addresses or sending alerts by email as soon as certain anomalies are detected. This relieves the burden of manual monitoring and allows me to concentrate more on strategic decisions. Automated DMARC evaluation is almost indispensable, especially with high mail volumes, for example in e-commerce or with large newsletter campaigns, in order to be able to react promptly. Even for smaller projects, it is worthwhile not doing the evaluation completely by hand. If you rely on a free platform or write scripts yourself, you will quickly gain routine in dealing with DMARC. You can also upgrade to professional tools at any time if required.Best practices: What I check regularly
To effectively protect my domain against spoofing, I consistently adhere to basic verification processes:- I analyze weekly aggregated DMARC reports for new IP addresses and denied access.
- I check SPF and DKIM entries every time I make changes to the infrastructure.
- I create a whitelist of all legitimate systems that are allowed to send emails on behalf of my domain.
- Suspicious patterns, e.g. many failed DKIM signatures, are prioritized for evaluation.
Clearly recognize and take limitations into account
DMARC reports are not a universal protection mechanism. Forensic reports do not always provide complete content due to data protection rules. Incorrectly configured cloud services can also send legitimate emails into the abyss - even though they are harmless in terms of content. I therefore evaluate each warning in a differentiated way, look closely at the headers of rejected messages in particular and then decide whether a domain should be blocked or just monitored. This requires regular attention - but effectively protects against identity abuse and loss of reputation. Another challenge is the correct evaluation of international sender sources. If my company has customers worldwide, it is not enough to block individual countries. I have to carefully differentiate between genuine customer inquiries and malware campaigns. Monitoring IP addresses and evaluating forwarding scenarios - such as when a legitimate mail server forwards emails - can quickly become complex. Alignment can break, especially if mailing lists or forwarding services are involved, which can falsely lead to negative DMARC results. I should also be aware that DMARC alone does not eliminate every fraud method. For example, attackers could use social engineering techniques to trick recipients into clicking on fake links. DMARC does prevent emails with forged senders from being successfully delivered - but the overall security of the IT landscape and user vigilance must continue to be promoted.
