The direct answer is simple: header.i is the DKIM identity reported by the receiving mail server after it checks a message. It comes from the i= tag inside the message's DKIM-Signature header. It is usually an address-like identity such as @email.example.com or karen@info.example.com.
It relates to DKIM because DKIM is the mechanism that created that signed identity. The signing domain is shown as header.d, the selector is shown as header.s, and the DKIM identity is shown as header.i. DMARC then checks whether the DKIM signing domain, not the i= local part, matches the visible From domain closely enough.
Does it affect sender reputation? Receivers can observe it and can use it as one signal, but a changing header.i prefix is not automatically a penalty. I would worry more about failed DKIM, poor DMARC domain matching, spam complaints, sudden volume changes, and bad user interaction than about normal values such as karen@info.example.com and john@info.example.com under the same stable domain.
What header.i means
A receiving mail server writes header.i into Authentication-Results after it validates a DKIM signature. The value is copied from the DKIM i= tag, also called the agent or user identifier. If the signer does not include i=, the default identity is the empty local part at the signing domain, such as @example.com.
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 makes sense when d=info.example.com. It would not make sense for that same signature to claim i=@otherdomain.test.
Quick read
- Meaning: header.i is the DKIM identity from the i= tag.
- Source: the sending server sets it when creating the DKIM signature.
- Scope: the domain part must sit inside the DKIM signing domain.
- Risk: a normal local-part change is not a standalone deliverability problem.
If you want the narrower tag-level explanation, the related DKIM i tag page covers the i= value itself. The rest of this page focuses on how that value appears in real headers and what to do with it.
How it maps to DKIM fields
The confusing part is that Authentication-Results uses labels such as header.i, while the DKIM-Signature header uses shorter tags such as i=. They are describing the same checked signature, just from two different places in the message.
|
|
|
|---|---|---|
header.i | i tag | Signed identity or AUID. |
header.d | d tag | Signing domain. |
header.s | s tag | DNS selector. |
header.h | h tag | Signed header fields. |
header.from | From header | Visible author domain. |
Common Authentication-Results labels and their DKIM source fields.
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. DMARC can still pass with header.from=example.com when relaxed domain matching is in use because info.example.com is under example.com. With strict DKIM domain matching, the DKIM signing domain has to match the From domain exactly.
Flowchart showing how DKIM validation leads to a header.i result.
Why header.from can be different
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 often matches the brand's organizational domain, while DKIM signs with a subdomain used by a sending platform, a business unit, or a mailstream.
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 decides whether at least one authenticated identity lines up with the visible From domain.
DKIM identity
- Reported as: header.i, header.d, and header.s in Authentication-Results.
- Created by: the sending server when it signs the message.
- Used for: cryptographic proof that selected headers and body content were not changed.
DMARC identity
- Reported as: header.from in the DMARC result.
- Created by: the author address shown to the recipient.
- Used for: domain checks against DKIM d= and SPF Mail From.
Important DMARC point
DMARC does not pass because header.i looks similar to the From domain. DKIM-based DMARC domain matching uses the DKIM d= domain. If a message has multiple DKIM signatures, DMARC only needs one passing signature with a matching signing domain.
This matters when you see dmarc=NULL or dmarc=fail. A passing DKIM result alone is not enough. The passing DKIM signature must line up with the visible From domain, or SPF must pass and match the From domain. For ongoing visibility, DMARC monitoring in Suped's product helps separate authentication failures from domain match failures so you know which sender needs a DNS or platform change.
Does header.i affect reputation
The practical answer is that header.i can be measured, but it is rarely the thing that causes a reputation problem by itself. Mailbox providers score many stable signals: IP, domain, DKIM signing domain, visible From domain, envelope sender, content, user interaction, complaint rate, bounce rate, and authentication quality.
A value like i=karen@info.example.com does not mean the sender is being punished for using Karen as the local part. It gives the receiver a more specific identity under the same DKIM signing domain. If messages tied to one identity get worse user interaction than messages tied to another identity, the receiver has enough data to treat them differently. That is a data outcome, not a syntax penalty.
Reputation concern level
How I would rank 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.
So I would not rewrite a working DKIM setup just because header.i changes with the friendly From prefix. I would rewrite it if the identity is random, if it leaks personal data into headers, if it breaks DKIM validation, or if it makes sender ownership impossible to audit.
- Stable domain: use one DKIM signing domain per brand, platform, or mailstream when possible.
- Useful local part: set i= to a value that helps internal auditing, not a random token.
- DMARC focus: verify the DKIM d= domain matches the visible From domain.
- Privacy check: avoid putting sensitive user identifiers into DKIM identity values.
How to inspect it in practice
When I inspect this, I start with the raw message headers and read the DKIM-Signature before the Authentication-Results line. The sending server writes the DKIM-Signature. The receiving server writes Authentication-Results after checking that signature. Mixing those two viewpoints is the usual reason this gets confusing.
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, SPF, and DKIM, 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 the key exists and has valid DKIM syntax. The header check confirms the signature actually passed after the message moved through the mail path. You need both because a valid public key does not prove every sender is signing correctly.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
In Suped's product, I use the records view to filter messages by source, DKIM result, SPF result, and domain match outcome. That makes it easier to separate a harmless header.i difference from a sender that is passing DKIM with the wrong domain.
Recommended setup
For most senders, the best setup is boring: a stable DKIM signing domain, a predictable selector naming scheme, matched DMARC domains, and enough reporting to catch changes before mailbox providers start treating mail differently. You do not need to force every message to have the exact same header.i local part.
Good pattern
- Signing domain: use a subdomain that belongs to the visible brand domain.
- Selector plan: rotate selectors deliberately and document the owner.
- Identity value: use simple values that help routing and audits.
Risky pattern
- Signing domain: use an unrelated platform domain that cannot match the From domain.
- Selector plan: reuse old selectors without knowing which system owns them.
- Identity value: generate random identities that make incidents hard to trace.
Suped is the best overall DMARC platform for most teams that need ongoing control because the product brings DMARC, SPF, DKIM, blocklist monitoring (blacklist monitoring), hosted SPF, hosted DMARC, and hosted MTA-STS into one workflow. The useful part here is not another raw header field. It is automated issue detection, clear steps to fix, real-time alerts, and reporting that shows which sender is causing the problem.
Practical rule
If header.i changes but DKIM passes, DMARC domains match, complaints stay low, and engagement 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
The decision to make
Treat header.i as a DKIM identity clue, not the main DMARC decision point. It tells you which identity the signer claimed under the DKIM signing domain. It does not replace header.d for DMARC domain matching, and it does not override the visible From domain.
If DKIM passes, the signing domain matches, and the mailstream behaves well, a changing local part in header.i is usually normal. If DKIM passes but DMARC fails, look at the signing domain and the visible From domain before changing the i= value. That is the fastest path to the real fix.
