SPF looks at the bounce address of an email when doing its check. (The bounce address is also referred to as the Return-Path, the MAIL FROM address, the envelope address, and in some circles, the RFC5321.MailFrom address.) When SPF does its check, it will look for an SPF record using the domain found in the bounce address.
DMARC attempts to correlate the results of checking SPF and DKIM with the domain found in a message’s From: header. It’s the domain of the From: header that ends up tying together all things DMARC.
Companies often misunderstand how SPF works and publish tech articles that instruct their customers to include the company’s own SPF record. However, this ends up doing nothing if the company uses its own domain in the bounce address*. When an email receiver processes a piece of email, it will look at the company’s SPF record — and not the SPF record of the customer.
Two unwanted things happen due to this misconception:
- People add unnecessary “includes” into their SPF records. This causes SPF records to bloat and for some to struggle with maintaining concise and accurate records (“too many DNS lookups”, anyone?).
- Confusion is introduced as people just want to get SPF into place to get their DMARC deployment finished. The result is that SPF passes, but still DMARC fails.
For SPF to work correctly in the context of DMARC, the bounce address has to be relevant to the domain of the From: header.
Unfortunately, a lot of companies that send email on behalf of others do not currently let their customers change the bounce address to the customer’s domain. This is slowly changing, but first companies have to understand the basics of how SPF works.
* There was a technology once called SenderID that tried to perform SPF-like checks, except it used the From: header domain (among others) as the thing to check. SenderID attempted to reuse existing SPF records, causing even more confusion. SenderID is obsolete technology.