The tool page is tamperbox.dev/email-header-analyzer. It opens on a working example: an order confirmation sent through a mail service, held for 38 seconds at one hop, with SPF passing for the service rather than the brand. This page is the long version: how the header block is read, every rule applied to the route, the authentication results and the identities, which parts of which standards the tool follows and where it stops, what each finding means, and what to do about it.

Where processing happens: the whole header block is parsed in your browser and never uploaded. Only when you choose Look up hop addresses are the public IP addresses of the hops, and nothing else, sent to the Tamperbox server for public DNS and network registry lookups. Nothing is stored.

What the tool answers

Every server that handles a message adds a Received header on top; the receiving server adds an Authentication-Results header with what it verified. The tool answers:

1. Which route did the message take, and where did it wait? The Received hops, oldest first, with delays and TLS.
2. Did the sender prove who they are? SPF, DKIM and DMARC as the receiver recorded them.
3. Do the identities line up? From, Return-Path and the DKIM signing domain compared exactly; Reply-To checked against From.
4. Who owns the sending addresses? On request only, through public DNS and the network registry.

It does not verify any signature; it reads what the receiver wrote.

Inputs

Raw headers

Paste the header block of a message: Gmail, open the message, the three-dot menu, “Show original”; Outlook on the web, the three-dot menu, “View message source”; Apple Mail, View, Message, All Headers. Parsing starts as soon as the text changes. Everything after the first blank line is treated as the body and ignored; folded continuation lines are joined back onto their field. Text with no Name: value lines is refused with “No headers found”.

An .eml file

Drop the file anywhere on the page, or use Open file, up to 5 MiB. Only the header block is read into the field; the body never reaches the page.

Reading the result

Verdict and chips

The verdict leads with what the receiver reports: DMARC passed (through DKIM or SPF when one aligns) or failed for the From domain, raised to a CHECK when Reply-To points elsewhere; without a DMARC result it names the first failure, the Reply-To difference, clock skew, or simply that the route was traced. The detail gives the hop count, the end-to-end time and the longest wait. The chips show each recorded result, the hops with their time, and a Reply-To warning; each is a button that scrolls to the section that explains it.

Findings

Everything found, worst first; passes fold into one line. An INFO finding always reminds you that these are reported results. The finding reference lists them all.

Take it further

Links that carry a value derived from the message into another tool: the DKIM key that signed it (selector and domain from the signature), SPF for the bounce domain, the DMARC policy of the From domain, the network behind the first public hop address, and the Date header as a Unix timestamp. Each opens the destination with the value already in its box; nothing is put in the URL.

History

History logs every Break it change with the headers it replaced; Revert undoes the newest, Reset input returns to what you entered. There are no Heal it repairs: headers are evidence, not something to fix.

Route

One row per hop, oldest first: the servers it went from and to, the address with its kind (sample, non-public), the protocol, a TLS badge, and the delay the previous server added, drawn as a bar. The longest wait over 30 seconds is marked. Under the route, Look up hop addresses sends the public addresses to the server and writes the network, registry country, AS number and reverse name next to each hop.

Authentication

The three results as the receiver recorded them, with the identity each one checked, and a table comparing the From domain with the Return-Path domain and every DKIM signing domain.

Message and every header

The identity fields with what each one means, and the complete header list with a filter. Values are shown as written: encoded words such as =?UTF-8?B?...?= in From or Subject are not decoded.

Method

Each rule below names the section of the specification it comes from. Where a rule is a Tamperbox choice and no specification asks for it, the source says “none”.

Reading the header block

The text is cut at the first blank line, the boundary RFC 5322 section 2.1 defines between the header section and the body. A line that holds only spaces or tabs also counts as blank here. Lines starting with a space or tab are joined to the field above: “Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP” (RFC 5322 section 2.2.3). The tool trims the continuation line and joins it with one space, so runs of white space inside a folded value become a single space.

A field is name: value. The name must be printable US-ASCII except the colon, the rule of RFC 5322 section 2.2; a line that is neither a field nor a continuation is skipped without a message. With no fields at all, the input is refused. Field names are matched without regard to case.

Route: hop order and clauses

Received headers are reversed, so the first hop is the oldest. That order is reliable because “SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines” (RFC 5321 section 4.4).

