When a receiving mail system checks a message, it may record SPF, DKIM and DMARC outcomes in an Authentication-Results header. Received headers can also show a reported route and timestamps. Both are evidence supplied in the message—not a guarantee that it is safe or a complete delivery trace.
Sender Policy Framework checks whether the connecting mail server is authorized by a domain's policy for a particular sending identity. A pass for that identity alone does not establish that the visible From address is aligned or that a message is benign.
DomainKeys Identified Mail verifies a domain's cryptographic signature over selected message content. A passing signature says that signed content validates for its signing domain; it does not by itself prove that domain is the one shown to the recipient.
DMARC evaluates whether an SPF-authenticated identity or a valid DKIM signing domain aligns with the message's visible From domain, and applies the domain's published policy. It combines authentication with alignment; it is not a malware or phishing verdict.
Mail can pass through several systems, and an attacker can insert a header that looks plausible. Use results only when you can identify the trusted receiving system that added them. A header's mere presence does not establish that its claims are valid.
A pass is not proof that a message is wanted or safe; a fail can have several causes, including forwarding or sender misconfiguration. Check the trusted receiver's documentation and message trace, and compare the results with the visible From domain and your organization's mail controls. This guide and helper do not verify signatures, inspect DNS, establish header provenance, or diagnose delivery.
Copy the relevant Authentication-Results and Received lines from a test message delivered to an account you control. The tool lists Received hops in header order (oldest first) and calculates differences between reported timestamps when it can parse them. Server clocks can differ, and untrusted headers can be forged; check the trusted receiving boundary and compare with your provider's message trace. Remove addresses and identifiers first. The browser tool reads the pasted header section locally and does not save or send it.
Send from a mailbox you control, through the Microsoft 365 or other approved sender you want to check, to info@cloudekhosting.com. Use a unique subject and no sensitive body content so you can identify the correct delivered copy. If it does not arrive, check Exchange message trace and any non-delivery report separately; there is no received header copy for this helper to analyze. For a delivered message, open it in Outlook. In new Outlook or Outlook on the web, choose More actions → View → View message details. In classic Outlook for Windows, open the message in its own window, choose File → Properties, then copy the Internet headers. Paste the header text into the local reviewer above; it reads the header section only and ignores the body. Microsoft’s Outlook instructions for viewing internet headers cover the supported Outlook versions.
This examines one delivered copy and its reported headers. It does not prove outbound delivery, inspect every hop, or replace Exchange message trace. Remove addresses and identifiers before sharing or saving a diagnostic.
See the IETF specifications for Authentication-Results (RFC 8601), SMTP trace information (RFC 5321, section 4.4), SPF (RFC 7208), DKIM (RFC 6376) and DMARC (RFC 9989).
