How to inspect test emails: headers, SPF, DKIM and DMARC

A provider dashboard saying “sent” usually means the provider accepted the request. A message appearing in a test inbox adds valuable evidence: a receiving system accepted it. Neither event tells you that the correct template, recipient, reply address, links and attachments were used. Nor does one successful receipt guarantee inbox placement at Gmail, Outlook or a customer's corporate gateway.

Inspection is therefore a sequence, not a single green badge. Start with what a recipient would notice, then move into headers and authentication results only when they help answer a specific question. DemoPost's Email Inspector brings these views together, but the judgement remains yours; it does not automatically diagnose or repair a sending configuration.

1. 1
   Create a fictional test user in your own application with a DemoPost address, for example yourprefix+signup@in.demopost.net.
2. 2
   Trigger the real workflow through the application: register the account, request the reset or create the invoice. Do not bypass application logic by sending directly from the provider console.
3. 3
   Open the newly received message and note the receipt time. Authentication evidence describes this delivery, at this moment, through this route.
4. 4
   Keep the data synthetic. Headers and original message files can contain addresses, identifiers and routing information that should not come from a real customer record.

Read the subject and body before opening the technical views. Confirm that the test user, environment, dates, currency and call to action match the scenario. Look for empty values, unresolved strings such as {{first_name}}, and links pointing to localhost, staging or an old domain. If there is an attachment, check its filename, type and size, then open it only when you expect that file.

Compare the HTML and plain-text parts. A multipart message can give capable clients an HTML version while retaining a readable text alternative. Missing plain text is not an authentication failure, but it may reduce accessibility and make the message less useful in text-oriented clients. Responsive preview widths can reveal wrapping problems; they do not emulate every behaviour of Gmail, Outlook or mobile mail apps.

External images may be blocked until you allow them. That is a viewing safeguard: loading a remote image makes a request to another server. Inspect the source and image URLs first if you do not recognise them. Likewise, inspect a link destination without automatically visiting it, then decide whether it belongs to the application and environment under test.

From is the visible identity

The From header is what readers normally see as the sender. DMARC uses its domain as the reference point for alignment. Confirm that its display name and address represent the product and environment you intended to test.

Reply-To controls where a reply goes

Reply-To can intentionally differ from From when a help desk, agency or specialised service handles responses. The difference is an observation, not a security failure. Confirm that the address belongs to the intended reply-handling system. SPF and DMARC do not authenticate Reply-To simply because it appears there.

Return-Path reflects the envelope sender

The return path commonly represents the SMTP envelope sender used for bounce handling. SPF evaluates the sending IP against that envelope identity (or, in some cases, the HELO identity), not against the visible From address. A provider-managed return path can therefore differ from From and still be expected. DMARC determines whether a passing SPF or DKIM identity aligns with the visible From domain.

SPF: was this server permitted for the envelope domain?

SPF compares the connecting mail-server IP with the policy published for the envelope sender domain. A reported pass supports that narrow statement. It does not validate the visible From address, inspect the message body or prove that a person is trustworthy. A server IP in a header usually belongs to a provider or data centre; it is not reliable evidence of a person's physical location.

DKIM: did a cryptographic signature validate?

DKIM lets a domain sign selected headers and the message body. The signature names a signing domain and selector whose public key is published in DNS. Merely finding a DKIM-Signature header is not a pass. Look for a trusted receiving system's reported validation result. A failure can follow from an incorrect key or from signed content changing after signing; the exact evidence matters.

DMARC: does a passing identity align with the visible From?

DMARC connects authentication to the domain a reader sees. It passes when at least one qualifying mechanism passes and aligns: either SPF with an aligned envelope domain, or DKIM with an aligned signing domain. Consequently, SPF and DKIM can each show a pass while DMARC fails if neither passing domain aligns with From. Check the identities rather than counting green labels.

These results are observations recorded along the delivery path. Authentication passing does not prove a message is harmless, and it does not guarantee that another provider will place the message in the inbox.

“Fail” means an evaluation produced a negative result. “Unavailable” means DemoPost cannot present trustworthy evidence for that check. An internally generated message may never have crossed an external receiving system. A forwarded or transformed message can also present a different evidence chain. Missing evidence proves neither success nor failure.

Keep time in mind. Authentication headers capture what a receiving system observed when the message arrived. A DNS lookup today shows today's records. Keys rotate and sender policies change, so current DNS can differ from the configuration used at receipt. Do not overwrite historical evidence with a fresh lookup, and do not make blind DNS changes from one result. First establish the actual sender, domain, selector, route and time involved.

Headers are ordered records added by the systems that handled the message. Start with the receiver's Authentication-Results, then compare From, Reply-To, Return-Path, DKIM signing domain and the relevant Received lines. Trust depends on who added a header; text in an untrusted message can imitate a result, which is why DemoPost only reports authentication where suitable evidence is available.

Source inspection helps with a different class of problem. Compare the HTML and text parts, content type, character encoding, link targets and image references. Download the original .eml when available if a sending-provider specialist needs the exact message. Avoid sharing it publicly: even a test message can contain addresses, internal hostnames or one-time links.

• Send through the same application workflow and provider configuration you intend to demonstrate or release.
• Use fictional user data and a distinct DemoPost reference for the scenario.
• Confirm recipient, From, Reply-To, subject, template values, links and attachment metadata.
• Read both HTML and plain text; check responsive widths without assuming client emulation.
• Treat remote images and links as destinations to inspect before loading or visiting.
• Read SPF, DKIM and DMARC results with their domains and alignment—not as generic trust badges.
• Separate an explicit failure from unavailable evidence.
• Record the receipt time before comparing against current provider or DNS configuration.
• Escalate the original .eml and exact evidence to the sending provider or domain owner when needed.
• Send a fresh test after a deliberate configuration change; do not stack speculative DNS edits.

For protocol details, consult the IETF standards for SPF (RFC 7208), DKIM (RFC 6376), DMARC (RFC 9989) and Authentication-Results (RFC 8601). Google also publishes practical email sender guidance. These sources explain the protocols; your sending provider remains the right place to confirm its specific domain-verification steps.