5

I always thought that receiving email servers check the "from" domain's SPF record to verify that the sending server is allowed to send email. For example, if I sent email from "atte@atte.com", the receiving email server would query DNS records for atte.com and verify that the server which is sending mail is allowed to send mail for this domain.

But today I came across this article, which claims that nowadays email servers don't care about the "from" domain's SPF record - instead, they care about the "Return-Path" domain's SPF record. The "Return-Path" header is used for bounces etc. and is generally not visible to email recipient. Doesn't this makes spoofing trivially easy?

My question is: is the information provided in the article correct or am I potentially running into deliverability issues if my SPF record is not listing the sending server as an allowed sender? Note that I'm not asking a question about a theoretical world where everyone adheres to standardized protocols, but rather a practical question about the actual world where email providers have extremely aggressive proprietary spam filtering systems.

Edit: This is not a duplicate. Because I was requested to do this, I will go through the linked "possible duplicates" 1 by 1 below:

Why set up DMARC for SPF if it's already set up for DKIM?

The question linked above is asking why set up DMARC if SPF and DKIM are already set. This is entirely different from my question "how do most common email providers use the SPF record in 2019".

Security of SPF vs SPF and DKIM in email

The question linked above is asking what are the advantages of DKIM, if SPF is already set. So a completely different question again.

DMARC policy result when exactly one of SPF and DKIM fails and exactly one succeeds

The question linked above has practical relevance for me, since it answers the issue that I have in practice. However, it does not answer the question I posted here. The question I posted implies that the SPF record is not set, which is clearly different from the situation where the SPF record is set.

Atte Juvonen
  • 440
  • 1
  • 4
  • 10
  • 1
    Possible duplicate of [Security of SPF vs SPF and DKIM in email](https://security.stackexchange.com/questions/151241/security-of-spf-vs-spf-and-dkim-in-email), [DMARC policy result when exactly one of SPF and DKIM fails and exactly one succeeds](https://security.stackexchange.com/questions/171387/dmarc-policy-result-when-exactly-one-of-spf-and-dkim-fails-and-exactly-one-succe), [Why set up DMARC for SPF if it's already set up for DKIM?](https://security.stackexchange.com/questions/171034/why-set-up-dmarc-for-spf-if-its-already-set-up-for-dkim). – Steffen Ullrich Feb 05 '19 at 05:26
  • 1
    I'm not sure what you are asking. The main part of the question is a question about what SPF actually provides, i.e. check of `SMTP.MAILFROM` (SMTP envelope, usually put as `Return-Path` into the header) vs `RFC822.FROM` (From in mail header). But then you claim that you actually want to know how SPF gets used in practice. Do you expect that mail providers use SPF for something it is not designed for in the first place (i.e. check RFC822.FROM) or what kind of answer do you expect here? – Steffen Ullrich Feb 05 '19 at 06:45
  • In short the answer would be that mail providers don't use SPF to provide sender integrity by itself since SPF was never designed for this purpose and cannot be used for this. It can only be used for this purpose if additionally DMARC is provided by the senders domain. So the question would be more if the providers check DMARC (most do) and also provide DMARC together with SPF or DKIM for their own domains (most provide SPF and/or DKIM but not DMARC). – Steffen Ullrich Feb 05 '19 at 06:47
  • Yes, I expect mail providers to use SPF for something it is not designed for in the first place: as one more input to their spam filtering systems. Perhaps I should have started by explaining my motivation: I'm looking into email deliverability issues. I'm now testing Postmark, and I'm getting pretty good deliverability. A few small ISPs are dropping my mail, and one is placing it into spam. I'm wondering if these issues are caused by my SPF record, which is not designating Postmark as an eligible sender. FYI I am providing DMARC as well. – Atte Juvonen Feb 05 '19 at 07:14
  • I edited OP now to narrow down the scope of my question so that hopefully the question is not unclear anymore. – Atte Juvonen Feb 05 '19 at 07:19
  • @SteffenUllrich When you refer to "claimed sender", you mean the domain in the "FROM" field, right? And the article I linked in OP is making the claim that nowadays servers in practice do not check the "FROM" field to verify sender, but instead check the "RETURN-PATH" field to verify sender, which doesn't really make sense to me. – Atte Juvonen Feb 05 '19 at 07:24
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/89271/discussion-between-steffen-ullrich-and-atte-juvonen). – Steffen Ullrich Feb 05 '19 at 07:24

