Understand DMARC aggregate XML reports, identify senders and separate legitimate traffic from errors or suspicious use. The objective is simple: read source_ip, count, disposition, dkim, spf, header_from and policy_evaluated, without breaking legitimate business email. This guide favors a cautious, documented and measurable method for SMBs, IT teams, marketing owners and executives.
Direct answer: identify real sending flows, check DNS records, apply fixes one by one, test toward Gmail and Outlook, then observe results before enforcement. For this topic, the guiding principle is to read source_ip, count, disposition, dkim, spf, header_from and policy_evaluated.
Key takeaway: Do not change a critical DNS record before understanding which tool uses it. A technically correct fix can interrupt invoices, notifications, web forms or campaigns when the flow was not inventoried.
In short
- A good diagnosis starts with real flows, not assumptions.
- DNS changes should be dated, tested and reversible.
- Gmail and Outlook react to technical setup, but also to reputation and engagement.
- A progressive method protects deliverability and business workflows.
Diagram: read the key XML fields
A raw DMARC aggregate report looks dense, but a few fields drive most of the diagnosis.
A DMARC aggregate report contains the information needed to understand which sources send email with your domain.
Start with source_ip, count, header_from, dkim, spf and disposition. These fields show volume, source and authentication outcome.
Diagram: turn XML into a readable table
To manage DMARC, XML needs to become a source-by-source view with volume and action.
Converting XML into a table helps quickly identify legitimate, unknown or suspicious flows.
A table makes priorities clearer: high-volume legitimate flows come first, but low-volume unknown flows should not be ignored.
Diagram: investigate a source IP
A source IP is not enough to conclude. Connect it to a provider, a tool and an internal owner.
Source IP analysis combines reverse DNS, WHOIS, likely provider and authentication results.
This prevents classification mistakes. An unknown IP may be a forgotten tool, a legitimate provider with bad configuration or real abuse.
Diagram: detect an unknown sender
Small volumes are easy to overlook, but they can reveal an old setup or unauthorized use.
Low volume, an unknown IP, DKIM failure or non-aligned SPF can reveal an unauthorized or misconfigured flow.
The right reaction is not immediate blocking. Verify, identify the possible owner, fix useful flows, then enforce the policy.
When should you use this method?
Use this method when the domain sends from several platforms, when deliverability drops, or before enforcing a stricter DMARC policy. It is also useful after a Microsoft 365, Google Workspace, CRM or marketing platform migration.
It also applies to organizations that want to strengthen email authentication before a customer audit, DNS migration, platform change or major campaign.
Step-by-step procedure
| Step | Action | Validation |
|---|---|---|
| 1 | Map real sending flows, including website, CRM, invoicing, support, marketing and collaboration mailbox. | Documented check |
| 2 | Check DNS records before changing them and keep a dated copy of the initial state. | Documented check |
| 3 | Apply the fix on a limited scope with a clear observation window. | Documented check |
| 4 | Test critical messages toward Gmail, Outlook and a neutral external mailbox. | Documented check |
| 5 | Compare technical results with business feedback: inboxing, spam, promotions, rejections and bounces. | Documented check |
| 6 | Document the decision, tool owners and next review date. | Documented check |
Concrete DNS example
Always adapt values to the real provider. Never copy a DNS example without checking the domain, DKIM selector, report address and expected policy.
example.com. TXT "v=spf1 include:spf.protection.outlook.com include:example-esp.net -all"
selector1._domainkey.example.com. CNAME selector1-example-com._domainkey.provider.example.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"Business deliverability precautions
Do not change a critical DNS record before understanding which tool uses it. A technically correct fix can interrupt invoices, notifications, web forms or campaigns when the flow was not inventoried.
Deliverability does not depend only on SPF, DKIM or DMARC. Complaints, bounces, list quality, volume, campaign consistency and content clarity also matter. Connect this tutorial with audit and deliverability services.
Short definitions
- SPF : DNS record that authorizes servers to send for a domain.
- DKIM : cryptographic signature proving message integrity.
- DMARC : policy that checks alignment and requests an action on failure.
- Sending domain : visible or technical domain used by a platform to send.
- Domain reputation : trust level built by providers from sending history.
Useful internal links
- Dharmail
- audit and deliverability services
- Dharmail blog
- How to Configure SPF, DKIM and DMARC Without Breaking Email Delivery
- How to Create a Sending Subdomain for Brevo, ActiveCampaign or Mailjet
- Why Do My Emails Land in Spam or Gmail Promotions?
- How to Set Up and Use Google Postmaster Tools to Monitor Email Reputation
Final checklist
- Map real sending flows, including website, CRM, invoicing, support, marketing and collaboration mailbox.
- Check DNS records before changing them and keep a dated copy of the initial state.
- Apply the fix on a limited scope with a clear observation window.
- Test critical messages toward Gmail, Outlook and a neutral external mailbox.
- Compare technical results with business feedback: inboxing, spam, promotions, rejections and bounces.
- Document the decision, tool owners and next review date.
- Monitor results for several days.
- Document the date, owner and reason for every change.
Operational validation method
After every change, create a short control sheet. Record the domain, the modified tool, the DNS record, the change time, the expected result and the person responsible. This avoids confused troubleshooting when several teams work on the same DNS zone or sending platform.
Then send three types of messages: a human email from the primary mailbox, an application message from the website or CRM, and a marketing message if a campaign platform is involved. Check the full received headers, not only the inbox placement. SPF, DKIM and DMARC lines show whether the message passes technically and whether the visible domain remains aligned.
Finally, monitor business signals. Lower replies, higher bounces, unusual complaints or customer feedback should be compared with the change date. This simple discipline helps you fix issues quickly without changing too many variables at once. For an SMB, it is often the difference between controlled improvement and a confusing series of tests.
Use the same review rhythm for the following two weeks. Check whether the same providers keep passing authentication, whether complaint signals remain stable, and whether business teams report fewer placement issues. If a new tool appears, do not add it blindly to SPF. First confirm the owner, sending purpose, DKIM support, visible From domain and expected volume. This keeps the setup understandable for future audits.
When the domain is used by sales, finance or customer support, schedule the change outside peak business hours and inform the people who receive customer replies. Their feedback is often the fastest way to spot a legitimate flow that technical dashboards did not reveal.
FAQ
How long should monitoring last before enforcement?
For an SMB, two to four weeks often provide a useful baseline. The window should include campaigns, invoices, reminders, notifications and rarely used tools.
Can everything be fixed in DNS?
No. DNS exposes authorization and authentication, but it does not replace configuration inside Microsoft 365, Google Workspace, the CRM or the marketing platform.
What is the main risk?
The main risk is blocking a legitimate flow nobody inventoried: invoice, web form, business application or old SMTP relay.
Should marketing flows be separated?
Yes when volume, audience or objective differs from human business email. A subdomain makes diagnostics clearer.
Is one isolated test enough?
No. Mailbox providers use aggregated signals. Observe several days and several message types.
When should I request an audit?
When the domain is business-critical, several tools send email, or deliverability loss affects revenue or customer relationships.
Conclusion
Dharmail can help audit your flows, fix DNS records and monitor the impact on Gmail, Outlook and business tools. Contact Dharmail to turn this tutorial into a domain-specific action plan.