An SPF record is a DNS record that essentially states which IPs/domains are allowed to send email on behalf of the domain.

When using a third-party email service, the service often recommends using a "catch-all" SPF record for all of their servers. Here's what Sendgrid recommends:

v=spf1 include:sendgrid.net ~all

The domain that this record is associated with (e.g. example.com) will "allow" all email from all of sendgrid.net's domains.

It seems to me that an attacker could simply register for a Sendgrid account and send emails on behalf of example.com that would "pass" the SPF check.

Is this true?

I know that SPF isn't designed to verify message authenticity. It just seems a bit odd that in the right situation, such a widely-lauded technology has such an easily-exploited weakness. And yes, I do realize that requesting a private IP from the third-party email service would alleviate this concern.

  • ...and yes, I do know about DKIM and DMARC. :) – rinogo Jun 7 '18 at 16:50
  • 1
    My guess is that Sendgrid doesn’t allow to send mail for a domain not registered to your account. Also, how long do you think an account doing this would exist? – Sven Jun 7 '18 at 17:06
  • 1
    This isn't a weakness of SPF. It's a potential weakness of Sendgrid. – ceejayoz Jun 7 '18 at 17:34
  • @Sven I'm not sure how Sendgrid would detect that anything suspicious was going on, so I would suspect an account could do this indefinitely until I detected and reported it. (As you suggest, hopefully they have some sort of domain ownership validation as a pre-requisite. I'm not sure as I'm just in the evaluation stage at this point) – rinogo Jun 7 '18 at 17:48
  • 1
    @rinogo The DKIM records I'm given to validate a domain in Sendgrid appear to include my Sendgrid user ID. I don't know if they'll refuse to send for my domain without this verification, but they do appear to have a way of differentiating between multiple accounts for the same domain. – ceejayoz Jun 7 '18 at 18:13

The DNS record that you mention says:

I, the owner of this domain, trust that Sendgrid will verify the From: field of all the emails that leave all SMTP servers in their IP pools and that Sendgrid will prevent unauthorized content.

It's not what RFCs say, but that's the practical meaning.

That's the architecture of SPF. Calling it a flaw is nonconstructive although understandable. It's true that under DMARC umbrella, the SPF is intended as solely a fallback mechanism in case DKIM fails (DKIM tends to be statistically somewhat error-prone). The fact that bulk-mail services offer SPF as a primary mechanism, often don't mention DKIM at all, and as often completely fail to authorize the From: header speaks about their cluelessness in their core business.

In face of this, I always recommend to go with From: dont-reply@mass-mailing.example.com which somewhat mitigates the impact of impersonating as a CEO, CFO, HR, etc. Nevertheless whoever wants me to set that domain record, I always ask them to accept the risk of From: ceo@mass-mailing.example.com. (I insert the real name of their CEO. They usually accept this. Duh.)

  • Thank you for your helpful answer! So, if I'm understanding, you're agreeing that "yes, SPF does have a weakness in this scenario", correct? Also, a minor point, note that I deliberately never used the word "flaw", only "weakness". :) – rinogo Jun 7 '18 at 17:45
  • Well, I don't know what's a "weakness" in a sysadmin context, and I've adopted a strict policy for myself to only use words that can be predictably understood by both me and the interlocutor. Surely, what you describe is not a security vulnerability. Surely, it's also not what most people expect of an anti-spoofing mechanism - that's why it might be called an architectural flaw. Surely, SPF alone is inadequate for your scenario. – kubanczyk Jun 7 '18 at 18:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.