From each Received header the tool takes the from, by and with clauses and the timestamp after the last semicolon, following the Stamp grammar of RFC 5321 section 4.4. The address is the first IPv4 address in the from clause and its TCP-info comment, else an IPv6 address literal there ([IPv6:...], RFC 5321 section 4.1.3), else any IPv4 address anywhere in the header. That last fallback can pick up the receiving server’s own address. An address outside public ranges is labelled non-public.

The timestamp is read with the browser’s date parser after a trailing comment is removed. A hop’s delay is its timestamp minus the previous hop’s: how long the earlier server held the message. The end-to-end time runs from the oldest stamp to the newest.

Route rules

Rule	Severity	Title	Source
The longest delay exceeds 30 seconds	CHECK	N s at server (the server that held the message)	none (Tamperbox threshold)
A hop is stamped more than 2 seconds before the hop before it	INFO	Clock skew at hop N	RFC 5321 §4.4
A hop has a from clause, no TLS marker, and a public address	CHECK	No TLS into server	RFC 3848 §1

Clock skew relies on header order over timestamps: the order is a MUST, while dates only carry “SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names” (RFC 5321 section 4.4).

A hop counts as encrypted when its header mentions ESMTPS, ESMTPSA, TLS or version=TLS anywhere. RFC 3848 section 1 defines ESMTPS as “the use of ESMTP when STARTTLS [1] is also successfully negotiated”. The other registered encrypted types, LMTPS, LMTPSA and the UTF8SMTPS family from RFC 6531 section 4.3, are not recognised unless the header also mentions TLS.

Authentication results: which header

The topmost Authentication-Results header is read, or the topmost ARC-Authentication-Results when there is none. Topmost is the newest, because the field “MUST be treated as though it were a trace header field” and “MUST be prepended to the message” (RFC 8601 section 4.1). Lower Authentication-Results headers are ignored, including a second one from the same receiver.

The value is split on semicolons, following resinfo in RFC 8601 section 2.2. The first part is shown as the reporting server, the authserv-id of RFC 8601 section 2.5. Every later part that starts with method=result becomes an entry, with its ptype.property values (smtp.mailfrom, header.i, header.d, header.s, header.from). When a method appears more than once, a passing entry is preferred.

The authserv-id is shown, never checked against a list of servers you trust. Section 2.5 says consumers “SHOULD use this identifier to determine whether or not the data contained in an Authentication-Results header field ought to be used or ignored”. The tool leaves that decision to you and says so in the INFO finding.

Authentication rules

Rule	Severity	Title	Source
Always	INFO	Reported results, not independent verification	RFC 8601 §7.1
No entries read from the header	INFO	No Authentication-Results header	RFC 8601 §2.2
DMARC pass	PASS	DMARC passed	RFC 9989 §5.3.5
DMARC fail or permerror	FAIL	DMARC result	RFC 9989 §5.3.5
SPF pass for a Return-Path domain that is not the From domain	INFO	SPF passed but is not aligned	RFC 9989 §4.4.2
SPF fail or permerror	FAIL	SPF result	RFC 7208 §2.6
DKIM none	INFO	DKIM none	RFC 8601 §2.7.1
DKIM fail or permerror	FAIL	DKIM result	RFC 8601 §2.7.1

Authentication rules: the sentences behind them

DMARC decides the verdict. RFC 9989 section 5.3.5: “If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.” The tool takes the receiver’s word for which side of that line the message fell. It treats none as informational, consistent with RFC 9989 section 9.2 registers as “No DMARC Policy Record exists for the Author Domain”.

SPF results follow RFC 7208 section 2.6. The tool treats neutral and none as informational, following RFC 7208 section 8.2, which says: “A “neutral” result MUST be treated exactly like the “none” result”. softfail is a CHECK here; section 8.5 says receivers “SHOULD NOT reject the message based solely on this result”.

DKIM results follow RFC 8601 section 2.7.1: none means “The message was not signed”, so it is INFO; fail and permerror are FAIL, temperror is CHECK, and neutral and other results are INFO.

Alignment

Alignment is an exact domain match, compared in lower case. RFC 9989 section 3.2.10.2 calls this strict alignment: “When the Author Domain (Section 3.2.2) is identical to an Authenticated Identifier (Section 3.2.1), the two are said to be in strict alignment.” Relaxed alignment (section 3.2.10.1) needs the Organizational Domain, which RFC 9989 finds with a DNS tree walk (section 4.10). The tool makes no DNS queries for authentication, so relaxed alignment is not evaluated.

