DMARC reports received: feedback from other providers
These are summaries sent back by participating receiving email providers. They describe what those providers observed about mail claiming to use your domain.
Why it matters. They can reveal an old application that is set up incorrectly or an unfamiliar system pretending to use your name.
For example. Your own server sees the mail it handles. A receiving provider can also report mail using your domain that originated somewhere else.
What to do. Keep these figures separate from local delivery totals. Investigate unfamiliar senders, but do not label every failure as an attack.
Awaiting receiver reports
No applicable receiver summary has arrived for this period. That is missing feedback, not an authentication pass or failure.
Why it matters. A newly published reporting address cannot create instant historical reports. Participating providers must observe mail and generate their feedback first.
For example. Putting a suggestion box on the wall does not mean somebody has already left a response.
What to do. Allow for provider reporting schedules. If expected feedback remains absent, check the reporting address, mailbox delivery and collection job.
Aggregate reports received
This counts the distinct provider-summary reports Elsie accepted in the day’s receipt window. It is not a count of emails you sent.
Why it matters. A summary can describe thousands of messages. One provider can send several summaries.
For example. Two report files describing 500 messages count as two reports and 500 reported messages—not two ordinary deliveries.
What to do. Compare report count, provider count and reported volume before judging how much feedback coverage you have.
Reporting organizations
This counts the different organization names in received summaries. It indicates how many named reporting sources contributed.
Why it matters. More report files do not necessarily mean more independent providers.
For example. One provider can send separate summaries for different periods or systems while using the same organization name.
What to do. Treat this as a coverage clue, not proof that every service your customers use has reported.
Messages reported by receivers
This adds up message observations in the provider summaries received that day. It does not add new successes to your local delivery report.
Why it matters. Feedback can describe earlier days or mail sent by other systems using your domain.
For example. A report arriving today can describe yesterday’s activity. Its original reporting period remains visible.
What to do. Check the provider periods and sources. Never add this number to successful local deliveries.
Aligned DMARC pass
The provider reported that at least one supported identity check passed and matched the domain shown to the reader.
Why it matters. Proof for somebody else’s domain does not prove authorized use of yours.
For example. A matching message signature can satisfy the test even when the other method fails. Both methods do not have to pass together.
What to do. Read this as authentication evidence—not proof of safe content, inbox placement or reading.
Aligned DMARC fail
The provider reported that neither method supplied passing proof matching the visible sender domain.
Why it matters. Possible causes include a legitimate system configured incorrectly, forwarding-related trouble, or unauthorized use of your domain.
For example. An old notification service can still send for your organization after a server move without passing the required checks.
What to do. Compare the source with your approved applications. Correct legitimate sending systems and investigate unknown sources before drawing conclusions.
Aligned DKIM pass
The provider reported a passing message signature tied to the required sender-domain identity.
Why it matters. This is reported message feedback, unlike the green DKIM box that checks the public-key configuration now.
For example. A correct key can be published while an application forgets to sign its messages. Comparing the two report sections can expose that difference.
What to do. Ask for real outgoing signatures and receiver observations when configuration is green but reported results are poor.
Aligned SPF pass
The provider reported that the sending system was authorized and that its authorization matched the domain identity required for the message.
Why it matters. This reports what happened at a destination, not merely whether Elsie’s current settings authorize its own server.
For example. A forwarded email can reach a provider from a different server than the original sender, changing the observed permission-check result.
What to do. Compare the source and approved sending services. A permission result for an unrelated domain is not proof of yours.
Receiver-reported reject
This counts messages that a provider described as rejected in its feedback. It describes reported handling, not just your published preference.
Why it matters. A reject policy is your request. This number is what a provider says happened.
For example. A provider can handle an authentication failure differently under its own rules, so failure and rejection counts need not match.
What to do. Review the source, failures and period together. Investigate a legitimate service appearing here before relying on it for more important mail.
Receiver-reported quarantine
This counts messages that a provider says it treated as suspicious or set aside under its quarantine handling.
Why it matters. The recipient may not see those messages in the ordinary inbox even when the address is correct.
For example. Some organizations use an administrator-managed quarantine rather than a folder visible to the user.
What to do. Have the receiving administrator trace important mail. Do not assume quarantine always means the same spam folder.
Provider reporting periods
The provider’s range says when it observed the mail. Its summary can arrive at Elsie later.
Why it matters. Old feedback should not be mistaken for a new problem or counted against the wrong day’s outgoing mail.
For example. A Monday report arriving Tuesday is shown with Tuesday’s received feedback and its original Monday period.
What to do. Compare periods before comparing counts. A wide displayed span is not a promise of continuous coverage.
Source addresses needing attention
These are internet addresses of sending systems that providers associated with failed domain-identity checks.
Why it matters. They point to a system worth investigating. An unfamiliar address is a clue, not automatic proof of an attack.
For example. It might be an approved outside service, a forwarding system, or an unauthorized sender.
What to do. Compare the address with your known providers before blocking a legitimate service or dismissing the evidence.
Collection warnings and unverified feedback
A warning means feedback could not be read reliably, a report needs review, or its figures should be treated cautiously.
Why it matters. A broken reader or questionable attachment must not become an all-clear result.
For example. A malformed report can be held for review while ordinary delivery reporting continues.
What to do. Have the administrator check the mailbox and collection job. Do not randomly change mail policy because one report file could not be read.
