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

Authenticating with SPF: -all or ~all

What is SPF?

Sender policy framework (SPF, RFC 7208) is an authentication process that ties the 5321.from (also known as the mail from, envelope from or return path) to authorized sending IP addresses. This authorization is published in a TXT record in DNS. Receivers can check SPF at the beginning of a SMTP transaction, compare the 5321.from domain to the connecting IP address and determine if that IP is authorized to transmit mail.

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

Spam, Phish or Malware?

Some mornings I check mail from my phone. This showed up this morning.
PizzaHutMail
My first thought was “oh, no, Pizza Hut is spamming, wonder who sold them my address.”
Then I remembered that iOS is horrible and won’t show you anything other than the Friendly From and maybe it was some weird phishing scheme.
When I got to my real mail client I checked headers, and sure enough, it wasn’t really from Pizza Hut. I’m guessing actually malware, but I don’t have a forensics machine to click the link and I’m not doing it on anything I can’t wipe (and have isolated from the rest of my network).
The frustrating thing for me is that this is an authenticated email. It not from Pizza Hut, the address belongs to some company in France. Apparently, that company has had their systems cracked and malware sent through them. Fully authenticated malware, pretending to be Pizza Hut, and passing authentication on various devices.
Pizza Hut isn’t currently publishing a DMARC record, but in this case, a DMARC record for Pizza Hut wouldn’t matter. None of the email addresses in the headers point to Pizza Hut.
I spent last week listening to a lot of people discussing DMARC and authentication and protecting people from scams and headers. But those all the protocols in the world won’t protect against this kind of thing. Phishing and malware can’t be fixed by technology alone. Even if every domain on the planet published a p=reject policy, mail like this would still get through.
 
 
 

Read More