The Return-Path domain is compared with the From domain, and every d= of a DKIM-Signature header (RFC 6376 section 3.5) is compared with From. A DMARC pass is attributed to DKIM or SPF only when one of them matches exactly; a DKIM domain that is a parent or subdomain of From is labelled as a domain relationship.

The From domain is extracted from a single mailbox after excluding display names and nested comments. The value "ceo@bank.example" <x@evil.example> yields evil.example. Ambiguous lists, multiple From fields and unsupported syntax yield an unknown domain; encoded display words are not decoded. See RFC 5322 section 3.4.

Reply identity

A Reply-To domain that is neither the From domain nor one of its subdomains is CHECK, “Replies go to X”. Source: none; this is a Tamperbox phishing heuristic. RFC 5322 section 3.6.2 only says Reply-To “indicates the address(es) to which the author of the message suggests that replies be sent”. With a DMARC pass, the verdict keeps the pass and is raised to a CHECK.

Hop address lookup

Nothing leaves the browser until you choose Look up hop addresses. Then up to 50 unique public addresses are sent to the server, three at a time, which returns the autonomous system, organisation and registry country from the network registry and the reverse name from public DNS. Documentation ranges are answered on the page without a request. Partial answers are counted and can be retried. Source: none; this is a Tamperbox convenience, not part of any mail standard.

Standards and conformance

The analyzer is a reader of trace and authentication headers. Everything in this section runs in your browser on the text you pasted. The only network request the code can make is the optional hop address lookup, which sends public IP addresses and nothing from the authentication section. The tool does not re-verify DKIM signatures, re-evaluate SPF, look up DMARC records or validate ARC seals. It reports what the receiver recorded, and where it parses more loosely than a specification allows, the tables below say so.

RFC 5322 Internet Message Format

RFC 5322, Draft Standard, updated by RFC 6854.

Section	Requirement	What the tool does
2.1	An empty line separates the header section from the body	Cuts at the first empty line; a line of only white space also ends the header
2.2	Field name of printable US-ASCII except colon	Same character range; lines that do not match are skipped silently
2.2.3	Unfold by removing CRLF before WSP	Unfolds, but trims and joins with one space
3.3	date-time syntax	Read by the browser’s date parser, which also accepts obsolete forms
3.4	name-addr = [display-name] angle-addr	Single mailbox parsed with display names and comments excluded; ambiguous input stays unknown
3.6.2	From is a mailbox list; Reply-To an address list	Only the first address of each is used
3.6.7	Return-Path and Received are trace fields	Read as trace; only the first Return-Path is used

The display-name gap matters for phishing. A From of "ceo@bank.example" <x@evil.example> is reported as from bank.example. Read the From row in Message and every header before you trust the domain.

RFC 5321 SMTP trace information

RFC 5321, Draft Standard, updated by RFC 7504.

Section	Requirement	What the tool does
4.4	Received lines are prepended and never reordered	Reverses them to get the route oldest first
4.4	Stamp: FROM, BY, optional WITH, then ; and date-time	Takes the first from, by and with words and the text after the last ;
4.4	The FROM clause SHOULD carry the address from the TCP connection	Takes the first address in the clause, with fallbacks described under Method
4.4	obs- date forms MUST NOT be used in SMTP	Accepts them; a stamp in EST is read without a warning
4.4	Return-Path preserves the MAIL FROM reverse-path	Uses the Return-Path domain as the SPF identity for alignment
4.1.3	IPv6 address literal [IPv6:...]	Recognised in the from clause

Received headers below your own receiver were written by servers you do not control. Section 4.4 says a mail program “MUST NOT change or delete a Received: line”, but nothing stops a sender from adding false ones before the first real hop. The tool draws them like any other hop.

RFC 3848 and RFC 6531 transmission types

RFC 3848, Draft Standard, registers ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS and LMTPSA for the with clause (section 1). RFC 6531, Proposed Standard, adds the UTF8SMTP family, including UTF8SMTPS “ESMTP with SMTPUTF8 and STARTTLS” (section 4.3).

