What is the Mail From field?

When emails are sent, there are two from fields, the Mail From and the Display From address.  The Display From address (technically referred to as RFC.5322 from address) is the from address that is displayed to the end user within their email client.  The Mail From (technically referred to as RFC.5321 from address) is the email address to which bounce messages are delivered.  The Mail From field is sometimes referred to as the Return Path address, Envelope From address, or Bounce address.
It may seem confusing to have an email with two from fields, but knowing the difference is important to properly setup your SPF records.
Taking a look at this email I received from GoPro, the Return-Path (5321.From) goes back to @bounce.email.gopro.com.  If I were to reply to the email, the message would go to @email.gopro.com. The Display From (5322.From) address is gopro@email.gopro.com.
GoPro-Headers
I would want to add the email address GoPro@email.gopro.com to my address book because that is the email address that is displayed in my email client. The reason why the Return-Path is different from the From address is because GoPro likely has an automated system that will process the bounce back messages (sent to @bounce.email.gopro.com) and automatically flag or unsubscribe those email addresses. This allows GoPro to setup automatic processing of the different mail streams sent to them, one stream being the bounce backs after a mailing and the second being an automated customer service system.
Where does SPF fit in?
SPF checks the Mail From (5321.From) address, not the Display From (5322.From) address.  In the example above, there should be an SPF record for the subdomain of bounce.email.gopro.com.  I can check the SPF record using our Authentication tools http://tools.wordtothewise.com/spf/check/bounce.email.gopro.com and I receive the following results:
SPF_GoPro
Checking the headers shows that GoPro does have a SPF record setup and the message was authenticated with SPF.
Authentication Results
For SPF records, make sure the SPF record matches the Mail From (From.5321)/Return-Path domain name.  Have your recipients add the Display From (From.5322) email address to their address book so they will continue to receive your mailings.

Related Posts

Office365/EOP IPv6 changes starting today

Terry Zink at Microsoft posted earlier this week that Office365/Exchange Online Protection will have a significant change this week. Office365 uses Exchange Online Protection (EOP) for spam filtering and email protection. One of the requirements to send to EOP over IPv6 is to have the email authenticated with either SPF or DKIM.  If the mail sent to Office365/EOP over IPv6 is not authenticated with SPF or DKIM, EOP would reject the message with a 554 hard bounce message.  Most mail servers accept the 554 status code and would not retry the message.  After multiple 5xx hard bounces to an email address, many mail servers would unsubscribe the user from future email campaigns.  The update starting today April 24, will change the error status code for unauthenticated mail to EOP from a 554 hard bounce to a 450 soft bounce and a RFC-compliant and properly configured mail server would then retry the message.
Prior to April 24, 2015, EOP responds to unauthenticated mail with a status code of: “554 5.7.26 Service Unavailable, message sent over IPv6 must pass either SPF or DKIM validation”.

Read More

Authentication and Repudiation

Email Authentication lets you demonstrate that you sent a particular email.
Email Repudiation is a claim that you didn’t send a particular email.
 
SPF is only for email authentication1
DKIM is only for email authentication
DMARC is only for email repudiation
 
1 SPF was originally intended to provide repudiation, but it didn’t work reliably enough to be useful. Nobody uses it for that now.

Read More

Four things to check before your next mailing

Like many bits of technology, email is often set-and-forget. Everything is checked and rechecked during setup, and then no one goes back and looks at it again. But mail programs are not static, and people make changes. These changes don’t really break things, but over time they can create their own set of problems.
Setting aside some time every quarter or even every year to check and make sure all the bits of mail are configured correctly is a good idea.

Read More