A passing authentication result can still fail DMARC
SPF checks whether a sending system is authorized for the domain evaluated by SPF. DKIM verifies a signature associated with its signing domain. DMARC also asks whether an authenticated domain aligns with the domain in the visible From address, according to the published alignment policy.
Aggregate reports summarize what participating receivers observed. They are useful for identifying sender configuration problems and unknown traffic, but do not provide complete delivery evidence for every message. Report arrival and detail depend on receivers, and the data should be handled according to the organization's mail-security and retention policy.
Setup: collect a legitimate sender inventory
List the organization's normal mail platform, website forms, transactional providers, helpdesk, marketing systems and any delegated senders. Record each visible From domain, envelope or MAIL FROM domain, DKIM signing domain and responsible owner.
Configure a suitable aggregate-report destination and confirm it can receive and process reports. If the destination is external to the policy domain, follow the required reporting authorization arrangement. Retain report identifiers and time windows so the same report is not counted repeatedly during analysis.
Read one sender's report row
- Start with source IP, message count and report period. Map the source to a known service using the inventory and provider evidence; an unfamiliar cloud address alone does not prove abuse.
- Inspect raw SPF and DKIM authentication results and their evaluated domains. Then compare them with the aligned results under the policy evaluation fields.
- Compare the evaluated domains with the visible From domain using the configured relaxed or strict alignment rules. SPF success for a provider-owned envelope domain may not align with the organization's From domain.
- Review disposition and any policy-override information. A reported action is receiver evidence for that observation, not a guarantee that every other receiver made the same decision.
Illustrative incident: transactional mail authenticates for the provider
In this illustrative scenario, a website sends account notifications with the company's From address. Its provider authenticates correctly using a provider-owned domain, but neither SPF nor DKIM aligns with the visible company domain. Aggregate reports show raw authentication success alongside aligned policy failure.
The mail owner enables the provider's supported custom signing or envelope-domain configuration and verifies fresh messages and later reports. The change is tested before stronger enforcement is introduced. This example explains domain alignment and does not claim an actual deliverability percentage.
Diagnostic evidence
| Observation | Inspect | Likely action |
|---|---|---|
| Raw SPF passes, aligned SPF fails | MAIL FROM and visible From domains | Review custom envelope-domain setup |
| DKIM verifies for a provider domain | Signing domain and policy mode | Configure supported aligned signing |
| Unknown source has no aligned pass | Sender inventory and message evidence | Investigate before authorizing it |
| Reports and a user complaint differ | Report period and message headers | Compare the same sender and event |
Correct one approved sender at a time
Repair a legitimate sender's supported domain configuration rather than adding unknown IPs to SPF merely to improve a report. Keep SPF lookup constraints, DKIM selectors and domain ownership in view. A DMARC pass requires an appropriate aligned authentication path; unrelated changes to message content will not establish that path.
Verify current message headers, then inspect fresh aggregate data after the reporting delay. Use several receiving systems where the business depends on them, and check the real mail workflow alongside authentication. Passing DMARC does not promise inbox placement or validate the sender's entire security posture.
SOP
Assign an owner to each sender and domain. Review new services before they begin sending, track alignment failures by known sender and retain evidence for unknown traffic investigations. Document forwarding and mailing-list limitations separately. A staged enforcement decision should follow sender validation, rather than using a single quiet report period as proof that all legitimate systems are covered.
See Clouvenix email security for implementation and operational handover.
Technical reference
Official reference 1. Documentation checked 19 October 2026; confirm behavior for your deployed edition and version.