Type	Means encrypted	Tool counts it as TLS
ESMTPS, ESMTPSA	Yes	Yes
LMTPS, LMTPSA	Yes	Only if TLS appears elsewhere in the header
UTF8SMTPS, UTF8SMTPSA	Yes	Only if TLS appears elsewhere in the header
Any type, with TLS in a comment	Not defined by these RFCs	Yes

The No TLS finding only applies to hops with a public address, so the usual LMTP hop to a mailbox store on an internal address is not flagged. RFC 3848 section 3 warns that these keywords “should not be used for mail filtering or relaying decisions except in very controlled environments”; the tool uses them only for a CHECK.

RFC 8601 Authentication-Results: parsing

RFC 8601, Proposed Standard.

Section	Requirement	What the tool does
2.2	authserv-id [version] (no-result / 1*resinfo)	Splits on every ; and shows the first part, version included, as the server
2.2	no-result is the literal none	Not recognised: the header is reported as missing
2.2	Comments (CFWS) may appear between tokens	A ; inside a comment or quoted reason cuts the entry short and its properties are lost
2.3	ptype.property=pvalue	Read for every dotted property; reason is not read
2.6	A method may carry a version, dkim/1	Not recognised: the entry is dropped
2.7.1, 2.7.2	DKIM and SPF result sets	Pass, none and failure, as listed under Method
4.1	Ignore unregistered results and unsupported methods	Shows only spf, dkim and dmarc; other methods are read but not displayed

The ; problem is not theoretical: the expanded example in RFC 7208 section 9.2 has reason="client-ip=192.0.2.1; smtp.helo=foo.example.com", which the tool splits in two.

RFC 8601 Authentication-Results: trust

Section	Requirement	What the tool does
2.5	Consumers SHOULD use the authserv-id to decide whether to use the header	Shows it; you decide
4.1	MUAs and filters “SHOULD NOT interpret this header field unless specifically configured to do so”	You start the reading by pasting; there is no trusted-server list
5	The receiving MTA MUST delete forged copies claiming its own authserv-id	Out of scope: the tool is not an MTA and assumes your receiver did this
7.1	Forged header fields: a trusted list “should initially be empty”	Always adds the INFO finding that results are reported, not verified

RFC 8601 says processing should not be on by default; the tool reads the header because that is its whole job, and every result is labelled as the receiver’s claim. If the topmost header was added by a server outside your own mail system, or by the sender, treat every result on the page as unverified.

RFC 7208 SPF

RFC 7208, Proposed Standard, updated by RFC 7372, RFC 8553 and RFC 8616.

Section	Requirement	What the tool does
2.4	With a null reverse-path, MAIL FROM is postmaster@ the HELO identity	Not applied: a Return-Path of <> has no domain, so the Return-Path row shows none
2.6	Seven results: none, neutral, pass, fail, softfail, temperror, permerror	Displays the recorded result as written
4	check_host() evaluation	Not performed; no DNS query is made
8.2	Neutral MUST be treated exactly like none	Both are informational
8.5	Softfail is between fail and none	Reported as CHECK
9.2	SPF results in Authentication-Results with smtp.mailfrom	Shows smtp.mailfrom as the checked identity; alignment uses Return-Path instead

The smtp.mailfrom the receiver recorded and the Return-Path domain usually agree. When they do not, the SPF tile and the alignment table show different domains.

RFC 6376 DKIM

RFC 6376, Internet Standard, updated by RFC 8301, RFC 8463, RFC 8553 and RFC 8616.

Section	Requirement	What the tool does
3.2	DKIM-Signature is a tag=value list	Parsed for d=, s= and a=
3.5	d= is the signing domain (SDID)	Compared with the From domain for alignment
6	“Verifiers MUST produce a result that is semantically equivalent to applying the steps listed in Sections 6.1, 6.1.1, and 6.1.2”	Not a verifier: no key lookup, no body hash, no signature check

Because it does not verify, the tool compares every d= it finds, including signatures the receiver marked as failed. With one aligned signature that failed and an unaligned one that passed, it still says DMARC passed through DKIM. RFC 9989 counts only a validated d= (section 3.2.3). The receiver’s own DMARC result is still the one shown.

RFC 9989 DMARC

RFC 9989, Proposed Standard, May 2026. It obsoletes RFC 7489 together with RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting); the tool uses neither report format.

