What is header.i in email headers, how does it relate to DKIM, and does it affect sender reputation?
Updated on 19 Jul 2026: We updated this guide for RFC 9989 and clarified what header.i can and cannot prove.
The direct answer is simple: header.i is not a standalone email header. It is a property that an authentication service can report inside Authentication-Results after evaluating a DKIM signature. Its value corresponds to the i= identity in the message's DKIM-Signature header, such as @email.example.com or karen@info.example.com.
It relates to DKIM because the signer asserts that identity. The signing domain is shown as header.d, the selector is shown as header.s, and the optional DKIM identity can be shown as header.i. DMARC checks whether the DKIM signing domain, not the i= local part, has Identifier Alignment with the visible From domain.
Does it affect sender reputation? A receiver can use it under local policy, but a changing header.i prefix is not an automatic penalty. Prioritize failed DKIM, poor DMARC domain matching, spam complaints, sudden volume changes, and weak recipient response over normal values such as karen@info.example.com and john@info.example.com under the same stable domain.
What header.i means
An authentication service can write header.i into Authentication-Results when it reports a DKIM evaluation, including a pass or fail. The value corresponds to the DKIM i= tag, called the Agent or User Identifier (AUID). If the signer omits i=, DKIM defines the default AUID as the empty local part at the d= domain, such as @example.com. A receiver is not required to display header.i in its result.
The domain part of i= must be the same as, or a subdomain of, the d= signing domain. That is why i=karen@info.example.com is valid when d=info.example.com. It cannot claim i=@otherdomain.test in that signature. If the DKIM public key has t=s, the AUID domain must exactly match the d= domain.
Quick read
- header.i reports the DKIM AUID associated with an evaluated signature.
- The signer sets i=, or DKIM defaults it to an empty local part at the d= domain.
- The AUID domain stays within the DKIM signing domain unless t=s requires an exact match.
- A normal local-part change is not a standalone deliverability problem.
DKIM calls i= the AUID and d= the Signing Domain Identifier (SDID). The SDID is DKIM's mandatory responsible domain. The AUID is optional, finer-grained information chosen by the signer.
What header.i does not prove
An AUID looks like an email address, but DKIM does not require it to identify a real mailbox or match the visible From address. Its domain does not have to resolve in DNS, and its local part can come from a private namespace defined by the signer. A value such as i=karen@info.example.com therefore does not prove that Karen owns a mailbox or authored the message.
Authentication-Results also has no integrity protection on its own. Trust the field added by the receiving system inside its trust boundary, identified by the authserv-id at the start of the field. An attacker can insert a lookalike result before delivery, so receivers normally remove or ignore untrusted copies.
Limits to remember
- header.i does not prove that the local part belongs to a person or mailbox.
- A matching AUID does not make DMARC pass; DMARC evaluates the passing d= domain.
- A missing header.i property does not mean DKIM lacked a signing domain or failed.
- In ARC headers, a standalone i=1 is the ARC chain instance, not the DKIM AUID.
How it maps to DKIM fields
Authentication-Results uses property names such as header.i, while DKIM-Signature uses shorter tags such as i=. They describe the signature from the receiver's result and the sender's original signature.
|
|
|
|---|---|---|
header.i | i= tag | Optional AUID asserted by the signer. |
header.d | d= tag | Signing Domain Identifier (SDID). |
header.s | s= tag | DNS selector used to locate the public key. |
header.a | a= tag | DKIM signing algorithm. |
header.from | Visible From domain | Author Domain evaluated by DMARC. |
Registered DKIM properties and related DMARC data in Authentication-Results.
DKIM signature and Authentication-Results exampletext
DKIM-Signature: v=1; a=rsa-sha256; d=info.example.com; s=spop2026; i=karen@info.example.com; h=from:to:subject:date; bh=...; b=... Authentication-Results: mx.receiver.example; dkim=pass header.i=karen@info.example.com header.d=info.example.com header.s=spop2026; dmarc=pass header.from=example.com;
In that example, DKIM passes for info.example.com. Under relaxed alignment, RFC 9989 uses a DNS tree walk to determine the Organizational Domain. If that process finds example.com for both info.example.com and the Author Domain, the DKIM identifier has relaxed alignment. Strict alignment requires the DKIM d= domain and the From domain to be identical.
Flowchart showing how DKIM validation leads to a header.i result.
Why header.i and header.from can differ
The header.from value is not the DKIM identity. It is the domain in the message's visible From header, or the domain the receiver extracted from that header for DMARC. That value can be the brand's root domain, while DKIM signs with a subdomain used by a sending platform or business unit.
For example, a message can have a visible From address at example.com, a DKIM signing domain at info.example.com, and a bounce domain at bounce.example.net. Those are different identities. DMARC passes when at least one authenticated DKIM or SPF identifier has Identifier Alignment with the visible From domain.
DKIM identity
- Authentication-Results can report header.i, header.d, and header.s for a DKIM evaluation.
- The sending server creates the identity and signature.
- DKIM proves that the signed header fields and signed body portion survived verification.
DMARC identity
- Authentication-Results commonly reports the Author Domain as header.from.
- The Author Domain comes from the address shown to the recipient.
- DMARC compares it with an authenticated DKIM d= domain or SPF MAIL FROM domain.
Important DMARC point
DMARC does not pass because header.i looks similar to the From domain. DKIM-based DMARC alignment uses the passing d= domain. If a message has multiple DKIM signatures, DMARC only needs one passing signature with an aligned signing domain.
This matters when you see dmarc=fail or no DMARC result. A passing DKIM result alone is not enough. The passing d= domain must have Identifier Alignment with the visible From domain, or SPF must pass with an aligned MAIL FROM domain. DMARC monitoring in Suped's product separates authentication failures from domain alignment failures so teams can identify the sender that needs a DNS or platform change.
Does header.i affect sender reputation?
Mailbox providers do not publish a universal rule that penalizes a changing header.i local part. A receiver can use the AUID under local policy, and RFC 6376 allows a stable AUID to identify a finer-grained sphere of responsibility. The standard leaves any extra interpretation to the receiver.
A value like i=karen@info.example.com does not create a syntax penalty for using Karen as the local part. It gives the receiver a more specific identity under the same DKIM signing domain. If a receiver observes different outcomes for different AUIDs, it can apply its own assessment. That is receiver policy, not a DKIM rule.
Reputation concern level
Practical priority for common header.i situations during a deliverability review.
Normal
Low
Stable local parts under one matching DKIM domain.
Needs review
Medium
Many identities with unclear sender ownership or weak reporting.
Fix first
High
DKIM passes but does not match the From domain.
Do not rewrite a working DKIM setup just because header.i changes with the friendly From prefix. Change it when the identity leaks personal data, breaks DKIM validation, or makes sender ownership hard to audit.
- Keep a stable DKIM signing domain for each accountable mailstream.
- Set i= to a value that supports internal auditing instead of exposing personal data.
- Verify that the passing DKIM d= domain has Identifier Alignment with the visible From domain.
- Treat changing AUID local parts as an audit clue, not an automatic reputation fault.
How to inspect it in practice
Start with the raw message headers and read the DKIM-Signature before the Authentication-Results line. The sending server writes DKIM-Signature. The receiving authentication service writes Authentication-Results after evaluating that signature. Mixing those viewpoints is the usual source of confusion.
For a focused DNS check, use the DKIM checker to confirm the selector and public key record are valid. For a wider view across DMARC and its DKIM/SPF inputs, run a domain health checker scan and compare the DNS setup with the actual headers from a delivered test message.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
The DNS check confirms that the key exists and has valid DKIM syntax. The header check confirms that the signature passed after the message moved through the mail path. Both matter because a valid public key does not prove that every sender is signing correctly.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
Suped's records view filters messages by source, DKIM result, SPF result, and domain alignment outcome. This separates a harmless header.i difference from a sender that passes DKIM with the wrong domain.
Recommended setup
For most senders, the practical setup uses a stable DKIM signing domain, a predictable selector naming scheme, matched DMARC domains, and enough reporting to catch changes before delivery suffers. You do not need to force every message to have the same header.i local part.
Good pattern
- Use a signing subdomain controlled by the visible brand domain.
- Rotate selectors deliberately and document the owner.
- Choose simple AUID values that help routing and audits.
Risky pattern
- Use an unrelated platform domain that cannot match the From domain.
- Reuse old selectors without knowing which system owns them.
- Generate random identities that make incidents hard to trace.
Suped's product connects DMARC reporting with SPF, DKIM, blocklist monitoring (blacklist monitoring), hosted policy controls, and MTA-STS. For this issue, the practical workflow groups records by sending source, compares DKIM d= with header.from, and alerts on new domain mismatches. That keeps header.i in context instead of treating it as a standalone score.
Practical rule
If header.i changes but DKIM passes, DMARC domains match, complaints stay low, and recipient response is healthy, leave it alone. If header.i changes alongside DMARC failures or source confusion, fix the sender setup.
Views from the trenches
Best practices
Compare DKIM d= with header.from before treating header.i as the delivery cause.
Keep DKIM identity domains stable, documented, and owned by the sending brand team.
Use reporting to group failures by sender source, not by isolated header values.
Common pitfalls
Assuming a different header.i value means DMARC domain matching has already failed.
Treating display name changes as the same issue as DKIM identity changes in headers.
Ignoring selector and signing domain details while focusing only on the local part value.
Expert tips
Check raw DKIM-Signature first, then compare receiver Authentication-Results fields.
Use strict domain matching only when every sender signs with the exact From domain.
Treat header.i as an audit clue, then verify reputation with real sender outcomes.
Marketer from Email Geeks says header.i maps to the DKIM i= tag, while header.d maps to d=.
2019-08-13 - Email Geeks
Marketer from Email Geeks says the i= value can identify a more specific sender under d=.
2019-08-13 - Email Geeks
When to change your DKIM setup
Treat header.i as a DKIM identity clue, not the main DMARC decision point. It tells you which optional AUID the signer asserted under the DKIM signing domain. It does not replace header.d for DMARC domain alignment, and it does not override the visible From domain.
If DKIM passes, the signing domain has Identifier Alignment, and the mailstream behaves well, a changing local part in header.i is usually normal. If DKIM passes but DMARC fails, inspect the d= domain and the visible From domain before changing i=.
