Header Triage
{{ triageHeadline }}
{{ summaryIdentityLine }}
{{ triageBadgeText }} {{ coreAuthBadgeText }} {{ routeBadgeText }} {{ alignmentBadgeText }} {{ totalPathDelayReadable }} {{ warningsCount }} warning(s) Score {{ qualityScore }}/10
{{ tag.text }}
Email header analyzer
Paste headers from message source, or drop one .eml/.txt file; body text after the first blank line is ignored.
{{ headerSourceMeta }}
{{ headerActionHint }}
Browser-only parse: no DNS lookup, DKIM cryptographic recheck, or message-body scan.
Accepted: 0 for all visible hops, or an integer such as 5 to inspect the newest five.
hops
Accepted: 5 seconds or more; start at 120 for ordinary mail, lower it for tight SLA reviews.
seconds
Turn on only for known forwarded/list mail; parsed SPF evidence still appears in Auth Matrix.
{{ ignore_spf ? 'On' : 'Off' }}
Turn on only when post-signing modification is expected; DKIM domains and signed headers still show.
{{ ignore_dkim ? 'On' : 'Off' }}
Turn on for route-only triage; Alignment Summary still reports relaxed and strict matches.
{{ ignore_dmarc ? 'On' : 'Off' }}
Field Value Copy
{{ key }} {{ value || '—' }}
Warning {{ index + 1 }} {{ warning }}
# From By Protocol Delay (s) Cumulative Context Copy
{{ hop.idx }} {{ hop.from || '—' }} {{ hop.by || '—' }} {{ hop.with || '—' }} {{ hop.delay ?? '—' }} {{ hop.cumulative ?? '—' }}
{{ hop.routeLabel }}
{{ hop.routeNote }}
No Received hops found
Paste an original header block with Received lines to build the relay ledger.
Mechanism Result Domain / Scope Alignment Evidence Copy
{{ row.label }} {{ row.result || '—' }} {{ row.scope || '—' }} {{ row.alignment || '—' }} {{ row.evidence || '—' }}
Field Value Copy
{{ row.label }} {{ row.value }}
Group Check Severity Result Copy
{{ row.group }} {{ row.check }} {{ row.severity }} {{ row.result }}
No zero-lookup findings available
Parse a complete header block to populate sender, route, auth, and leak checks.
 
{{ headerBlock }}

                

            


        

    

                

                

                    

                        

                            Tags: DNS, Diagnostics, Email, Security
                        

                        

                            
                            
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                    

                

                

                    

                                                                                

                                
                                    
                                        DMARC Validation Report
                                                                                    Check a domain's DMARC record, review policy tags, report destinations, alignment, rollout status, and control scores from DNS.
                                                                            
                                    
                                
                            

                                                                                

                                
                                    
                                        BIMI Validation Report
                                                                                    Validate BIMI for a domain and selector with DNS, DMARC, SVG logo, and certificate evidence checks, then review readiness notes.
                                                                            
                                    
                                
                            

                                                                                

                                
                                    
                                        DMARC DNS Record Generator
                                                                                    Build a DMARC DNS TXT record for a domain, stage policy rollout, normalize report URIs, and flag external-report authorization.
                                                                            
                                    
                                
                            

                                                                                

                                
                                    
                                        DKIM Validation Report
                                                                                    Check a DKIM selector for a signing domain, review TXT tags, key size, testing flags, and resolver evidence in a readable report.
                                                                            
                                    
                                
                            

                                            

                

            

        
                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  

    
    
When a message looks wrong, the visible sender and subject are only the front of the story. The delivery trail sits above the body in the message header, where mail servers add trace fields, authentication checks, routing clues, and identifiers that ordinary mail clients hide. That trail can explain why a message arrived late, why authentication failed after forwarding, or why a payment request deserves a second channel of verification.

    
An email header is not a single verdict. It is a set of statements written by different systems at different moments. Each Received field is normally prepended by a server that accepted or relayed the message, so the newest hop appears first and older hops appear lower down. Authentication summaries such as Authentication-Results describe checks performed by a receiving system, while fields like From, Reply-To, Return-Path, Message-ID, and DKIM-Signature expose different parts of sender identity.

    
Good header review starts by separating delivery evidence from identity evidence. A route may look normal while the reply destination points somewhere else. SPF may fail because a forwarder changed the sending host, while DKIM still passes because the signed content survived. DMARC alignment can fail when the authenticated domain is real but does not line up with the visible From domain. Those differences matter because attackers often rely on the gap between what a user sees and what the mail system actually authenticated.

    

      

        
        
          

            Question
            Header evidence to inspect
            Common trap
          

        
        
          

            Why was delivery slow?
            Received timestamps, relay names, protocols, and cumulative delay.
            Blaming the last server when the largest gap happened earlier in the path.
          

          

            Is the sender identity coherent?
            From, Reply-To, Return-Path, SPF domain, DKIM d= domain, and DMARC alignment.
            Treating a display name or address alone as proof of control over a domain.
          

          

            Did forwarding or a list affect authentication?
            ARC fields, list headers, automation headers, SPF outcome, DKIM outcome, and intermediary domains.
            Calling every SPF failure spoofing even when a forwarder or list server is visible.
          

          

            What should be redacted before sharing?
            Internal hostnames, private IP addresses, user addresses, message identifiers, and gateway labels.
            Posting a raw header that exposes internal infrastructure or incident details.
          

        
      

    


    

      Email header triage flow from header fields to route, authentication, timing, findings, and warnings
    


    
