[{"data":1,"prerenderedAt":299},["ShallowReactive",2],{"/blog/read-received-headers":3,"/blog/read-received-headers-surround":288},{"id":4,"title":5,"authors":6,"badge":12,"body":14,"date":276,"description":277,"extension":278,"image":279,"indexable":281,"meta":282,"navigation":281,"path":283,"reviewedBy":284,"seo":285,"stem":286,"updated":276,"__hash__":287},"posts/3.blog/14.read-received-headers.md","How to Read Received Headers and Trace an Email Delivery Path",[7],{"name":8,"to":9,"avatar":10},"Once Email Engineering","/about",{"src":11},"/images/authors/default-cartoon-author.webp",{"label":13},"Delivery analysis",{"type":15,"value":16,"toc":266},"minimal",[17,26,29,34,44,54,57,94,97,101,107,110,116,119,145,148,152,155,158,161,181,189,193,199,202,212,216,221,233,237,248,256,260,263],[18,19,20,21,25],"p",{},"An email can pass through an application server, an outbound relay, a filtering service and the recipient's mail exchanger before it reaches an inbox. Each receiving SMTP server normally adds a ",[22,23,24],"code",{},"Received"," field. Reading those fields can help locate a delay, identify the server that handed mail to your provider and build a delivery timeline.",[18,27,28],{},"The fields are diagnostic evidence, not a complete chain of custody. A sender can add fake lines before transmission, clocks can disagree and private infrastructure may hide or rewrite details. Use the trace together with provider logs, authentication results and the context of the message.",[30,31,33],"h2",{"id":32},"what-a-received-field-records","What a Received field records",[18,35,36,43],{},[37,38,42],"a",{"href":39,"rel":40},"https://www.rfc-editor.org/rfc/rfc5321#section-4.4",[41],"nofollow","RFC 5321 section 4.4"," requires an SMTP server that receives a message for delivery or further processing to prepend trace information. A typical field looks like this:",[45,46,52],"pre",{"className":47,"code":49,"language":50,"meta":51},[48],"language-text","Received: from outbound.example.com (outbound.example.com [192.0.2.10])\n        by mx.example.net with ESMTPS id ABC123\n        for \u003Crecipient@example.net>;\n        Mon, 03 Aug 2026 10:30:04 +0000\n","text","",[22,53,49],{"__ignoreMap":51},[18,55,56],{},"Common clauses answer different questions:",[58,59,60,67,73,79,85,91],"ul",{},[61,62,63,66],"li",{},[22,64,65],{},"from"," describes the host presented by the sending side and may include the address observed on the network connection;",[61,68,69,72],{},[22,70,71],{},"by"," identifies the server that accepted this hop and wrote the field;",[61,74,75,78],{},[22,76,77],{},"with"," describes the transport or protocol variant, such as ESMTP or encrypted SMTP;",[61,80,81,84],{},[22,82,83],{},"id"," is a queue or transaction identifier useful when an administrator can search that server's logs;",[61,86,87,90],{},[22,88,89],{},"for"," may identify one envelope recipient, although it is optional and can be removed for privacy;",[61,92,93],{},"the date after the semicolon records when the receiving server accepted the message, including a numeric time-zone offset.",[18,95,96],{},"Not every field contains every clause. Gateways and non-SMTP systems can produce unfamiliar formats. RFC 5321 explicitly tells receiving systems to be robust with unexpected trace formatting rather than rejecting a message merely because a trace line looks unusual.",[30,98,100],{"id":99},"read-the-route-from-the-bottom-upward","Read the route from the bottom upward",[18,102,103,104,106],{},"SMTP servers prepend new ",[22,105,24],{}," fields above the existing ones. The newest receiving hop is therefore at the top of the header block; the earliest recorded hop is usually at the bottom.",[18,108,109],{},"Consider this simplified trace:",[45,111,114],{"className":112,"code":113,"language":50,"meta":51},[48],"Received: from filter.example.net by mx.recipient.example;\n        Mon, 03 Aug 2026 10:30:07 +0000\nReceived: from outbound.sender.example by filter.example.net;\n        Mon, 03 Aug 2026 10:30:04 +0000\nReceived: from app.internal.example by outbound.sender.example;\n        Mon, 03 Aug 2026 10:29:59 +0000\n",[22,115,113],{"__ignoreMap":51},[18,117,118],{},"Read it as:",[120,121,122,132,138],"ol",{},[61,123,124,127,128,131],{},[22,125,126],{},"app.internal.example"," handed the message to ",[22,129,130],{},"outbound.sender.example",".",[61,133,134,135,131],{},"The outbound server handed it to ",[22,136,137],{},"filter.example.net",[61,139,140,141,144],{},"The filter handed it to the recipient's ",[22,142,143],{},"mx.recipient.example"," server.",[18,146,147],{},"Do not sort the fields by their visible timestamps. The protocol-defined field order is more useful because server clocks may be wrong or unsynchronised. Convert each timestamp to one time zone only when estimating delay, and preserve the original value in any evidence record.",[30,149,151],{"id":150},"calculate-delay-carefully","Calculate delay carefully",[18,153,154],{},"For each adjacent pair, subtract the earlier receiving time from the later one after applying the numeric offsets. A large positive gap can indicate queueing, rate limiting, a temporary network failure or processing at the next service. It does not identify the cause by itself.",[18,156,157],{},"A negative gap usually points to clock skew, a parsing mistake or an untrusted field—not time travel and not automatic proof of forgery. Check whether the offsets were handled correctly and whether the two lines were written by systems you control.",[18,159,160],{},"When investigating your own application, correlate the trace with:",[58,162,163,166,169,175,178],{},[61,164,165],{},"the UTC time at which the application requested the message;",[61,167,168],{},"the sender's queue ID and delivery log;",[61,170,171,172,174],{},"the first ",[22,173,24],{}," field written by infrastructure you trust;",[61,176,177],{},"the time the recipient provider reports accepting or displaying it;",[61,179,180],{},"any retry status or SMTP response recorded by the sending system.",[18,182,183,184,188],{},"The ",[37,185,187],{"href":186},"/blog/email-testing-checklist","developer email testing checklist"," explains how to record the request-to-arrival timeline without treating one inbox observation as the whole delivery system.",[30,190,192],{"id":191},"decide-which-hop-you-can-trust","Decide which hop you can trust",[18,194,195,196,198],{},"The topmost ",[22,197,24],{}," field was added by the server closest to the mailbox you are viewing. If that mailbox provider is trusted, this field is usually the strongest starting point: it can report the network address from which the provider actually accepted the message.",[18,200,201],{},"Work downward only as far as the fields remain consistent with infrastructure you recognise. Lines allegedly created before the message entered a trusted provider can be fabricated by the sender. A malicious sender cannot normally rewrite fields already added later by the recipient's systems, but it can place plausible-looking trace text in the message before those systems see it.",[18,203,204,205,207,208,211],{},"Hostnames also require context. A ",[22,206,65],{}," name may come from an SMTP greeting, reverse DNS or local configuration. A private address such as ",[22,209,210],{},"10.0.0.0/8"," can describe an internal hop but cannot be traced directly across the public Internet. An IP geolocation result is approximate and does not establish the identity or physical location of the author.",[30,213,215],{"id":214},"received-fields-do-not-replace-authentication","Received fields do not replace authentication",[18,217,218,220],{},[22,219,24],{}," fields describe transport hops. SPF, DKIM and DMARC evaluate different evidence about domain authorisation, signatures and alignment. A route that looks ordinary can carry a malicious message, and a legitimate forwarded message can have a complicated route.",[18,222,223,224,228,229,232],{},"Use the ",[37,225,227],{"href":226},"/blog/corecomponent","SPF, DKIM and DMARC guide"," to interpret authentication results separately. Do not infer that the visible ",[22,230,231],{},"From"," address controlled every host in the route, or that a familiar relay makes the content safe.",[30,234,236],{"id":235},"use-the-local-header-analyser-without-oversharing","Use the local header analyser without oversharing",[18,238,239,240,244,245,247],{},"The Once Email ",[37,241,243],{"href":242},"/tools/email-header-analyzer","email header analyser"," extracts ",[22,246,24],{}," hops, authentication results and repeated fields in the browser. Paste header fields only—never a password, verification code, message body or attachment. The tool does not contact the listed servers, verify their logs or prove that a field is genuine.",[18,249,250,251,255],{},"Before sharing results, replace personal addresses, public IP addresses, queue IDs and internal hostnames while retaining the order and time offsets needed to reproduce the issue. The ",[37,252,254],{"href":253},"/blog/safe-email-test-evidence","test evidence redaction guide"," provides a safer reporting pattern.",[30,257,259],{"id":258},"a-reliable-interpretation-checklist","A reliable interpretation checklist",[18,261,262],{},"Start at the top to identify the final receiving system, then reconstruct the path from the bottom upward. Trust the field order before the clocks. Normalise time zones, flag negative or unusually long intervals, and mark the boundary between trusted and sender-controlled infrastructure. Correlate queue IDs with authorised server logs when available.",[18,264,265],{},"Most importantly, state the limit of the conclusion. A trace may support “the recipient provider accepted this connection from this relay at this time.” It usually cannot prove who wrote the message, whether every earlier hop is genuine or whether its links and attachments are safe.",{"title":51,"searchDepth":267,"depth":267,"links":268},2,[269,270,271,272,273,274,275],{"id":32,"depth":267,"text":33},{"id":99,"depth":267,"text":100},{"id":150,"depth":267,"text":151},{"id":191,"depth":267,"text":192},{"id":214,"depth":267,"text":215},{"id":235,"depth":267,"text":236},{"id":258,"depth":267,"text":259},"2026-08-03","Follow Received header fields in the correct order, compare timestamps safely and recognise the limits of hostnames, IP addresses and untrusted trace data.","md",{"src":280},"/images/blog/read-received-headers-cover.webp",true,{},"/blog/read-received-headers","Once Email technical review",{"title":5,"description":277},"3.blog/14.read-received-headers","qqLVpKxBinmeaHV3Ed1t7hVJIteT9uDuUM5AyQht1KY",[289,294],{"title":290,"path":291,"stem":292,"description":293,"children":-1},"Why Some Websites Reject Disposable Email Addresses","/blog/why-sites-reject-disposable-email","3.blog/13.why-sites-reject-disposable-email","Understand the account-recovery, abuse, support and risk reasons behind disposable-email restrictions—and what legitimate users should do instead of evading them.",{"title":295,"path":296,"stem":297,"description":298,"children":-1},"A Safe Checklist Before Downloading an Email Attachment","/blog/attachment-safety-checklist","3.blog/15.attachment-safety-checklist","Check the request, sender, file name, type and handling environment before downloading an attachment—and know what email previews and scanners cannot prove.",1785734006180]