10

I just got an email from some random person's name "via" info@mydomain.com, although info@mydomain.com is just a distribution group within G Suite.

We have an up-to-date SPF record added from Google, and I'm not quite sure what or how another person is able to send an email via my domain.

Here are some references from the message source, without giving any specific information to my domain or the receipients:

Date: Mon, 01 Apr 2019 23:41:44 -0500
Subject: Mass Shootings orchestrated to pass gun control for the Federal
 Reserve Shareholders planned U.S. Holocaust- How can your industry help?
From: 'Random Person' via Info <info@mydomain.com>
<snipped>
Message-ID: <186271992.14957742.1554180104822@mail.yahoo.com>
Thread-Topic: Mass Shootings orchestrated to pass gun control for the Federal
 Reserve Shareholders planned U.S. Holocaust- How can your industry help?
Thread-Index: AWY0NTc5UrmPA22gl2edULFwYvLC7TIwMTU5
References: <186271992.14957742.1554180104822.ref@mail.yahoo.com>
Mime-version: 1.0
Content-type: multipart/alternative;
    boundary="B_3637013229_1574776269"

All of our users have 2FA enabled, although I don't think that's relevant here. This is clearly a spoofed emailed as info@mydomain.com is not a registered account within the domain (just verified it).

Any ideas how this may have happened and how to prevent it?

Also, this message doesn't seem to contain any valuable information other than it was potentially leveraging Yahoo to send email on "behalf" of my domain, which I'm not quite sure how that worked.

LewlSauce
  • 213
  • 2
  • 6
  • 9
    You snipped out every single piece of the header that would help to figure this out. What did the SPF part of the header say? What were all the "from" addresses? – schroeder Apr 02 '19 at 06:44
  • 2
    Actually, and this surprised me too, this is all of the email content except for the "To" recipients. Everything underneath "boundary=" is the body of the email which contains the long paragraphs of text. It doesn't make sense to me either and I've personally investigated message headers for other resources. This got me a little stumped. – LewlSauce Apr 02 '19 at 06:45
  • 1
    You seem to contradict yourself: "info@mydomain.com is just a distribution group within G Suite" and "info@mydomain.com is not a registered account within the domain". Can you explain? – schroeder Apr 02 '19 at 06:45
  • @schroeder Yes. info@mydomain.com is just a distribution group, not an actual user account. In other words, there is no way to login to info@mydomain.com - it's just a group with associated users. – LewlSauce Apr 02 '19 at 06:46
  • Then you have your answer: you do not have SPF ***checking*** set up. – schroeder Apr 02 '19 at 06:46
  • @schroeder sorry I'm misunderstanding. My TXT records includes a SPF record as suggested by Google. What do you mean by "SPF checking" set up? – LewlSauce Apr 02 '19 at 06:47
  • 1
    No images of text please. What you originally had was perfect. – schroeder Apr 02 '19 at 06:53
  • If you go to the Google Groups interface for `info@mydomain.com`, does this thread show up there? Or does it only show up in your individual `@mydomain.com` Gmail? If the former, can you please do a show original on the message *in the Groups interface?* You may get more headers that way. – Kevin Apr 02 '19 at 17:46
  • 1
    @Kevin Nope, no messages show up in the google groups interface. It only shows up in the G Suite `@mydomain.com` inbox. I remember trying to find a way to disable messages from posting there (like a forum) awhile ago too, so perhaps that may be why. – LewlSauce Apr 02 '19 at 17:50
  • That message subject is really something. – user253751 Apr 03 '19 at 02:41

4 Answers4

18

Having an SPF record in your DNS records helps the recipient know which email server is legtimiate for your domain. The recipient looks up the sending domain for the valid server IPs and then decides what to do with the email.

  1. If the sending IP is on the list, then the email is likely OK.

  2. If the sending IP is not on the list, then it should be treated suspiciously.

This checking logic requires that the receiving email server is configured to check for SPF records. If you are not checking for SPF records, then the entire SPF checking process is not done.

If your email headers do not include the SPF fields, then your email server is not set up to check for SPF and it is not protecting your company in this way.

You need to look up your email service documentation to figure out how to turn on SPF checking.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • Gotcha. Sounds great. I'm using G Suite and will look up additional information. I sincerely appreciate your help. So from what it sounds like, there's technically no way to prevent someone from spoofing your domain; only ways to ensure checks are in place so that recipients can validate whether or not it's spam (aka SPF and DMARC) records. Is that correct? – LewlSauce Apr 02 '19 at 06:54
  • Don't think of it as "spam" but as an illegitimate sender. SPF records list what you define as a legitimate sender. Recipient email servers perform a "lookup" when it receives an email to see if the sending IP is a legitimate sender for your domain (that's why the list is in DNS). – schroeder Apr 02 '19 at 06:56
  • SPF, DMARC, DKIM protect you from more than just spam. – schroeder Apr 02 '19 at 06:57
  • Makes sense. Sorry, didn't really mean spam per se, but "spoof." From what I've gathered, you can't prevent someone from spoofing your domain, only checks so that the recipient can verify if it's spoofed or not. Correct me if I'm wrong. I appreciate the help! – LewlSauce Apr 02 '19 at 06:58
  • 2
    Anyone can spoof the "From" address. And there are/were lots of valid reason for this. SPF/DMARC prevents abuse of this feature. – schroeder Apr 02 '19 at 07:08
  • @schroeder though annoyingly it also prevents use of this feature (ie, all the valid reasons to which you refer). – MadHatter Apr 02 '19 at 14:54
  • @MadHatter unless you list the approved senders in the record – schroeder Apr 02 '19 at 15:04
  • 1
    @schroeder from which I take it that you don't regard RFC-compliant mailing lists as a valid use of header-From "spoofing"? – MadHatter Apr 02 '19 at 19:01
8

Just having a SPF record does not mean that nobody is able to use your email address as the claimed recipient for spoofed messages.

First, SPF only cares about the SMTP envelope and not about the From field in the mail header. It is no problem to send a mail where both are different. There are no information in your question of what the SMTP envelope was (usually shown as Return-Path field in the mail header) but it is actually common that both are different when spoofing mails. To care about the From you would additionally need to setup DMARC.

And even if both SPF and DMARC are setup the recipient of the mail would actually need to check this. While many check SPF most don't check DMARC.

For more information see also Why set up DMARC for SPF if it's already set up for DKIM?.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • The OP is using G suite which checks SPF records. This answer sounds like far more likely to be correct than the accepted answer. – Calimo Apr 02 '19 at 09:49
2

Actually the SPF record only tells which server(s) legitimate mails using your domain may come from - and we're talking envelope information (SMTP/RFC2821) here, not the From line inside the mails (RFC2822).

Inside your mail program you'll normally only see the mail content (RFC2822), so a mail using your domain in the From line may actually have been sent using a different envelope sender and you'll only be able to see that if you look at the headers where a line like 'X-Apparently-From' would reveal the sender used to deliver the mail.

Also, if one of the servers specified in your SPF is compromised, mails using your domain can be sent through it quite legitimately.

P. Goetterup
  • 121
  • 2
  • Thanks. Based on the email headers, it looks like the email was sent from Yahoo, which makes no sense to me. – LewlSauce Apr 02 '19 at 13:35
0

The first line of headers should always be
Received: from sender.hostname (203.0.113.0) by your.hostname
Each MTA that receives the message, including your MTA, it is supposed to prepend this header to it.

All messages received by a MTA will have at least one. The only way to have none is not receiving it over SMTP. Is it possible that someone added this message directly into your local mailbox/maildir copy, bypassing the smtp server?

user185953
  • 80
  • 10