Email testing guide

How to read an email test report

An email test report describes the message that reached this inbox. Start with the captured authentication results, then inspect message structure and links. A pass is not a guarantee of safety or inbox placement.

Product rules reviewed: October 15, 2026

How do I run a test?

Open Email Test 2.0 and copy the generated address.
Send a non-sensitive test message from an application or mailbox you control. TempHotmail receives this message; it does not send it for you.
Keep the same test inbox open. When the message arrives, open it and inspect the diagnostic report.
Compare the message and captured headers with the sending application’s logs. If nothing arrives, use the delivery troubleshooting guide.

What do Pass, Fail, Warning and Unknown mean?

These are display categories derived from the captured header fields, not a new authentication check performed by your browser.

Display status	Meaning in this report	Next step
Pass	The captured result says pass for that protocol.	Check the authenticated domain and whether it matches the intended sender.
Fail	The captured result contains fail, permerror or policy; a Received-SPF failure fallback can also appear as Fail.	Inspect the raw result and ask the sending service to check its configuration and logs.
Warning	The captured result contains softfail, neutral or temperror.	Read the exact result before deciding whether to change configuration or retry.
Unknown	There is no recognized result for that protocol, or the captured value is none.	Check whether the provider exposed headers. Unknown does not prove authentication failed.

What do SPF, DKIM and DMARC each describe?

SPF records a receiving server’s assessment of the sending host for the envelope domain. DKIM records its assessment of a message signature. DMARC checks whether a passing SPF or DKIM identity aligns with the visible From domain.

TempHotmail summarizes the available Authentication-Results field, with fallbacks to ARC-Authentication-Results and Received-SPF where applicable. A captured header is only as useful as its receiving infrastructure and provenance; pasted or sender-supplied text is not independent proof.

Why can SPF pass while DMARC fails?

SPF can pass for an envelope domain that does not align with the visible From domain. If no passing, aligned DKIM signature satisfies DMARC either, DMARC can fail.

For example, SPF may authenticate a sending provider’s domain while From uses your application’s domain. Check the envelope sender, DKIM signing domain, From domain and alignment policy together. Read your sending provider’s instructions before changing DNS.

Why are results Unknown or headers missing?

The receiving provider may not expose the required headers, or the captured header may not contain a recognized result. A missing result is a visibility limit, not a failed test.

If headers exist, expand the raw-header panel and look for Authentication-Results. If the result is still unavailable, compare with an organization-controlled test mailbox and the sender’s logs. If no message arrives, there is no received-message report to interpret.

Does a pass guarantee Gmail inbox placement or a safe attachment?

No. Authentication results describe specific checks on one received message. They do not prove a link or attachment is safe, and they do not predict delivery to every mailbox provider.

This tool does not rerun DKIM signature verification, perform a live DNS audit or provide a malware scan. Use a controlled inbox at the destination provider to investigate that provider’s delivery behavior.

What do links, pixels, format and message hops tell me?

The link count summarizes distinct HTTP/HTTPS links in the captured HTML; it is not a reputation check.
Tracking-pixel indicators use image attributes and URL patterns. Zero detected pixels does not prove that a message contains no tracking.
Remote images stay blocked by default in the message viewer. Loading them can make requests to an outside server.
HTML and plain-text indicators describe which bodies are available. Message hops count captured Received fields, not an independent trace of every network event.
The HTML size warning is a heuristic for large message bodies, not proof of clipping in any particular email client.

Public worked example

SPF and DKIM pass, but DMARC fails

This synthetic example uses reserved example domains. It demonstrates the same analyzer used for received messages; it is not a live delivery test or a customer message. Example reviewed October 15, 2026.

spf: pass
dkim: pass
dmarc: fail

The captured SPF and DKIM results authenticate delivery.example identities, while the visible From domain is sender.example. Neither passing identity aligns with the From domain in this example. The report reads the captured DMARC failure; it does not calculate alignment again.

Content summary: 1 distinct web link, 0 detected tracking-pixel indicators, 1 captured Received field. Zero pixel indicators does not prove there is no tracking.

Inspect the example headers

Authentication-Results: mx.receiver.example;
 spf=pass smtp.mailfrom=bounce.delivery.example;
 dkim=pass header.d=delivery.example;
 dmarc=fail header.from=sender.example
Received: from outbound.delivery.example by mx.receiver.example
From: Example application <notifications@sender.example>
To: Example test inbox <inbox@receiver.example>
Subject: Example signup confirmation
Content-Type: multipart/alternative