All blogs & guides

PRACTICAL OUTREACH

DMARC Reports: Read Them and Find Sending Problems

By TransmitInbox team
Published September 20, 2026 · Updated October 14, 2026

DMARC reports can arrive every day while nobody on your team knows what to do with them. Hidden inside those attachments is useful evidence about which systems are sending with your domain and where authentication needs attention.

Start with a report someone is responsible for reading

An aggregate DMARC report is a summary from a receiving mail system. It groups observations about mail using your domain, including sending sources and authentication outcomes; it is not a campaign report showing opens or replies. The reporting format is defined in RFC 9990. DMARC aggregate reporting standard

The rua value in a DMARC record specifies the aggregate reporting destination. Reports commonly arrive as XML attachments, sometimes compressed. A reporting service can turn those files into a more readable view. Microsoft’s reporting guidance

Before choosing software, assign an owner. Someone needs to review new sources, investigate failures, and keep the sending inventory current. A dashboard nobody checks simply gives the unread attachments a nicer home.

Use a controlled reporting mailbox or service rather than relying on one employee’s personal inbox. Record who can access it, who manages the DNS record, and what happens when the usual reviewer is away.

If reporting is already configured but nothing arrives, ask the administrator to check the destination and routing. An external reporting service may also need DNS authorisation. Use its setup instructions rather than adding records by guesswork. Reporting configuration checks

Match sending sources to your own inventory

Start with the report’s domain, reporting organisation, and time period. Then review the sending IP addresses and associated message counts. These describe observations within that report’s coverage. Report fields

Keep a separate list of services authorised to send for your business. Include employee mail, outreach tools, newsletters, support platforms, website forms, and transactional applications. Give each entry an internal owner.

When an unfamiliar source appears, investigate it before classifying it. It could relate to a forgotten service, an indirect delivery route, or unauthorised use. A recognisable hosting company is not enough evidence that your team approved the sender.

Ask practical questions:

• Which application could have produced this mail?
• Does its configured sending route explain the source?
• Who owns the account and its authentication settings?
• Can a representative message or log confirm the connection?

Do not add an unknown source to SPF merely because it appears in a report. First establish whether it should be sending at all. Authentication configuration should follow your authorised inventory, not make every observed source pass.

Save the answer when a source is identified. The next reviewer should not have to repeat the same investigation because the explanation stayed in somebody’s chat history.

Read authentication and alignment as separate checks

SPF or DKIM can pass individually while DMARC fails because the authenticated domain does not align with the visible From domain. Microsoft identifies this distinction as an important troubleshooting clue. DMARC alignment guidance

In the XML, auth_results contains underlying authentication results, while policy_evaluated includes the alignment-aware SPF and DKIM outcomes used for DMARC evaluation, alongside disposition. Compare them rather than treating every “pass” as equivalent. Aggregate report structure

Consider this simplified teaching example, not a client report:

• The visible From domain is example.com.
• DKIM passes using the sending service’s domain, provider.example.net.
• SPF passes using that service’s envelope domain.
• Neither authenticated identity aligns with example.com, so DMARC fails.

The useful question is whether the authorised service has been configured to authenticate appropriately for your domain. A working signature for another domain does not answer that question.

Have the service owner inspect the actual message and the relevant configuration. Our SPF, DKIM, and DMARC troubleshooting checklist covers the underlying setup without requiring you to diagnose everything from an aggregate row.

Once corrected, look for fresh evidence from that route. Keep the change timestamp so reports covering earlier traffic are not mistaken for proof that the correction failed.

Know what the report cannot establish

Reports reflect the receiving systems that generated them, rather than a guaranteed census of every message you sent. Disposition information describes DMARC handling; it does not prove inbox placement. Other filtering can affect a message separately. Reporting scope and disposition

This matters when your team sees a healthy authentication result but weak campaign outcomes. Keep investigating. Our guide to business emails going to spam explains other areas worth reviewing.

Do not describe every failing row as a lost customer email. First determine whether the traffic was yours, which route it followed, and what the available evidence shows. Equally, do not describe every passing row as a successful conversation.

Keep report observations beside delivery logs, provider responses, and campaign results. Compare similar periods and coverage. Totals from different reporting systems may describe different sets of messages, so write down those differences before drawing conclusions.

For North American and European campaigns, authentication evidence remains separate from contact eligibility and regional requirements. A passing result confirms neither the relevance of your offer nor permission to send it.

Quick checklist: give each finding a next step

Before closing a report review, check that you have:

• Confirmed the domain and reporting period.
• Matched legitimate sources to named service owners.
• Investigated unexpected sources instead of automatically authorising them.
• Distinguished basic authentication from DMARC alignment.
• Recorded the correction, owner, and follow-up evidence needed.

Avoid tightening a policy simply because one summary looks reassuring. Review all known legitimate routes and plan any enforcement change with the administrator responsible for them. Keep a record of the previous configuration and a way to address unexpected failures.

A useful DMARC review ends with an updated inventory or a specific action. If reports keep arriving without either, a managed cold email service can help coordinate the investigation. Ask who reads the reports and how unresolved findings reach the person who can fix them.