Why would I see two domains in the 'Mail From' field of an email header?

The primary 'Mail From' domain is the RFC 5321.MailFrom (envelope sender or return-path), used for server-to-server communication and bounce handling. The second domain, often seen in Authentication-Results headers, might be the authserv-id , which is the hostname of the receiving server that performed the authentication, not another sending domain.

Does having multiple or unaligned domains in email headers affect email deliverability?

Yes, it significantly affects deliverability. Both the Mail From and 'Header From' domains have their own reputations. If these domains are not aligned (especially for DMARC) or if either has a poor reputation, mailbox providers are more likely to filter your emails to spam or reject them entirely. Subdomains can help manage this.

How do SPF, DKIM, and DMARC relate to the domains in my email headers?

The 'Mail From' domain (RFC 5321.MailFrom) is verified by SPF (Sender Policy Framework), ensuring the sending IP is authorized. The 'Header From' domain (RFC 5322.From) is what recipients see and is typically signed by DKIM (DomainKeys Identified Mail). DMARC (Domain-based Message Authentication, Reporting, and Conformance) then checks for alignment between these domains to confirm sender legitimacy.

What is the difference between a custom sending domain and a shared domain from an ESP?

A shared domain means your Mail From or DKIM signing domain belongs to your ESP, not your brand. This can make DMARC alignment more challenging and tie your reputation to other senders using the same shared domain. Custom domains or subdomains are generally preferred for better control over reputation.

Why are there two domains in the 'Mail From' field of an email header, and how does it affect deliverability? - Technical - Email deliverability - Knowledge base

When examining email headers, particularly for deliverability issues, discovering what appears to be two distinct domains within the 'Mail From' field can be confusing. It raises immediate questions about email routing, sender identification, and ultimately, why emails might not be reaching the inbox. This phenomenon is a nuanced aspect of how email protocols operate and how mailbox providers (MBPs) interpret sending information.

The existence of these multiple domain references, while sometimes confusing, is often a standard part of the email sending process, though it can also signal an issue if not properly understood or configured. Understanding each domain's role is critical for diagnosing and resolving email deliverability challenges, especially when dealing with specific mailbox providers like

Outlook.com or

Gmail.

The two crucial 'From' domains

Email headers contain a wealth of information about a message's journey and origins. The 'Mail From' field often refers to what's technically known as the envelope from address (also called the RFC 5321.MailFrom or return-path). This is the address where bounce messages are sent, effectively the hidden return address for the sending server. In contrast, the 'From' field you see in your email client, known as the header from (or RFC 5322.From), is the friendly sender address displayed to recipients.

While the query refers to two domains in the 'Mail From' field, it's often a misinterpretation of how email authenticationprotocols like SPF and DKIM interact with various header fields. Sometimes, particularly in the Authentication-Results header (which is added by the receiving server), you might see the smtp.mailfrom domain followed by the authserv-id. The authserv-id represents the receiving server's hostname that performed the authentication, not another sending domain. This can lead to the impression of two sending domains being present.

For example, in a raw header, you might see something like: Authentication-Results: spf=pass (sender IP is 1.2.3.4) smtp.mailfrom=yourdomain.com; hotmail.com; Here, yourdomain.com is the actual smtp.mailfrom domain, while hotmail.com is the authentication service identifier from

Hotmail, rather than a second sending domain.

RFC 5321.MailFrom (Envelope Sender)

This is the address used for the actual SMTP communication between sending and receiving servers. It's primarily used for handling bounce messages and is checked by SPF (Sender Policy Framework).

Purpose: Technical return address for the email transfer process.
Visibility: Not typically seen by end-users, only in raw email headers as Return-Path.
Authentication: The primary domain verified by SPF.

RFC 5322.From (Header From)

This is the 'friendly' From address that email recipients see in their inbox. It represents the apparent sender of the email and is crucial for brand recognition and user trust.

Purpose: Identifies the human-readable sender of the email.
Visibility: Prominently displayed in email clients to the recipient.
Authentication: The domain generally signed by DKIM and aligned by DMARC.

How email authentication utilizes domains

Email authentication protocols like SPF, DKIM, and DMARC rely on these domains to verify a sender's legitimacy and prevent spoofing. SPF (Sender Policy Framework) checks the Mail From domain to ensure that the sending IP address is authorized to send mail on its behalf. If the IP isn't listed in the domain's SPF record, the email may fail SPF authentication.

DKIM (DomainKeys Identified Mail) adds a digital signature to the email header, which is then verified by the receiving server against a public key published in the sending domain's DNS records. The domain that signs the email (the d= tag in the DKIM signature) is typically, but not always, the same as the 'Header From' domain. This is where domain alignment becomes critical for DMARC.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) pulls these elements together. It requires either the Mail From domain (for SPF) or the DKIM signing domain to align with the 'Header From' domain. Alignment means they share the same organizational domain, or the DKIM signing domain should be the same as the 'Header From' domain. Failure in this alignment, especially when a strong DMARC policy (like quarantine or reject) is in place, can lead to messages being rejected or sent to spam.

The importance of domain alignment

For optimal deliverability, ensure that the domain in your Mail From (envelope sender) and your DKIM signing domain are aligned with your 'From' header domain. This consistency helps mailbox providers (MBPs) confidently verify your identity.

Subdomains: Often, ESPs will use a subdomain for the Mail From (e.g., bounces.yourdomain.com). This is fine as long as it aligns with the 'Header From' domain. Learn more about changing subdomains for email.
Reputation: A consistent and aligned domain structure helps build a unified and positive domain reputation.