Headers are strongest when they are treated as clues, not as courtroom proof. A trusted receiving gateway can record useful authentication results, but a copied block of text can still be incomplete, reordered, or forged before it reached that boundary. A header also says little about whether the message body contains a malicious link, whether an attachment is safe, or whether the sender had a legitimate business reason to ask for an action.

    
For support, abuse, or incident response work, preserve the original message source before editing it. Use the header to narrow the next check: gateway logs for delays, DNS and signing records for authentication problems, identity records for sender mismatch, and user-context review for content risk.

  






  

    
How to Use This Tool:

    
Use an original message source whenever possible. Forwarded copies, screenshots, and copied visible message text often remove the Received, authentication, and DKIM fields needed for useful header analysis.

    
    
      
  1. Copy the full raw header block from the mail client, or choose a local .eml or .txt file with Browse .eml/.txt. The file path is not enough; the content must include the header lines.
    2. 
      
  2. Paste or drop the text into Raw email header. The source badge should show the line and character count, which is a quick check that the header was actually loaded.
    3. 
      
  3. Use Parse header or wait for the browser-side parse to refresh. If a full message source is pasted, analysis stops at the first blank line and ignores the body.
    4. 
      
  4. Leave Hop limit at 0 for the full visible path. Set a positive number when you only want the newest Received hops to affect the relay ledger, warnings, charts, and score.
    5. 
      
  5. Keep Slow-hop threshold at 120 seconds for ordinary delivery triage, or lower it when you are reviewing a tighter service-level complaint.
    6. 
      
  6. Turn on Ignore SPF in score, Ignore DKIM in score, or Ignore DMARC in score only when you have a known forwarding, list, gateway, or route-only reason. The evidence still appears in the Auth Matrix and Alignment Summary.
    7. 
      
  7. Start with Triage Brief, then compare Relay Ledger, Relay Delay Bars, Delay Accumulator, Auth Matrix, Alignment Summary, Signed Header Coverage, and Findings Ledger before exporting or sharing results.
    8. 
    

    
If Relay Ledger says no hops were found, return to the raw source and make sure the copied block includes lines that begin with Received:. If a selected file is rejected, use one text-like .eml or .txt file under the size limit shown by the browser error.

  






  

    
Interpreting Results:

    
Read the warnings and identity fields before leaning on the score. A high score means the visible header evidence is internally coherent under the checks here. It does not prove that the sender is safe, that links are harmless, or that the message was expected. A low score means something visible deserves review, but forwarding, mailing lists, clock skew, and partial authentication summaries can produce noisy results.

    
The most useful pattern is usually a combination of route, authentication, and identity evidence. A single SPF failure is weaker than SPF failure plus DMARC relaxed miss plus Reply-To mismatch. A long relay delay is more useful when the slow hop identifies a specific handoff. ARC and list headers can explain why authentication changed, but they still need trust decisions from the receiving gateway.

    

      

        
        
          

            Output cue
            Best reading
            Verification step
          

        
        
          

            DMARC relaxed alignment: No
            Neither the parsed SPF domain nor any parsed DKIM signing domain shares the expected organizational domain with Header.From.
            Compare Header.From, SPF domain, DKIM domains, and the original gateway authentication record before trusting the visible sender.
          

          

            Slow hops >= 120 s
            One or more adjacent Received timestamps cross the current slow-hop threshold.
            Use the Relay Ledger row number, relay names, and Delay Accumulator to search gateway logs around that handoff.
          

          

            Negative hop delay
            A newer hop appears older than the next older hop, which points to clock skew, malformed dates, pasted order problems, or forged trace data.
            Check server time synchronization and compare the original message source against the mail gateway copy.
          

          

            ARC chain present
            Forwarding or intermediary preservation may be involved.
            Use the receiving gateway's ARC trust rules; visible ARC fields alone do not prove the seals are valid.
          

          

            Reply-To domain differs from Header.From
            Replies may go to a different domain than the visible sender domain.
            Verify the requested action out-of-band, especially for invoices, credential resets, shipping changes, or bank details.
          

          

            Origin IP exposed
            The header includes a field such as X-Originating-IP or private/bogon route information.
            Preserve it for internal investigation, but redact it before external sharing when it exposes people or infrastructure.
          

        
      

    

  






  

    