Section	Requirement	What the tool does
3.2.4	The SPF Domain is the SPF-validated MAIL FROM	Uses the Return-Path domain
3.2.10.1	Relaxed alignment: same Organizational Domain	Not evaluated
3.2.10.2	Strict alignment: identical domains	Evaluated, without checking that SPF or DKIM passed
4.4	Domain comparisons are case-insensitive	Lower-cases before comparing
4.10	DNS tree walk for policy and Organizational Domain	Not performed
5.3.1	Zero or several From domains: validation is not possible	Uses the first domain and carries on
5.3.5	Pass when an Authenticated Identifier aligns	Takes the receiver’s recorded result
9.2	Result names pass, fail, none, temperror, permerror	Pass is PASS; none is INFO; temperror is CHECK; fail and permerror are FAIL

The dmarc=none result is informational: it indicates no applicable policy, rather than a failed authentication check.

RFC 8617 ARC

RFC 8617, Experimental. Not on the standards track.

Section	Requirement	What the tool does
4.1.1	AAR is instance ";" authres-payload	Read only when no Authentication-Results header exists; the instance tag i=1 is shown as the server name and the real authserv-id is skipped
4.2.1	Instance tags order ARC sets	Not used; the topmost AAR is taken
5.2	Validator actions on ARC-Seal and ARC-Message-Signature	Not performed

An ARC-Authentication-Results header records what an intermediary saw, and without seal validation anyone could have written it.

RFC 2047 encoded words

RFC 2047, Draft Standard. Encoded words (section 2) are not decoded; From, Subject and other values are shown as written. The From domain is unaffected, because encoded words may not appear in an addr-spec (section 5).

Finding reference

The RFC section column links the rule each finding comes from. “none” marks a Tamperbox recommendation that no specification requires.

Authentication findings

Finding	Severity	What it means	What to do	RFC section
Reported results, not independent verification	INFO	The receiver’s word, not a re-check	Confirm the reporting server is yours	RFC 8601 §7.1
No Authentication-Results header	INFO	Nothing was recorded, the header says none, or the headers came from the sender’s side	Copy from the received message	RFC 8601 §2.2
DMARC passed	PASS	The receiver found an aligned SPF or DKIM pass		RFC 9989 §5.3.5
DMARC fail (or other)	FAIL	The From domain was not proven; none means it has no DMARC policy	Treat as unverified; if yours, fix SPF or DKIM alignment	RFC 9989 §9.2
SPF passed but is not aligned	INFO	Normal for a mail service; DMARC relies on DKIM	Nothing	RFC 9989 §4.4.2
SPF fail, permerror	FAIL	The receiver reports failure or a permanent evaluation error	Add the server to the record, if the message is yours	RFC 7208 §2.6
DKIM none	INFO	The message was not signed	Sign outgoing mail	RFC 8601 §2.7.1
DKIM fail (or other)	FAIL	The signature did not verify or could not be checked	Check the key; look for a forwarder that altered the message	RFC 8601 §2.7.1

Identity and route findings

Finding	Severity	What it means	What to do	RFC section
Replies go to X	CHECK	Answers leave the From domain	Verify the sender before replying	none (Tamperbox heuristic)
N s at server	CHECK	The longest wait on the route	Nothing, unless it repeats	none (Tamperbox threshold)
Clock skew at hop N	INFO	Server clocks disagree; header order still holds	Fix the clock if the server is yours	RFC 5321 §4.4
No TLS into server	CHECK	The hop was not recorded as encrypted	Enable STARTTLS; publish MTA-STS	RFC 3848 §1

Guide

Is this message genuine?

1. Confirm that the server named in Authentication-Results is your own receiving server; everything below it was written by the sender.
2. Read the DMARC result. A pass means the From domain was proven; a fail means it was not.
3. Check Reply-To and Return-Path. A reply address on another domain is the common shape of phishing that asks you to answer.
4. Read the From header itself in Message and every header. The display name may claim a different address than the actual mailbox; compare them.
5. If in doubt, contact the supposed sender through a channel you already have.

My own mail fails DMARC

1. Open the DKIM key that signed it (Take it further) and confirm it is published and strong enough.
2. Open SPF for the bounce domain and confirm the sending service is listed.
3. Make the service sign with your domain, not its own, so DKIM aligns even when the bounce domain does not.

