Summary
In email headers, header.i refers to the 'i=' tag within the DKIM-Signature, serving as the 'Agent or User Identifier' (AUID). It specifies the specific identity, often an email address or subdomain, responsible for signing the email. While header.i itself identifies the signer, its critical relationship to sender reputation primarily hinges on DMARC alignment. For a message to pass DMARC with DKIM, the domain in the header.i tag must align with the RFC5322.From header. If these domains do not align, it leads to a DMARC failure for DKIM, signaling potential spoofing to receiving mail servers. Such a misalignment can significantly harm sender reputation, leading to emails being marked as spam or rejected, even if the DKIM signature itself is technically valid. Although header.i is largely an internal configuration detail set by the sending server, its correct setup and alignment are paramount for successful email authentication and maintaining good deliverability.
Key findings
- Identifier for Signature: Header.i, also known as the 'i=' tag in a DKIM signature, stands for 'Agent or User Identifier' (AUID). It specifies the identity of the user or agent responsible for signing the email, indicating who or what entity takes responsibility for the signature.
- Relation to D= Tag: The domain specified in the i= tag must be a subdomain of the d= (signing domain) tag for the DKIM signature to be considered valid.
- Optional Component: The i= tag is optional in a DKIM signature. When present, it can specify a more granular identity, such as a specific email address or a subdomain, distinct from the broader d= domain.
- Server-Side Setting: The i= tag is set by the sending server when the DKIM signature is created, defining the specific signing identity for that email.
Key considerations
- DMARC Alignment Critical: For successful DMARC authentication, the domain specified by header.i must align with the RFC5322.From header domain. This means it needs to be the same organizational domain or a subdomain of it. Failure to align will cause DKIM to not pass DMARC, even if the DKIM signature itself is technically valid.
- Impact on Reputation: Misalignment of header.i with the 'From:' domain, leading to DMARC failure, severely negatively impacts sender reputation. Receiving servers may interpret such emails as spoofing attempts, resulting in higher spam scores, rejection, or delivery to the junk folder.
- ESPs and Signing: Email service providers (ESPs) frequently use header.i to sign emails on behalf of their clients, designating the specific identity responsible for the signature.
- Not a Direct Concern for Most: While essential for authentication, header.i is largely an internal configuration detail. Outside parties generally don't need to delve into its intricacies, as long as DMARC alignment is correctly maintained.
What email marketers say
10 marketer opinions
The header.i component of a DKIM signature indicates the specific identity or subdomain responsible for signing an email, often an Authorizing User Identifier (AUID). While it designates the signer, its true impact on sender reputation stems from its interaction with DMARC. Crucially, the domain in header.i must align with the RFC5322.From address for a message to successfully pass DMARC via DKIM. If this alignment fails, it triggers a DMARC failure, which receiving servers interpret as a potential spoofing attempt, leading to damaged sender reputation, increased spam classification, or outright rejection, regardless of the DKIM signature's technical validity.
Key opinions
- Specific Identity Provider: Header.i functions as the Authorizing User Identifier (AUID) within a DKIM signature, pinpointing the specific identity, such as an email address or subdomain, responsible for signing the message.
- Enables Sub-Domain Signing: It allows for the specification of a signing identity that is a subdomain of the broader d= (signing domain) tag, providing flexibility for complex sending infrastructures and delegation of signing authority.
- Supports Multiple Senders: This mechanism enables a single primary domain to support multiple distinct signing entities or users, a capability frequently utilized by email service providers (ESPs) to sign on behalf of their clients.
- Core Authentication Detail: While often an internal configuration, header.i is a fundamental element for validating the authenticity of the email's origin through DKIM, signifying who took responsibility for the signature.
Key considerations
- DMARC Alignment Requirement: The primary importance of header.i for deliverability is its strict requirement to align with the RFC5322.From header domain for a DMARC pass. This alignment is crucial for sender reputation.
- Reputation Consequences of Misalignment: Failure to align the header.i domain with the 'From:' domain will result in a DMARC failure for DKIM, which receiving servers interpret as a potential spoofing attempt. This severely damages sender reputation and causes emails to be rejected or sent to spam folders.
- Indirect Impact on Reputation: Header.i itself does not directly affect sender reputation. Its influence is entirely indirect, stemming from its role in achieving DMARC alignment, which is critical for validating email authenticity.
- Beyond Technical DKIM Pass: Even if the DKIM signature is technically valid and passes its own checks, a DMARC failure due to header.i misalignment can still lead to non-delivery or spam classification, overriding a successful DKIM authentication.
Marketer view
Email marketer from Email Geeks explains that header.i corresponds to the i= tag in the DKIM signature, similar to header.d for d=. The i= tag is optional and can specify a more specific identity, such as an email address or a subdomain of the d= domain, that takes responsibility for the signature. He notes it appears in authentication-results due to the specific filter setup and advises not to be concerned about it.
5 Nov 2023 - Email Geeks
Marketer view
Email marketer from Mailchimp Support explains that while header.i identifies the signer in DKIM, its importance for sender reputation often comes down to DMARC alignment. For a message to pass DMARC with DKIM, the domain in the header.i tag (AUID) must align with the RFC5322.From header. If these domains differ, it can lead to DMARC failure, negatively impacting sender reputation and deliverability.
26 Feb 2025 - Mailchimp Support
What the experts say
3 expert opinions
The header.i field, an integral part of a DKIM signature, designates the specific identity, typically an email address or user agent, that is responsible for signing the message. This identifier is generated and set by the sending server during the signing process. For a DKIM signature to be successfully validated, the domain within the i= tag must strictly be a subdomain of the d= (signing domain) tag. A failure to establish this precise subdomain relationship will result in a DKIM authentication failure. While header.i is largely an internal configuration detail that external parties generally don't need to decipher, its accurate implementation is paramount. Any misconfiguration that leads to a DKIM failure can significantly harm sender reputation by increasing negative user interactions, ultimately impacting email deliverability.
Key opinions
- Identifies Signer: The i= tag in a DKIM signature identifies the specific user or agent responsible for signing the email, often presented as an email address.
- Server-Generated: Sending email servers are responsible for setting the value of the i= tag during the creation of the DKIM signature.
- Strict Subdomain Rule: For valid DKIM authentication, the domain specified in the i= tag must be a subdomain of the d= (signing domain) tag.
- DKIM Validation Dependency: A failure in the i=d subdomain relationship directly causes DKIM validation to fail, signaling an authentication issue.
Key considerations
- Direct Reputation Risk: When the i= domain is not a subdomain of the d= domain, the resulting DKIM validation failure directly harms sender reputation. This can lead to increased spam classifications or rejections.
- Internal but Critical: Although header.i serves primarily as an internal configuration detail, its correct setup, especially concerning its required subdomain relationship with the d= tag, is crucial for maintaining proper email authentication and deliverability.
- User Experience Impact: The negative effect on sender reputation stemming from header.i issues arises when such failures lead to adverse user interactions, such as emails being marked as spam or rejected by recipient systems.
- Focus on Validation: For external parties, the primary concern is whether the DKIM signature, including the correct i= configuration, passes validation, rather than understanding the granular political or technical intricacies of the i= tag's specification.
Expert view
Expert from Email Geeks explains that the i= tag was a significant political battle at the IETF and is primarily about internal configurations, meaning outside parties shouldn't need to understand its intricacies. She clarifies that i= is set by the sending server when creating the DKIM signature. She further advises that while any element in an email can be measured for reputation, it only negatively impacts a sender's score or gets 'dinged' if it results in more negative user interactions than positive ones.
13 Mar 2025 - Email Geeks
Expert view
Expert from Spam Resource explains that header.i in DKIM stands for 'identity' and indicates the user or agent responsible for signing the mail, often an email address. It notes that the 'i=' domain must be a subdomain of the 'd=' (signing domain) tag for valid DKIM authentication.
16 Feb 2024 - Spam Resource
What the documentation says
3 technical articles
The header.i field within an email's DKIM-Signature header identifies the 'Agent or User Identifier' (AUID), which specifies the particular identity, such as a user or system, responsible for signing the email. While header.i itself names the signer, its critical influence on sender reputation primarily arises from its role in DMARC alignment. For comprehensive email authentication, the domain specified in the header.i tag must align with the email's 'From:' domain. Both Google and Microsoft emphasize that this alignment is essential for DKIM to successfully pass DMARC checks. A failure in this alignment results in a DMARC 'fail' verdict, which receiving mail servers, including Google's and Microsoft's, interpret as a potential sign of spoofing, significantly damaging sender reputation and increasing the likelihood of emails being marked as spam or rejected.
Key findings
- AUID Identification: header.i in the DKIM-Signature specifies the 'Agent or User Identifier' (AUID), indicating the identity of the user or agent responsible for signing the email.
- Subdomain Constraint: For valid DKIM verification, the domain within the i= tag must be a subdomain of the d= (signing domain) tag.
- Policy Lookup Significance: The i= tag is crucial for policy lookup during the DKIM verification process, helping to determine the applicable signing policy.
- Alignment for Reputation: The signing identity specified by header.i directly impacts alignment checks, which are pivotal for DMARC and, consequently, influence sender reputation based on how receiving systems perceive the email's authenticity.
Key considerations
- DMARC Alignment is Key: header.i's primary impact on sender reputation for major providers like Google and Microsoft is through its alignment with the 'From:' domain as required by DMARC. This is essential for successful email authentication and deliverability.
- Direct Reputation Harm: Misalignment of header.i with the 'From:' domain leads to a DMARC 'fail' verdict, which directly harms sender reputation by increasing the likelihood of emails being marked as spam or rejected by receiving mail servers.
- Vendor Recommendations: Google and Microsoft strongly recommend DMARC implementation and stress the importance of header.i to 'From:' domain alignment for successful deliverability and to avoid negative reputation impacts.
- Verification vs. Alignment: While header.i is vital for the technical verification of a DKIM signature, its most significant role for overall deliverability and sender reputation comes from facilitating successful DMARC alignment with the 'From:' domain.
Technical article
Documentation from RFC Editor explains that the header.i tag in DKIM-Signature specifies the 'Agent or User Identifier' (AUID), which indicates the identity of the user or agent responsible for signing the email. It must be a subdomain of the d= tag. This tag is crucial for policy lookup during DKIM verification and directly relates to the signing identity, impacting alignment checks that can influence sender reputation if not correctly configured with the From: domain.
26 Jun 2023 - RFC Editor
Technical article
Documentation from Google Postmaster Tools explains that while header.i specifies the signing identity for DKIM, its primary impact on sender reputation for Google's systems comes through DMARC alignment. Google strongly recommends DMARC implementation, which requires the domain in the i= tag to align with the 'From:' domain for DKIM to pass DMARC successfully. Failure to align can result in emails being marked as spam or rejected, directly harming sender reputation.
1 Apr 2022 - Google Postmaster Tools Help
Do DKIM selectors affect email reputation?
Does the sender-id header impact email deliverability?
How does turning on DKIM impact domain reputation and email deliverability?
What is the relationship between MailFrom, Return-Path, DKIM signing, and Google Postmaster Tools, and how do they impact email delivery and domain reputation?
When changing subdomains for email, is it better to change the 5321.from or 5322.from header for deliverability, and how does DKIM alignment affect this?
Why does my email header show DKIM and SPF as none, and how do I fix Outlook deliverability issues?