Technical Details:

    
Message headers follow the Internet Message Format model of named fields separated from the body by a blank line. Long fields may be folded over continuation lines, and repeated trace or authentication fields are normal. For analysis, the header block is isolated, folded lines are unfolded, and repeated field names are preserved because real delivery paths often contain several Received, Authentication-Results, ARC-Seal, and DKIM-Signature entries.

    
Received trace fields are usually prepended, so the first visible hop is the most recent server. Hop delay is inferred by subtracting the timestamp of the next older hop from the timestamp of the newer hop. Positive values add to cumulative delay, values at or above the chosen slow-hop threshold become slow-hop findings, and negative values are treated as ordering or clock anomalies rather than useful delivery time.


    
Formula Core

    
Hop delay uses adjacent parsed Received timestamps. The newest visible hop is indexed first.

    

      
        
          hop delay secondsi
          =
          
            
              newer hop timei
              -
              older hop timei
            
            1 second
          
        
      
    

    
Cumulative delay counts only positive hop delays so that one bad clock does not subtract from the rest of the route.

    

      
        
          cumulative delay
          =
          
            ∑
            i=1
            n
          
           max
          (
          0
          ,
          hop delay secondsi
          )
        
      
    

    
The 0 to 10 header score is an additive triage score. Authentication ignore switches count the selected mechanism as neutral for scoring, but they do not remove the parsed evidence from the result tables.

    

      
        
          score
          =
          route
          +
          clock
          +
          SPF
          +
          DKIM
          +
          DMARC
          +
          alignment
          +
          delay
          ,
          0
          ≤
          score
          ≤
          10
        
      
    


    
Rule Core

    

      

        
        
          

            Score part
            Points
            Boundary used
            Reason to verify
          

        
        
          

            Route
            1
            At least one parsed Received hop.
            Forwarding, privacy filtering, and missing source can shorten the visible route.
          

          

            Clock ordering
            1
            No negative hop delay warning.
            Clock skew and copied trace lines can mimic route tampering.
          

          

            SPF
            2
            Parsed SPF result is pass, or SPF is ignored in score.
            SPF is tied to the envelope sender path, so forwarding can break it.
          

          

            DKIM
            2
            Parsed DKIM result is pass, or DKIM is ignored in score.
            A visible DKIM field is not the same as a fresh cryptographic verification.
          

          

            DMARC verdict
            2
            Parsed DMARC result is pass, or DMARC is ignored in score.
            DMARC depends on authentication plus alignment with the visible From domain.
          

          

            Relaxed alignment
            1
            SPF or DKIM aligns with Header.From under relaxed organizational-domain matching, or DMARC is ignored in score.
            The organizational-domain comparison is a lightweight approximation, not a full public suffix list evaluation.
          

          

            Visible delay
            1
            Total positive visible path delay is finite and less than 3600 seconds.
            Hidden queueing before the first visible hop cannot be measured from the pasted header.
          

        
      

    


    
Authentication evidence comes from visible authentication summaries and signature headers. SPF is associated with the envelope sender domain, often shown as smtp.mailfrom or inferred from Return-Path. DKIM evidence includes the signing domain in d=, the selector in s=, the canonicalization choice, the algorithm, body hash presence, optional expiry, optional body length tag, and the signed-header list in h=. DMARC alignment compares the visible Header.From domain with passing SPF or DKIM identity. Strict alignment requires an exact domain match; relaxed alignment accepts an organizational-domain match.

    
ARC fields are interpreted as forwarding context rather than as direct proof. An ARC chain can preserve earlier authentication assessments through a mediator, but trust depends on whether the final receiver accepts that chain. The analyzer can count ARC instances, inspect sequencing, and surface cv= values, but seal validity requires cryptographic validation by a mail system.

    

      

        
        
          

            Field or clue
            What it contributes
            Important limit
          

        
        
          

            Authentication-Results
            SPF, DKIM, DMARC, ARC result text and supporting domains from a receiver or intermediary.
            It is a reported result, not a fresh re-run of the tests.
          

          

            DKIM-Signature
            Signing domain, selector, algorithm, canonicalization, signed headers, body hash tag, expiry, and body-length tag.
            Only a mail verifier with DNS and message body access can validate the signature.
          

          

            Reply-To
            Reply destination compared with Header.From for mismatch clues.
            Legitimate ticketing systems and mailing lists may use different reply domains.
          

          

            Message-ID
            Presence, domain clue, From-domain comparison, and timestamp-like token hint.
            Message identifiers are generated by hosts and are not reliable human-readable provenance by themselves.
          

          

            List and automation headers
            List-ID, unsubscribe, Auto-Submitted, and Precedence clues that explain bulk, list, or automated mail.
            They may explain authentication noise without proving the message is wanted or safe.
          

          

            Private or bogon IPs
            Route privacy and internal infrastructure clues from visible hops.
            They are useful in internal investigations and often inappropriate for external sharing.
          

        
      

    

    
