MODLAN EMAIL FORENSICS LAB · V139
Examine the message without pretending the header knows more than it does.
Browser-local by design: local EML and raw-source examination plus optional synthetic examiner scenarios built around evidence provenance, authentication limits, trust-horizon reasoning and business-control verification. The shared MODLAN forensic engine runs locally in your browser; message bytes are never uploaded or stored by the public lab.
WHY THIS EXISTS
Authentication data answers narrower questions than most people think.
SPF, DKIM, DMARC, Authentication-Results, Received headers and identity fields are useful evidence. They are not interchangeable with authorship, legitimacy, authorization or intent. The lab makes that distinction visible in live local examination and optional controlled examiner scenarios.
Separate claim from verification
Authentication-Results is treated as a preserved assertion until an independent trust basis exists.
Reason across relationships
Trace, authserv-id, SMTP identity, visible From, Reply-To and DKIM context are examined together rather than scored as isolated tells.
Calibrate confidence
A correct answer reached with unjustified certainty is not treated as the same professional performance as a well-supported bounded conclusion.
Return to the business control
When authenticity remains uncertain, a trusted verification procedure can resolve the operational decision without requiring impossible certainty from the artifact.
Open an .EML file or paste raw email source.
Processed locally in this browser. Message bytes are not uploaded to MODLAN, no account is required, and no telemetry or server-side evidence record is created.
SYNTHETIC EXAMINER SCENARIOS · V132
Reason from the evidence. Then state what the evidence cannot prove.
Three optional synthetic examiner scenarios run entirely in your browser against the same shared forensic engine. They are training scenarios, separate from the live local email intake above. Nothing is uploaded, no attempt is stored, and no score is transmitted.
Hosted transactional mail
Decide whether those domain differences alone support a fraud conclusion.
TRACE HOPS1
AUTH RECORDS1
DKIM1
SIGNALS4
HIGHESTINFO
EVIDENCE BEFORE VERDICT
ASSERTED ≠ VERIFIED
DERIVED ≠ ATTRIBUTED
AUTHENTICATION PASS ≠ LEGITIMACY
STRUCTURAL CORROBORATION ≠ RECEIVER PROOF
INSUFFICIENT EVIDENCE IS A VALID PROFESSIONAL CONCLUSION
Preserved claims versus derived context
SPF=pass · DKIM=pass · DMARC=pass
Trace corroboration: trueRoute and trust-horizon context
relay.example-esp.net (relay.example-esp.net [203.0.113.40])
STRUCTURALLY CORROBORATEDDo not collapse infrastructure identity into authorship
VISIBLE FROMclaims@northstar-example.com
REPLY-TOAbsent
RETURN-PATH<bounce+78122@bounce.example-esp.net>
MESSAGE-ID DOMAINmailer.example-esp.net
DKIM d=northstar-example.com
PUNYCODENOT OBSERVED
Every signal carries severity and provenance
northstar-example.com → bounce.example-esp.net (relationship: ORG_UNDETERMINED)
SPF authenticates an envelope identity, not the visible From address, and a separate bounce domain is normal ESP practice. DMARC alignment must be evaluated separately and cannot be settled here without DNS.northstar-example.com → mailer.example-esp.net (relationship: ORG_UNDETERMINED)
Message-ID is generated by the submitting system, so divergence is expected for hosted, relayed and gateway mail.northstar-example.com:content-type, northstar-example.com:return-path
A field omitted from h= is not protected by that DKIM signature, but omission does not establish that the field was changed or malicious.pass on MAILFROM=bounce.example-esp.net; visible From=northstar-example.com
SPF authenticates an RFC5321 MAIL FROM or HELO/EHLO identity as declared by the receiver; it does not authenticate the person or, by itself, the RFC5322 visible From address.Commit to a verdict, confidence, and evidence basis before debrief.
PROVENANCE VOCABULARY
Authority should be visible, not implied by color.
Read directly from supplied bytes using the current parser.
Claimed by the artifact or a preserved header; not independently verified by MODLAN.
Deterministically computed from supplied bytes and reproducible from the same input.
Reserved for a cryptographic check completed using examiner-supplied validation material.
Reserved for a validation performed against an external source at a recorded analysis time.
Available material is insufficient to determine the proposition.
PUBLIC LAB / PROFESSIONAL EXAMINATION
The public lab supports browser-local technical examination. It does not create custody or an expert conclusion.
Real matters requiring acquisition controls, evidence retention, full cryptographic validation, external-source verification, examiner attestation or litigation support belong in a scoped professional engagement.