A long delay

A wait over 30 seconds at one server is usually a queue, a content filter or a greylisting retry. If it repeats, ask the operator of that server. The route names the server that held the message.

Clock skew

A hop stamped before the one under it means a server’s clock is wrong. The order of the headers is what counts. Fix the clock with NTP if the server is yours.

Break it cases

Each case is built from the headers you pasted, keeping every other line.

Case	What it does to the headers
Reply-To elsewhere	Sets Reply-To to a look-alike domain
All checks fail	Replaces Authentication-Results with spf=fail, dkim=none, dmarc=fail and a look-alike Return-Path
Clock skew	Restamps the newest Received header 70 seconds before the one under it
Not headers	Loads a sentence that is not a header block

Worked example

The page opens on an order confirmation sent through a mail service, built from documentation addresses and the reserved .example zone. Four hops: the sender’s laptop to out.harbor-supply.example, to the mail service mail-sor-f17.inboxcloud.example, to mx.receiver.example, to the mailbox store, 41 seconds end to end, 38 of them at the mail service.

Receiver reports: DMARC passed through DKIM. SPF passed for send.bulkpost.example, the mail service’s bounce domain, so the only aligned identity is the DKIM signature d=harbor-supply.example; s=google. The findings are the 38-second wait (CHECK), two INFO notes, and the DMARC pass. Look up hop addresses answers from local sample data, so nothing is sent. Replace the sample with your own headers and every section, card and link is rewritten for them.

For agents

The Tamperbox MCP server runs the same analysis. Search its catalog for the header operation, inspect the input schema, and call it with the header block. Keep the warning block with any conclusion:

• Results are what the receiving server recorded; nothing is re-verified.
• Headers below the trusted receiver can be forged.
• Alignment is an exact domain match; delays depend on each server’s clock.

See Connect an MCP client and Code mode for the calling pattern, and Security and privacy for what travels when addresses are looked up.

Limits

• No signature or ARC verification; no DNS lookup for the authentication section.
• Exact alignment only.
• The topmost Authentication-Results header only.
• From supports a single mailbox with display names and comments; ambiguous lists remain unknown and encoded words are not decoded.
• Hop lookups: up to 50 public addresses, only on request; country is registry data, not location.
• Nothing is stored.

References

Specification	Status	Sections used
RFC 5322, Internet Message Format	Draft Standard, updated by RFC 6854	2.1, 2.2, 2.2.3, 3.3, 3.4, 3.6.2, 3.6.7
RFC 5321, Simple Mail Transfer Protocol	Draft Standard, updated by RFC 7504	4.1.3, 4.4
RFC 3848, ESMTP and LMTP Transmission Types Registration	Draft Standard	1, 3
RFC 6531, SMTP Extension for Internationalized Email	Proposed Standard	4.3
RFC 8601, Message Header Field for Indicating Message Authentication Status	Proposed Standard	2.2, 2.3, 2.5, 2.6, 2.7.1, 2.7.2, 4.1, 5, 7.1
RFC 7208, Sender Policy Framework	Proposed Standard, updated by RFC 7372, 8553, 8616	2.4, 2.6, 4, 8.2, 8.5, 9.2
RFC 6376, DomainKeys Identified Mail Signatures	Internet Standard, updated by RFC 8301, 8463, 8553, 8616	3.2, 3.5, 6
RFC 9989, DMARC	Proposed Standard; obsoletes RFC 7489 with RFC 9990 and 9991	3.2.3, 3.2.4, 3.2.10.1, 3.2.10.2, 4.4, 4.4.2, 4.10, 5.3.1, 5.3.5, 9.2
RFC 9990, DMARC Aggregate Reporting	Proposed Standard	none; cited as a successor of RFC 7489
RFC 9991, DMARC Failure Reporting	Proposed Standard	none; cited as a successor of RFC 7489
RFC 8617, Authenticated Received Chain	Experimental	4.1.1, 4.2.1, 5.2
RFC 2047, MIME Part Three: Message Header Extensions	Draft Standard, updated by RFC 2184, 2231	2, 5

RFC 9990 and RFC 9991 are cited only as the documents that, with RFC 9989, replace RFC 7489; the tool reads no DMARC reports. For the key behind a message’s signature, see the DKIM Record Checker.