2 Answers2

3

From the beginning SPF test has compared the envelope sender against the published DNS record. This article is wrong claiming that this has been changed.

SPF is simply designed against forged senders, not forged headers. DKIM is designed to protect the headers and the body against forging and tampering. The From: header is always signed, other headers being optional.

DKIM can only protect mail that has been signed, but it doesn't provide a mechanism to prove that an unsigned message should have been signed. DMARC alignment can enforce DKIM by telling the receiver how they should handle unsigned messages.

SPF and DKIM protects your email domain against different threats. The only efficient solution against email spoofing is to use SPF+DKIM+DMARC together in a combination that allows all your own email scenarios and restricts everything else.

To answer the new question after the modification:

  • You need SPF record to match the envelope sender. Your SPF record doesn't need to match the sender in the From: header as it's never tested against the SPF record.

  • You should also implement DKIM+DMARC. This protects the From: header.

  • With all three set, a 3rd party email server can send email on your behalf using your domain in the From: header, if they have a matching DKIM signature. The envelope sender must match the SPF record: it can be their own domain, or you can add their servers to your SPF record to allow using your domain. Both are equally good, as the receiver only sees the From: header, and it's validated by DKIM.

Esa Jokinen
  • 16,100
  • 5
  • 50
  • 55
  • From your post it is unclear why SPF would be needed. If DMARC says all messages must be signed, then the receiver knows how to handle unsigned messages. And if a message is correctly signed with DKIM, the receiver knows it was sent by the authorized server. So SPF is not needed? – Atte Juvonen Feb 05 '19 at 05:20
  • 4
    DMARC relies either on SPF or DKIM, i.e. one with the RFC822.FROM aligned DKIM header (domain) or an aligned SPF record (SMTP.MAILFROM) is sufficient and not both are needed. SPF is the simpler to setup method compared to DKIM (DNS record vs. changes to the sender MTA which adds signature) and that's why more broadly used but one needs essentially only DKIM+DMARC or SPF+DMARC and not both. DKIM is usually considered more robust against mail forwarding in mailing lists etc. – Steffen Ullrich Feb 05 '19 at 05:23
  • That's true. DMARC could say that unsigned message from a valid SPF source is still ok. Using them all together works against the widest range of spoofing. We must remember that not every recipient implements them all: if you implement DKIM+DMARC at the sender side, you still should protect your domain with SPF. The mailing list scenarios could easily be handled with changing the envelope sender while keeping the `From:` header. That's why SPF+DKIM+DMARC, while your perspective is totally valid, too. – Esa Jokinen Feb 05 '19 at 05:37
  • @SteffenUllrich: Actually [this](https://security.stackexchange.com/a/171046/70406) answer puts it all together quite perfectly! – Esa Jokinen Feb 05 '19 at 05:46
1

Most modern email providers use a combination of DKIM and SPF information. Per Google's support documentation on how to respond when your emails are getting blocked with Gmail:

"Fix messages that aren't authenticated First, make sure messages you sent are authenticated using DKIM (preferred) or SPF.

Next, check out these tips for sending bulk messages with Gmail:

Use RSA keys that are at least 1024-bits long. Emails signed with less than 1024-bit keys are considered unsigned and can easily be spoofed. Gmail combines user reports and other signals, with authentication information, when classifying messages. Authentication is mandatory for every mail sender to ensure that your messages are correctly classified. For best practices, see Gmail's Bulk Senders Guidelines. Learn how to create a policy to help control unauthenticated mail from your domain."

DarkMatter
  • 2,671
  • 2
  • 5
  • 23