Impact on deliverability and sender reputation

The reputation of both the Mail From domain and the 'Header From' domain significantly impacts email deliverability. Mailbox providers (ISPs) assess both, among other factors, to determine if an email is legitimate or potential spam. A poor reputation on either can lead to emails being sent to the junk folder or blocked entirely. For instance, if your transactional emails use a Mail From domain that has been used for spammy 'business development' emails, it can drag down the deliverability of your legitimate transactional mail.

To protect your primary domain's reputation, many organizations choose to use subdomains for different email streams. For example, marketing.yourdomain.com for campaigns and transactional.yourdomain.com for receipts and password resets. This strategy helps isolate reputation issues, meaning if your marketing emails hit a spam trap, your transactional emails are less likely to be impacted. This approach also affects how blocklistsor blacklists might affect your overall sending.

Furthermore, factors like your domain's age, sending volume, and complaint rates all contribute to its reputation. A newer domain or one with a history of high bounces or spam complaints will struggle more with deliverability. Mailbox providers like

Yahoo (and Hotmail, now

Outlook.com) continuously monitor these metrics. Maintaining a positive sender reputation is an ongoing process.

Domain Type	Impact on Deliverability	Example
Aligned domains (SPF/DKIM/DMARC)	High likelihood of inbox placement. Signals legitimacy and trust to ISPs.	Mail From: mail.yourdomain.comFrom: yourdomain.com
Misaligned domains	Increased risk of landing in spam or being rejected, especially with DMARC in place. Erodes sender trust.	Mail From: sharedesp.netFrom: yourdomain.com
Subdomains for segmentation	Helps protect root domain reputation. Isolates sending traffic, preventing one stream from affecting another.	Mail From: bounces.yourdomain.comFrom: info@yourdomain.com

Best practices for domain management

To ensure your emails reach the inbox, consistently using your own domain for both the Mail From (envelope sender) and 'Header From' addresses is a foundational best practice. This means authenticating your sending domain properly and ensuring that email service providers (ESPs) are configured to use your domain, or a subdomain of it, for the underlying technical sending aspects. This setup promotes trust and consistent brand identity.

Implement and maintain robust email authentication: SPF, DKIM, and DMARC are non-negotiable for modern email deliverability. SPF records should explicitly authorize all IP addresses that send mail on behalf of your Mail From domain. DKIM signatures should be correctly configured to cover your 'Header From' domain. DMARC ties these together, instructing receiving servers on how to handle emails that fail authentication or alignment. A well-configured DMARC record provides crucial visibility into your email ecosystem.

Example SPF record for your Mail From domainDNS

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Regularly monitor your domain's reputation with tools like Google Postmaster Tools and perform email deliverability tests. Pay attention to bounce rates, complaint rates, and any blocklist (or blacklist) listings. Addressing these issues promptly is crucial for maintaining a healthy sending reputation and ensuring your emails consistently land in the inbox.

Using dedicated subdomains

Separate your email traffic using dedicated subdomains (e.g., marketing.yourdomain.com and transactional.yourdomain.com) for different types of emails. This isolates the reputation of each stream.

Reputation isolation: A problem with one email stream (e.g., marketing) won't necessarily impact the deliverability of another (e.g., transactional).
Clearer tracking: Makes it easier to analyze performance metrics for specific campaigns.

Views from the trenches

Best practices

Always align your RFC 5321.MailFrom and RFC 5322.From domains, especially with DMARC enforced.

Use subdomains for different types of email sends, like 'm.yourdomain.com' for marketing and 't.yourdomain.com' for transactional.

Regularly monitor your domain's reputation using tools and DMARC reports to catch issues early.

Ensure all sending IPs are correctly listed in your SPF record to prevent authentication failures.

Common pitfalls

Assuming the 'Mail From' domain is the only one affecting deliverability, ignoring the 'From' header.

Not aligning SPF, DKIM, and DMARC with the 'Header From' domain, leading to DMARC failures.

Using shared domains from ESPs for 'Mail From' without proper DMARC alignment.

Ignoring bounce messages, which indicate issues with your Mail From domain and list hygiene.

Expert tips

For Microsoft/Hotmail issues, check the `Authentication-Results` header carefully to distinguish between `smtp.mailfrom` and the `authserv-id` (receiving server's domain).

A poor reputation on any domain involved in the email transaction can contribute to deliverability issues, not just the primary sending domain.

While RFCs allow multiple addresses in the `From` header, it's generally best practice to use a single, consistent address for deliverability.

Understand that mailbox providers have varying interpretations and implementations of email headers and authentication results.

Marketer view

Marketer from Email Geeks says they were investigating Hotmail deliverability problems and noticed what appeared to be two domain names in the 'Mail From' field.

2020-08-04 - Email Geeks

Expert view

Expert from Email Geeks says the `smtp.mailfrom` is the envelope from address, which is checked by SPF.

2020-08-04 - Email Geeks

Ensuring robust email delivery

The appearance of what seems to be two domains in an email's 'Mail From' field, particularly in authentication results headers, is a common point of confusion rooted in the technical intricacies of email protocols. It highlights the distinction between the hidden envelope sender (Mail From) and the visible sender ('Header From'). While the former is crucial for SPF authentication and bounce handling, the latter dictates user perception and is central to DKIM and DMARC alignment.

Achieving and maintaining high deliverability hinges on a clear understanding of these domains and their interplay. By ensuring strong domain alignment, implementing proper authentication records (SPF, DKIM, DMARC), and actively monitoring your sender reputation, you can navigate these complexities and consistently land your emails in the recipient's inbox.