DMARC reports show who sends email using your domain. They reveal both legitimate and unauthorised sources. Many organisations publish DMARC in monitoring mode and stop there. Reading the reports helps identify genuine senders, fix authentication gaps, and move towards enforcement. That process helps stop attackers from spoofing your domain.
A quick recap of what DMARC does
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It helps organisations protect their email domains from spoofing.
DMARC works with two other email authentication methods. These are Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).
SPF checks whether an approved server sent the message. DKIM adds a digital signature to prove that the message came from an approved source.
DMARC connects these checks to a policy. That policy tells receiving mail servers what to do when an email fails authentication.
DMARC has three main policy settings:
- None: Monitor email without taking enforcement action.
- Quarantine: Treat failed messages as suspicious, usually by sending them to spam.
- Reject: Block messages that fail the policy.
The key point is simple. A policy of p=none does not block spoofed email.
It gives you visibility, but it does not stop an attacker from sending messages that appear to come from your domain.
Quarantine provides a stronger response. Reject provides the strongest enforcement.
For organisations dealing with phishing and business email compromise, reaching enforcement matters.
What DMARC reports contain
DMARC reports provide the data needed to understand your email environment.
Receiving mail servers send reports about messages that use your domain. These reports show the sources sending those messages. They also show whether authentication checks passed or failed.
The data can reveal legitimate services that your team may have forgotten.
For example, your marketing platform may send email on your behalf. A customer support system may also send messages. Finance software could send invoices from your domain.
An attacker can also appear in the same data.
That makes DMARC reporting useful from an attacker’s perspective. The reports help you understand who uses your domain. They also show where authentication does not match your intended setup.
Without this information, moving to enforcement becomes a guessing exercise.
With it, you can build a clear picture of your legitimate senders.
Why organisations get stuck at p=none
Many organisations start with p=none.
That makes sense during the initial setup. Teams need time to understand their email environment before blocking messages.
The problem starts when monitoring becomes the final destination.
Reports continue to arrive, but nobody reviews them. The organisation keeps collecting data without acting on it.
Over time, the domain can appear protected because it has a DMARC record. However, p=none does not stop spoofing.
This creates a dangerous gap between configuration and protection.
The reason is often simple. Raw DMARC reports can be difficult to interpret. They contain technical data about sending sources, authentication results and message volumes.
Security teams may already have more alerts than they can review. Email authentication data can then sit untouched.
As a result, the organisation never gains enough confidence to move to enforcement.
The answer is not simply to change the policy.
First, understand the data.
Then, fix the genuine sending sources.
Finally, tighten the policy.
Reading reports to separate legitimate senders from abuse
The first step is to identify every source sending email from your domain.
Start with the sources that appear in your reports. Then compare them with the services your organisation actually uses.
Some sources should be familiar. Others may need investigation.
For each source, ask a few basic questions:
- Does this service belong to the organisation?
- Should it send email using this domain?
- Does it pass SPF or DKIM?
- Does its configuration match your intended setup?
- Does the source still need permission to send?
These questions turn raw report data into useful decisions.
Next, separate legitimate senders from unknown sources.
A legitimate source may simply need better authentication. An unknown source may represent misconfiguration, an old service, or attempted abuse.
This distinction matters.
You do not want to block a legitimate marketing campaign. At the same time, you do not want to leave an attacker with an open route to impersonate your domain.
The goal is controlled enforcement.
Fixing genuine senders before enforcement
Before moving to a stricter DMARC policy, fix the legitimate senders you have identified.
Each approved service needs the correct authentication setup.
For SPF, confirm that the sending service has permission to send for your domain. For DKIM, confirm that the service signs messages correctly.
Also check alignment.
DMARC does more than ask whether a message passed authentication. It checks whether the authenticated domain aligns with the visible From domain.
This detail can cause confusion during implementation.
A service may successfully send email while still failing DMARC alignment. If that happens, moving directly to reject could affect legitimate messages.
Work through your sending sources before enforcement.
Marketing tools deserve attention. So do ticketing systems, customer platforms, finance applications and internal services.
Old systems also deserve scrutiny.
An organisation may have stopped using a service months ago while its DNS records remain active. An attacker could target that forgotten configuration if it creates an authentication gap.
Cleaning up these sources reduces the number of exceptions you need to manage.
Moving from monitoring to enforcement
Once your legitimate senders authenticate correctly, start tightening your DMARC policy.
A staged approach can reduce disruption.
Begin with monitoring through p=none. Review the reports and fix the legitimate sources that fail.
Next, consider moving to p=quarantine.
This gives you an additional layer of enforcement. Failed messages can move to spam instead of reaching the recipient’s inbox normally.
Continue reviewing the reports.
Look for unexpected failures. Check whether legitimate services still send successfully. Investigate anything that does not match your known email environment.
Once the results remain consistent, move towards p=reject.
Reject tells receiving mail servers to block messages that fail your DMARC policy.
That is the point where DMARC starts doing the job many organisations assume p=none already does.
An attacker attempting to spoof your exact domain now faces a much stronger barrier.
However, enforcement does not mean you can stop reviewing your email environment.
Your organisation changes.
New suppliers appear. New marketing platforms get added. Teams replace old systems. Applications start sending email.
Each change can affect your authentication setup.
Keep reviewing the data so your policy remains effective.
Validating that your email controls work
Configuration alone does not prove protection.
A DNS record can show that DMARC exists. It does not prove that your wider email controls work as intended.
Validation provides stronger evidence.
Test the controls from the attacker’s perspective. Confirm whether an unauthorised source can successfully impersonate your domain. Check how receiving systems handle messages that fail authentication.
This approach moves the question from “Is DMARC configured?” to “Can an attacker still use my domain to send convincing email?”
That distinction matters.
Attackers do not care whether your DNS record looks correct. They care whether they can make a message appear legitimate.
For that reason, organisations should treat email authentication as an active control rather than a one-time configuration task.
To validate your email exposure and authentication controls, explore our email security capability. You can also use digital risk protection to understand broader impersonation and identity exposure.
DMARC reporting as part of continuous exposure management
DMARC reporting works best when it becomes part of a wider exposure process.
Your email domain is one part of your external attack surface. Attackers can also target exposed credentials, look-alike domains, leaked information and impersonation profiles.
That means email protection should not sit in isolation.
Start with discovery. Identify the domains, services and senders connected to your organisation.
Then validate. Confirm which controls work and which gaps an attacker could use.
After that, prioritise the exposures that create the clearest path to abuse.
Finally, remediate and validate again.
This approach keeps the focus on evidence.
Instead of collecting configuration data and assuming the controls work, you confirm the result.
That is especially useful when your organisation has a large and changing external footprint.
DMARC also works alongside other security controls. Strong identity protection, secure credentials and phishing awareness still matter.
No single control stops every business email compromise attempt.
However, effective email authentication removes one important avenue for domain spoofing.
For the technical specification and reporting guidance, see the official DMARC.org resources.
Frequently asked questions
What do DMARC reports show?
DMARC reports show which sources send email using your domain. They also show whether those messages pass or fail authentication. This data helps security teams identify legitimate senders, investigate unknown sources and find authentication gaps before moving towards a stricter DMARC policy.
Why do organisations stay at p=none?
Organisations often start with p=none because it provides visibility without blocking legitimate email. The problem comes when nobody reviews the reports. Without that analysis, teams lack confidence to enforce DMARC. As a result, the domain can remain open to spoofing despite having a DMARC record.
How do you move to enforcement safely?
Start by reviewing your DMARC reports. Identify every legitimate sender and fix its SPF, DKIM and alignment issues. Then move from monitoring to quarantine while you continue reviewing the results. Once legitimate mail passes consistently, move towards reject and continue checking for new sending sources.
Why does DMARC enforcement matter?
DMARC enforcement tells receiving mail servers how to handle messages that fail authentication. Quarantine sends suspicious messages towards spam, while reject tells receiving systems to block them. By reaching enforcement, organisations create a stronger barrier against attackers attempting to spoof their domain.
