Microsoft Sentinel analysis is only as reliable as the data that reaches its workspace. Start with a controlled pipeline that turns untrusted report files into normalized, tenant-scoped observations. Sending an attachment directly to a logging endpoint is not a substitute for validating its contents, preserving provenance and checking that the intended rows remain queryable.
Define the Azure boundary
Microsoft's Logs Ingestion API guide describes JSON ingestion into a Log Analytics workspace, with a data collection rule (DCR) defining the input and destination. The table must exist first. A transformation can map the input schema to the destination schema. Obtain the endpoint, DCR immutable identifier and stream name from the actual deployment rather than copying values from an example.
The same guide distinguishes a DCR ingestion endpoint from a data collection endpoint (DCE). A DCE is needed for the documented private-link case or when the DCR lacks an ingestion endpoint. It also documents access scoped to the DCR and the Monitoring Metrics Publisher role. Have the Azure owner approve the identity, scope and destination. This article does not provision identities, grant permissions or assert a native EmailAuth connector.
Preserve meaning during normalization
Use separate fields for report period, ingestion time, tenant identifier, reporting organization, report identifier, row identity, policy domain, source IP and message count. Authentication outcomes and policy disposition are different observations. Preserve the raw-file hash and an access-controlled evidence reference without copying the entire report into every event.
RFC 9990 defines aggregate-report semantics. One row may represent multiple messages. Summing rows instead of the count field produces a misleading volume. Deduplicate the report before expanding it into rows, and keep any correction or replay linked to its earlier import. Do not present missing reports as proof that no mail was sent.
Reject unsafe inputs before export
Bound attachment size, expanded bytes, execution time and queue depth. Use an XML parser configured to reject external resource resolution and unnecessary declarations. OWASP's XML guidance explains why parser configuration must be explicit. Put rejected inputs in a restricted quarantine with a reason and retention policy; a parser error is not an authentication failure.
Test invalid compression, excessive expansion, malformed XML, prohibited external-resource resolution, invalid message counts and incorrect tenant association before accepting data. Choose size, nesting, element-count and runtime limits from the supported schema and capacity tests, not arbitrary demonstration values. Keep parser rejection separate from a DMARC authentication result. No parser implementation, sample dialect or executed security test is supplied here.
Verify the complete path
Suppose one accepted report row represents seven messages. A repeated identical report should not increase that analytical total under the chosen deduplication policy; the expected total remains seven, not fourteen. This is hypothetical count arithmetic, not an observed ingestion result. In a real test, query the destination table by tenant and report identifier and compare both row count and summed message count with the retained normalized input. Test a transformation that drops a field or row so acceptance cannot be confused with complete evidence.
Record request acceptance separately from destination visibility and analytic-rule execution. Maintain a durable retry queue, classify permanent schema failures separately from transient service failures, and reconcile uncertain submissions before replay. Alert on ingestion lag and quarantine growth. These design checks do not prove Azure ingestion, Sentinel detections or email delivery without observed end-to-end evidence.