The Signed Header Coverage chart counts whether a practical core set of fields, including From, Subject, Date, Message-ID, and To, appears in the DKIM signed-header list. RFC 6376 requires the From field to be signed; the wider set is a header-side review aid for spotting thin or unusual signatures.

  






  

    
Limitations and Privacy Notes:

    
This is a header triage aid, not a mail gateway verdict or malware scanner. It is most useful for deciding what to inspect next.

    
    
      
  • The pasted header is parsed in the browser, with no DNS lookup, DKIM re-signature check, ARC seal validation, reputation lookup, attachment scan, or message-body scan.
    • 
      
  • Authentication results are only as trustworthy as the system that wrote them. A forged, copied, or incomplete header block can mislead any text parser.
    • 
      
  • The relaxed alignment check uses a lightweight organizational-domain approximation and should not replace gateway DMARC enforcement data.
    • 
      
  • Header text can contain personal addresses, internal hostnames, private IP addresses, routing identifiers, and ticket references. Redact sensitive values before sharing outside the incident or support context.
    • 
      
  • Charts and exports repeat parsed header data. Review them with the same confidentiality rules as the raw message source.
    • 
    

  






  

    
Worked Examples:

    
Normal two-hop delivery. A raw header shows two Received hops, SPF result: pass, DKIM result: pass, DMARC result: pass, and DMARC relaxed alignment: Yes. Total path delay (s) is 125, Slow hops >= 120 s is 1, and the Triage Brief still deserves a relay check because the delay crossed the default threshold by a small margin.

    
Forwarded message with noisy SPF. A mailing-list header contains ARC fields and List-ID. SPF fails after the intermediary hop, but DKIM passes with a signing domain that aligns to Header.From. If Ignore SPF in score is turned on, Score overrides records SPF and the Auth Matrix still keeps the failing SPF evidence for review.

    
Slow delivery complaint. A customer reports a message that arrived 20 minutes late. The Relay Ledger shows hop #3 with Delay (s) near 780, and the Delay Accumulator jumps at the same point. The best follow-up is the handoff shown in that row, not the last hop in the chain.

    
Payment redirection risk. Header.From is vendor.example, Reply-To domain is a lookalike domain, DMARC relaxed alignment is No, and Message-ID domain does not match the sender. Treat that combined pattern as an out-of-band verification trigger before acting on invoice, bank, or credential instructions.

  






  

    
FAQ:

    

      Does a coherent header mean the email is safe?
      
No. A coherent header means the visible route, authentication summaries, and identity clues do not contradict the checks here. You still need content review, link inspection, attachment scanning, sender context, and gateway logs for a security decision.

    

    

      Why can forwarded mail fail SPF?
      
SPF checks whether the sending host is authorized for the envelope sender domain. A forwarder can change the host that delivers the message while preserving the original visible sender, so SPF may fail even when DKIM or ARC provides better forwarding context.

    

    

      Why does the DKIM chart not prove the signature is valid?
      
The chart reads the visible DKIM-Signature signed-header list and counts coverage for a core set of headers. It does not fetch DNS keys, hash the body, or verify the signature.

    

    

      What should I do when Relay Ledger is empty?
      
Go back to the original message source and copy the top header block, including lines that start with Received:. A forwarded message body or screenshot usually does not include enough route data.

    

    

      Can I paste the whole message source?
      
Yes. The parse stops at the first blank line, so the header block is used and the message body after it is ignored. For file input, use one local .eml or .txt file.

    

    

      Are the pasted headers uploaded for analysis?
      
The header text is parsed by the browser page and the checks do not perform DNS or mail-server lookups. Because headers can contain sensitive incident data, follow your organization's policy before pasting or exporting raw evidence.

    

  






  

    
Glossary:

    

      
Received header

      
A trace field added by a mail server that accepted or relayed the message.

      
Authentication-Results

      
A header field where a receiver reports SPF, DKIM, DMARC, ARC, or related authentication outcomes.

      
SPF

      
Sender Policy Framework, a DNS-based check for whether a host may send using an envelope sender domain.

      
DKIM

      
DomainKeys Identified Mail, a domain signature over selected headers and body content.

      
DMARC alignment

      
The comparison between the visible Header.From domain and the authenticated SPF or DKIM identity.

      
ARC

      
Authenticated Received Chain, a way for intermediaries to carry authentication results through forwarding.

      
Return-Path

      
The delivered form of the envelope sender address, often used when reviewing SPF identity.

      
Hop delay

      
The time difference inferred between adjacent parsed Received timestamps.

    

  






  

    
References: