4

My understanding is that SPF can be used to define a set of IP addresses that are permitted to send outbound emails on behalf of a domain. If a mail server that is not included in the set of permitted IP addresses sends an email, the receiving server could perform the TXT record lookup on the from domain and inspect the record to help determine whether it should soft fail or hard fail an inbound email.

E.g. 

dig my-site.com TXT
"v=spf1 include:_spf.google.com include:servers.mcsv.net -all"

I thought that this record was basically saying "allow any servers indicated by the TXT record found at spf.google.com or servers.mcsv.net and fail anything else.

Then I came across this: https://www.intercom.com/help/configure-intercom-for-your-product-or-site/configure-intercom-for-your-team/a-guide-to-sending-email-from-your-own-address

Do I need SPF? No, Intercom handles that for you. Emails sent from Intercom include a return-path header. When a recipient mail server receives one of our emails and checks the SPF record of the domain in our return-path, they will see that our sending IP addresses are authorized senders. This means emails sent through Intercom will pass authentication automatically and you don't need to set up any records yourself.

This confuses me. Doesn't this mean that intercom in this case (also anyone on the internet using the same technique) can send an email that appears to come from my-site.com despite the fact that I have used an SPF record which is supposed to fail anything that isn't in my set of white-listed IP addresses? Wouldn't the person receiving the email see this as being "from" me@my-site.com AND as an SPF pass, even though the sending server's IP address may not have been one of my authorized IP addresses?

Note, I do use DKIM and DMARC as well - but I want to isolate this discussion to just the SPF side of things.

schroeder
  • 123,438
  • 55
  • 284
  • 319
David
  • 167
  • 6

2 Answers2

4

When we're talking about "From" in regards to email, it can refer to two things:

  1. The "From: " header
  2. The "Envelope From" that is exchanged between email servers directly when establishing a connection.
  3. They don't have to be the same.

When your client connects to the server to send email, here's a simplified exchange between them:

client: HELO client.example.com
server: Hello, client.example.com, nice to meet you
client: MAIL FROM: <bjones@example.com>
server: Okay
client: RCPT TO: <csmith@example.com>
server: Okay, go ahead with the message, terminate with a single '.'
client:
From: Junie B. Jones <bjones@example.com>
Subject: Important discussion

Hello, Claire...
...blah...
...blah...
.
server: Okay, accepted for delivery

You'll see above that the "From" showed up twice: first time as part of MAIL FROM, and the second time as From: in the body of the message. Only the first one (called "Envelope From" or "Return Path") is important as far as mail servers are concerned -- the second one is mostly for looks. In fact, it can be missing entirely.

What Intercom is saying is that when they send a message, they will send it like this:

client: HELO foo.intercom.com
server: Hello, foo.intercom.com, nice to meet you
client: MAIL FROM: <someaddr@intercom.com> # <-- envelope-from
server: OK
client: RCPT TO: <somedestination@example.com>
server: OK, proceed, terminate with a single "."
client: 
From: Junie B. Jones <bjones@example.com> # <-- cosmetic "From:"
Subject: Mailing from intercom

...blah...
...blah...
.
server: OK, accepted for delivery

Many mail clients will show this as "Junie B. Jones <bjones@example.com> via foo.intercom.com" when displaying the email, to indicate the discrepancy between the Envelope-From and the cosmetic From, but it's considered a kosher practice when it comes to email.

SPF specifically only deals with Envelope-From, and ignores the cosmetic "From:" field:

mricon
  • 6,238
  • 22
  • 27
1

The Return-Path header represents the mail from command issued in SMTP (RFC 5321), also known as the "envelope sender". Sender Policy Framework checks only SMTP information: the host as identified with SMTP EHLO or HELO commands and the envelope sender.

SPF run by a system that does not have direct access to the SMTP information must extract the envelope sender from the Return-Path header and the HELO host from the appropriate Received header (or else trust the Received-SPF header).

I suspect that your envelope sender represents the account you use to authenticate with Intercom, which means you will pass Intercom's SPF but you will not be "aligned" for DMARC since that does not match your From header's domain.

This means you still need your own SPF record that blesses Intercom's outbound servers (not necessarily their entire record; you don't want to allow their marketers unless they're also your marketers). The record you have above looks sufficient. Set up a DMARC record with an rua key to send aggregate reports to a dedicated mailbox and you'll see (over a long period of time) everything that uses your domain in its From header without passing SPF or DKIM that is aligned with your domain.

Community
  • 1
Adam Katz
  • 9,718
  • 2
  • 22
  • 44