DMARC reports received: feedback from other providers
What it is
Aggregate reports contain domain-level counts, sending IPs, policy information and authentication observations. They are not individual-message traces or read receipts.
How Elsie measures or checks it
Elsie reads configured reporting inboxes without deletion, extracts bounded XML/gzip/zip attachments, checks required fields and exact domain scope, and deduplicates report identities. It selects summaries by receipt time, retaining provider periods separately.
Why it is done this way
This exposes sending paths absent from local Postfix logs while avoiding double-counting feedback as additional local delivery.
Limits and investigation notes
Not all receivers report. Reports can arrive late, cover different periods or overlap. They are receiver-supplied evidence, not a complete census.
Protocol reference: DMARC aggregate reporting — RFC 9990 ↗
Implementation details above describe Elsie’s current checks, not a claim of full protocol conformance.
Awaiting receiver reports
What it is
The empty state means no parsed report satisfies the configured domain and inbox receipt-time filter.
How Elsie measures or checks it
The summary deliberately avoids a zero-denominator pass rate or a green aggregate-authentication result. Collection status is evaluated independently.
Why it is done this way
No reports received and reports received without failures are different evidence states.
Limits and investigation notes
Publishing rua requests feedback; it does not guarantee its delivery or timing. Provider participation and the reporting path both affect arrival.
Protocol reference: DMARC aggregate reporting — RFC 9990 ↗
Implementation details above describe Elsie’s current checks, not a claim of full protocol conformance.
Aggregate reports received
What it is
Elsie counts selected stored report rows. The report identity combines domain, organization, contact, report ID and provider begin/end times.
How Elsie measures or checks it
An identical repeat is not inserted again. Changed contents under the same identity are flagged for review instead of being added.
Why it is done this way
This avoids simple retransmission double-counting and preserves conflicting input for investigation.
Limits and investigation notes
Reports with different identities can still overlap. A report count does not equal an independent-provider count.
Source: the deployed Elsie report calculation or operational check, reviewed October 5, 2026.
Reporting organizations
What it is
The implementation counts distinct org_name strings in selected report metadata. It does not consult a verified company directory.
How Elsie measures or checks it
The names are supplied by the reporter and stored with contact and report identifiers. Literal distinct name values determine the displayed count.
Why it is done this way
Separating named-organization count from report count helps interpret repeated files from one source.
Limits and investigation notes
Naming variations can split one provider; identical names can merge sources. These are reported names, not verified legal identities.
Source: the deployed Elsie report calculation or operational check, reviewed October 5, 2026.
Messages reported by receivers
What it is
The total is the sum of record row/count values in selected, deduplicated reports. It is count-weighted, not a count of XML rows.
How Elsie measures or checks it
The query joins aggregate records to reports filtered by domain and received timestamp. Provider periods are not used to divide each row proportionally into local hours.
Why it is done this way
Receipt-day accounting surfaces late-arriving evidence without rewriting previously delivered daily reports.
Limits and investigation notes
This is not a global distinct-message count. Overlapping periods, different reporting systems and non-local senders can prevent reconciliation with local events.
Source: the deployed Elsie report calculation or operational check, reviewed October 5, 2026.
Aligned DMARC pass
What it is
The summary treats a row as passing when policy_evaluated.dkim is pass OR policy_evaluated.spf is pass. These are the reported aligned results.
How Elsie measures or checks it
Each qualifying row’s message count is added once. Raw auth_results for unrelated domains do not replace the aligned result.
Why it is done this way
The OR rule avoids both excluding valid single-method passes and double-counting messages that pass both methods.
Limits and investigation notes
These remain receiver assertions. A passing domain identity is not an endorsement of the message’s content.
Protocol reference: DMARC policy and alignment — RFC 9989 ↗
Implementation details above describe Elsie’s current checks, not a claim of full protocol conformance.
Aligned DMARC fail
What it is
A row fails when both aligned policy-evaluated results are fail. Failed volume is total reported count minus the OR-based pass count.
How Elsie measures or checks it
A raw SPF or DKIM pass for a different domain does not override a failed aligned result.
Why it is done this way
This avoids treating another domain’s legitimate signature or authorization as proof of the visible sender identity.
Limits and investigation notes
Failure does not prove malicious intent. Key mismatches, list modifications, forwarding and unauthorized mail need different investigations.
Protocol reference: DMARC policy and alignment — RFC 9989 ↗
Implementation details above describe Elsie’s current checks, not a claim of full protocol conformance.
Aligned DKIM pass
What it is
The method subtotal sums message counts for rows with policy_evaluated.dkim=pass. It is an aligned-method result, not every cryptographically valid signature.
How Elsie measures or checks it
Raw observations are retained for investigation, but the headline comes from policy_evaluated. The same row can also qualify for aligned SPF pass.
Why it is done this way
This preserves the difference between a valid signature and one whose domain matches the required identity.
Limits and investigation notes
DKIM and SPF subtotals overlap. Do not add them to get unique DMARC passes or total messages.
Source: the deployed Elsie report calculation or operational check, reviewed October 5, 2026.
Aligned SPF pass
What it is
The method subtotal sums rows with policy_evaluated.spf=pass. It does not use an arbitrary raw SPF pass from auth_results.
How Elsie measures or checks it
It is independent of the current SPF probe, which evaluates Elsie’s configured IPv4 rather than reconstructing the receiver’s historical SMTP session.
Why it is done this way
Current DNS corrections must not erase the historical results in a provider’s report.
Limits and investigation notes
Aligned SPF and DKIM can pass for the same row. They are overlapping method subtotals, not additive populations.
Source: the deployed Elsie report calculation or operational check, reviewed October 5, 2026.
Receiver-reported reject
What it is
Elsie sums row/count where the reported disposition equals reject. It does not infer rejection from p=reject alone.
How Elsie measures or checks it
Recognized disposition values and aligned authentication results are stored independently for each aggregate row.
Why it is done this way
Keeping these dimensions separate distinguishes policy intent, authentication outcome and reported receiver action.
Limits and investigation notes
This is not a local bounced-event count or a trace of one message. Do not add it to the local permanent-failure count.
Source: the deployed Elsie report calculation or operational check, reviewed October 5, 2026.
Receiver-reported quarantine
What it is
Elsie sums row/count for disposition=quarantine, independently of published policy and aligned result.
How Elsie measures or checks it
The display follows the provider’s reported handling instead of guessing from local queue logs or today’s DNS policy.
Why it is done this way
It supplies a receiving-side observation that a local successful handoff cannot fully describe.
Limits and investigation notes
Quarantine implementation varies. The value does not reveal the precise mailbox location, release authority or whether a person read the message.
Source: the deployed Elsie report calculation or operational check, reviewed October 5, 2026.
Provider reporting periods
What it is
Provider begin/end epoch values are stored, but the daily selection uses IMAP receipt time within the local day.
How Elsie measures or checks it
The display presents the earliest begin and latest end of selected reports in UTC. It does not apportion aggregate row counts into Central-time days.
Why it is done this way
This surfaces late reports without altering already-issued daily history.
Limits and investigation notes
The overall span does not prove contiguous coverage or nonoverlapping observations. Inspect individual report periods for reconciliation.
Source: the deployed Elsie report calculation or operational check, reviewed October 5, 2026.
Source addresses needing attention
What it is
The summary groups source_ip values from rows with both aligned methods failing, then sums their message counts.
How Elsie measures or checks it
It displays up to ten highest-count failing IPs and notes additional retained sources. It does not infer geography, ownership or motive.
Why it is done this way
Prioritization supports focused remediation without restoring long lists of successful domains.
Limits and investigation notes
An IP can be shared or reassigned. Aggregate metadata cannot establish a human sender’s identity or intent.
Source: the deployed Elsie report calculation or operational check, reviewed October 5, 2026.
Collection warnings and unverified feedback
What it is
The collector reads scoped inboxes without deletion or marking message bodies read. It bounds size and decompression, rejects external XML entities and isolates parsing errors.
How Elsie measures or checks it
The summary warns on failed or stale polls over 20 minutes and on receipt-period parsing-review messages. Its header test flags reports lacking expected local DMARC-pass evidence as unverified assertions.
Why it is done this way
Failure isolation preserves routine reporting while keeping unavailable or questionable evidence visible.
Limits and investigation notes
The present header check is a limited provenance signal, not cryptographic proof that XML contents are true. Trusted-header handling at the receiving boundary must be verified.
Protocol reference: Authentication-Results trust — RFC 8601 ↗
Implementation details above describe Elsie’s current checks, not a claim of full protocol conformance.
