HN Explorer

Ask HN: A spammer is spoofing my email address; what do I do?

143 points by hellofunk ↗ HN
About every 15 seconds all day, another Mail Delivery Subsystem Status Notification Failure pops in from random servers around the world for some email that supposedly I sent, but of course did not. Apparently someone is sending out thousands of emails as coming from my address, and there is nothing I can do about it, right? Here are my questions:

1) Or, is there something I can do about this? 2) Will this cause my email address to end up on blacklists and cause me significant problems? 3) Why in 2016 are Internet mechanisms not in place to prevent stuff like this?

50 comments

[ 2.9 ms ] story [ 104 ms ] thread
gupi
There are already mechanisms to prevent the spoofing of legit email addresses. See details below:

DKIM - https://support.google.com/a/answer/174124?hl=en

SPF - https://support.google.com/a/answer/33786?hl=en

Dmarc - https://support.google.com/a/answer/2466580?hl=en

However, implementing needs support from your email/hosting provider.

you_eeeeeediot
SPF would be a good start, most mail transport systems will check it. DKIM and then dmarc gets a little deeper down the rabbit hole but both still very worth it.
kspaans
That's funny, because gmail doesn't verify DKIM headers. At least not when I spoof gmail addresses! Maybe because my originating mailserver is whitelisted?
Volundr
That's odd, GMail is how I check to make sure I have DKIM setup correctly. Just send an email to my gmail account and check the message for "Authentication-Results: mx.google.com; dkim=pass" in the headers.

I'm also getting DMARC reports back from them for all my domains.

kspaans
Good point, I should have said that the headers correctly fail DKIM auth, but the gmail/inbox interface doesn't flag it as spam or do anything to tell you the email is spoofed! I can demonstrate if you want (email in my user profile).
verst
I used to work on Spam, Abuse and Deliverability for Google Apps and am one of the original authors of those help center articles (although they have been changed a bunch since).

Can you share the full message headers of one of these bounces you are receiving? Feel free to redact your email address. https://support.google.com/mail/answer/22454?hl=en

Edit: I left Google in 2013

js2
I switched my domain away from Google Apps to Fastmail because Google was hard bouncing emails that I sent to other Google Apps domains. I had both SPF and DKIM set up correctly. I could send emails to gmail.com addresses just fine, and to Google Apps addresses that weren't aliases (which Google implements via groups as I recall). But anything that went to a Google Apps destination address that was a group alias would bounce. I was on the grandfathered free tier so I coudldn't really complain, but it was the final straw the drove me to Fastmail. Now I can email those same addresses which used to bounce just fine.
verst
Google Apps does have email aliases (they are really just pointers to regular Google Apps Gmail accounts).

Google Groups uses a different sub system internally, and if you don't have SPF configured (or configured it wrong) it definitely rejects messages aggressively or queues them for moderation.

Virtually every problem where legitimate mail to any of your Google Apps email addresses (or groups) bounced could be addressed by adding DKIM and SPF. Some folks have strange dual delivery set ups, or perhaps use an outbound gateway server (for compliance filtering, journaling etc) - in those cases you definitely need to adjust the SPF records accordingly.

I never tried Fastmail before, maybe I'll check it out :)

js2
I'm fairly certain I had DKIM and SPF set up correctly. It was literally only when emailing another Google Apps+Google Group address that bounced. It looked like this:

    Delivery to the following recipient failed permanently:

    hi@smashrun.com

    Technical details of permanent failure:

    Message rejected by Google Groups. Please visit http://mail.google.com/support/bin/answer.py?hl=en&answer=188131 to review our Bulk Email Senders Guidelines.
Full headers:

    X-Received: by 10.55.15.30 with SMTP id z30mr25314313qkg.47.1440345211659;
           Sun, 23 Aug 2015 08:53:31 -0700 (PDT)
    Return-Path: <js2@example.org>
    Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com. [2607:f8b0:400d:c09::232])
           by mx.google.com with ESMTPS id 136si23593726qhc.102.2015.08.23.08.53.31
           for <hi@smashrun.com>
           (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
           Sun, 23 Aug 2015 08:53:31 -0700 (PDT)
    Received-SPF: pass (google.com: domain of js2@example.org designates 2607:f8b0:400d:c09::232 as permitted sender) client-ip=2607:f8b0:400d:c09::232;
    Authentication-Results: mx.google.com;
          spf=pass (google.com: domain of js2@example.org designates 2607:f8b0:400d:c09::232 as permitted sender) smtp.mailfrom=js2@example.org;
          dkim=pass header.i=@example.org
    Received: by qkda128 with SMTP id a128so5917057qkd.3
           for <hi@smashrun.com>; Sun, 23 Aug 2015 08:53:31 -0700 (PDT)
    DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
           d=example.org; s=google;
           h=from:content-type:content-transfer-encoding:mime-version:subject
            :message-id:date:to;
           bh=D6Jgw+8F97OpSz0ORbLuvcih9KdhWrTFusiNkbOms2w=;
           b=0X7YTsfGYQ31fR8zT8Vc4+7iYOtUmQT/kNx7SKdNyx9GxPPHo9kTqFxWhBHEKUbLiU
            zd0iFHh12IVn993lvSIkBLIBHnTaQSxgt7vpxCKhSGlvuJ1jbocHtCmYvF+FNwyiZAgE
            SNiTXBBmxCc7Z4g9GW0PGDz0hNbRp+PBJfabY=
    X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
           d=1e100.net; s=20130820;
           h=x-gm-message-state:from:content-type:content-transfer-encoding
            :mime-version:subject:message-id:date:to;
           bh=D6Jgw+8F97OpSz0ORbLuvcih9KdhWrTFusiNkbOms2w=;
           b=DfuecqdbbnVwcjQsa8Aon9ukQYC43RYb5V3uWnb3ayZzZagDyT7aVg8StcSjh9HsFZ
            +OPKwfULiQc9u3twxq5h/Q7urZQIlY/FVyBAXQbikK+c8rzfb9nB+2cSBZHPYrlgU0hd
            ZO/n0x7x6OsCOWePFVcO2sc9EEO6+YsoeapsnzAaWKgYxF2T8v34UPimKPKBtphJ7N3a
            W7anf2KbbGcsXSQiz+EfWgeNwhLMKSk5V8g0aXrCSMDXcPf20NW6NnKbcYms/rOIQRSM
            +J44wGA+rau6Wv+/0GA+XkGUOYpISMC2ATrEOO9/6XmmQSGmo3vb4oUSg9UmUCNGSVzY
            wKWg==
    X-Gm-Message-State: ALoCoQkfkZy/EZ2g8DXjWbFZEEaJou2F+r9Vhn5u4/H4A+bq9ZT/2IYeptS95RrShLFAzNDp9Bwd
    X-Received: by 10.55.21.140 with SMTP id 12mr3454160qkv.31.1440345211394;
           Sun, 23 Aug 2015 08:53:31 -0700 (PDT)
    Return-Path: <js2@example.org>
    Received: from [192.168.1.131] (cpe-XXX-XX-XXX-XXX.nc.res.rr.com. [XXX.XX.XXX.XXX])
           by smtp.gmail.com with ESMTPSA id x201sm9160834qkx.28.2015.08.23.08.53.30
           for <hi@smashrun.com>
           (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
           Sun, 23 Aug 2015 08:53:30 -0700 (PDT)
    From: js2 <js2@example.org>
This would fail 100% of the time when mailing any other Google Apps+Google Groups address, no matter the message content. I had failures from three separate Google Apps hosted domains over the course of a year. Once I moved my domain from Google Apps to Fastmail, this stopped happening.

Yes, I pay Fastmail and I wasn't paying for Google Apps. But I also get responsive support from Fastmail, IMAP push to iOS devices, more flexibility in delivery rules, etc.

verst
Google Groups has a feature to automatically reject messages it considers to be Spam. That feature has always been quite terrible. The Google Groups Backend hasn't changed in a very long time.

https://support.google.com/groups/answer/2627595?hl=en

I personally always disable it for public groups and then rely on Spam filtering of the recipient inbox.

By the way - the bounce message you are seeing is what is sent when the Spam Classification Server determined your message to be Spam. The main reasons for that are things like sending from a bad IP, having certain keywords that are strongly correlated with Spam, or having domains in your message that are associated with Spam (based on other messages having been marked as Spam containing those domains).

js2
Re: Spam Classification Server. The problem went away when I moved my domain away from Google Apps. Literally, the exact same test message that I could not send when I had my domain on Google Apps, I could send once my domain was on Fastmail. Nothing changed, but that my message was now routing via Fastmail's SMTP servers vs the Google Apps SMTP servers. Same message content, same client IP, same MUA, same destination (I had a friend with a Google Apps domain setup a test group for me to send to on his domain).
verst
So you are saying:

Google Apps SMTP -> Google Apps Group (different domain) == FAIL

Fastmail SMTP -> Google Apps Group (different domain) == SUCCESS?

It's been a long time since I looked at this. We did have great internal tools to look up the classification of individual messages, including the top 10 deciding reasons for a given message classification. With a paid Google Apps domain a support rep investigating your ticket would eventually look at this tool to figure out what's going on.

js2
Yup, that's what was happening. Agree about a paid account, but I decided Fastmail was a better fit for my needs.
js2
Yup, that's what was happening. Re: a paid account, I decided Fastmail was a better fit for my needs. Besides that, the problem was on the receiving end. So I somewhat disagree that I should have had to pay Google for someone to look into that.
buro9
I actually had the same problem and was dealing with it this weekend.

@dang helpfully pointed out an email to him had ended in the spam box, and a bit of investigation later revealed that some Vietnamese and Indian spammers had been sending email as me, to the tune of a few thousand emails per day.

I already had SPF in place, but I've since added DKIM and a strict reject policy via DMARC.

Additionally I added https://dmarcian-eu.com/ (or https://dmarcian.com/ if you're outside the EU), and this allows the DMARC reports to be sent directly there where they can be analysed and reported on.

My buro9.com records now look like:

  ;; TXT Records
  buro9.com.	300	IN	TXT	"v=spf1 include:_spf.google.com include:spf.mailjet.com -all"
  _dmarc.buro9.com.	300	IN	TXT	"v=DMARC1\; p=reject\; sp=reject\; adkim=s\; aspf=s\; rua=mailto:z3qirov9@ag.dmarcian-eu.com\; ruf=mailto:z3qirov9@fr.dmarcian-eu.com\; rf=afrf\; pct=100\; ri=86400"
  mailjet._domainkey.buro9.com.	300	IN	TXT	"k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzruNqjSTPtVVkkxRUG8H0EXToKtfuccUJNx8ElnhtgtWu30P3YIAd1nwFSfQEzwLn8BycK/S9I0/F+9p5fLpE6maxZxLadVq8cnWYROIWrjZnEJ549xQjX5/TB0uOiKYTVy8q17ZMEoJbpihm/vIKzqibl2cCPTHEDk12AV9kCwIDAQAB"
  buro9._domainkey.buro9.com.	300	IN	TXT	"v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0I0/RqPxshGephScWuBUE56L6ro4bS8FWuW3BWx93jLCpaOzY0iTAWGz58nvCSuG081ePqtnATyqcQdKxOaAYIyFyGm5fr6W4FVMAWyOP3OQ889vLFmpIPEaI/GpvBezwUdBvlxd+2xrKckXwUqhFRrG6bP4NyGDZxoSQF55DiQIDAQAB"
Note I've gone strict on SPF (against Google's recommendation), my DMARC is sending aggregate reports and forensics to Dmarcian, and I have DKIM keys for both Google (I'm on Google Apps) as well as Mailjet (I have a mailing list of 37k people and that needs to work too).

So far this appears to be having the desired effect, and I don't yet know of any deliverability issues from my email. Looks like this combination works well.

On domains I send no email from, i.e. buro9.co.uk:

  ;; TXT Records
  buro9.co.uk.	300	IN	TXT	"v=spf1 -all"
  _dmarc.buro9.co.uk.	300	IN	TXT	"v=DMARC1\; p=reject\; rua=mailto:z3qirov9@ag.dmarcian-eu.com\;"
An SPF that signals everything fails, and a reporting endpoint to find out if people are still trying to send spam as me.
jontanemobay
is this a yahoo/gmail or similar , or are you using your own domain. You won't get blacklisted if someone is spoofing your yahoo/gmail because their already are mechanisms to validate spoof'd vs legitimate messages. If you are using your own domain look into setting up SPF , DKIM and DMARC records .
hellofunk
It's my gmail account. According to a doc I just find on Gmail's site, they recommend reporting the bounced messages themselves as Spam, so I've done that.
danmarg
Is the mailer-daemon message from @googlemail.com or from recipient domains?
linkregister
Because GMail uses SPF, DKIM, and DMARC effectively, I'd say you shouldn't worry about it in general. And I can't really think of anything you could do short of using another email address or provider.

The major email service providers (GMail, Yahoo, Hotmail, iCloud, AOL, Comcast) should already be sticking these spoofed emails in their recipients' spam folders.

If you rely on communication with a less- or un-managed email server, then you might have issues, since they might not be filtering based off of SPF, DKIM signatures, or DMARC policy.

cweagans
IMO, this is a good reason to use a provider that will let you use your own domain. I recommend Fastmail. I've been using them for a while and have been very happy with them. The chances of some spammer spoofing you@somerandomdomain.com are much smaller than with username@gmail.com.
derekp7
True, unless you have a wildcard user for your domain. Whenever I give out my email, I typically add a unique identifier to the user name, so I can have something like "xyzHN@example.com". Then if I start getting spam, I know who leaked my email address.

The problem that happened then is someone was using random users@example.com causing the blowback spam to fill up my mail box. Until I added SPF, then hadn't had an issue since.

varjag
There is a standard syntax for subaddresses with '+' suffix, e.g. foo+oneoff@bar.com: the replies will end up at foo@bar.com. Wildcards in email domains are a bad idea and been so for many years.

https://en.wikipedia.org/wiki/Email_address#Sub-addressing

justinlardinois
The problem with using a standard convention for this sort of thing is that it's easy to detect and subvert (in this case, drop the + character and everything following it from the username).

If I sign up for, say, a Sears mailing list with the address sears@justinlardinois.com, it's not possible to divine what my "real" email address is.

What are the arguments for this being a bad idea?

vhost-
This is exactly what I do. I point everything in google apps to my primary account and then when an email from <service>@mydomain.com gets leaked, I just create an account for it in google apps and send everything to the trash.
derekp7
I like to track down where I used the given email from -- you'd be surprised who leaks your email. Was going through my spam folder, found a bunch of virus-laden phishing emails sent to an address I used one time on Equifax's site to get my credit report.
varjag
You can just use one subscription address for all unimportant services, thus using e.g. subscription+sears@justinlardinois.com.

> What are the arguments for this being a bad idea?

It enables spammers and makes you vulnerable to their backscatter, and there is no good way around it.

icebraining
You can just use one subscription address for all unimportant services, thus using e.g. subscription+sears@justinlardinois.com.

Yes, but if they drop the "+sears" part, you lose the tracking information.

What do you mean by wildcard emails enabling spammers?

Backscatter is not really a problem, I just filter non-whitelisted addresses to another folder which deletes them after a short while. Known problematic address get filtered to /dev/null. This is really easy to do with Sieve.

notahacker
Unless they've got a very specific purpose in mind (like spoofing an email address associated with a particular domain for phishing purposes), don't spammers just spoof a random real email address from the list of harvested email addresses they're sending the mailshot to?

I've definitely received generic spam emails purporting to originate from colleagues (whose email addresses would have been published in the same place) and I think I've even received one or two with my email as the spoofed originator...

samwillis
Do check that no one has hacked your email and is sending from it. You said that its a gmail account; spf will all be allready setup.

It's quite common to see people have their gmail accounts hacked and used for spam.

hellofunk
I assume if it was hacked, I'd see the sent mails in my sent folder or in trash, no? I have 2-factor setup on my account so I doubt it was hacked.
icebraining
Not necessarily, they could send them to Trash and then delete them from Trash itself.
bks
This is commonly known as a Joe Job - https://en.wikipedia.org/wiki/Joe_job

Steps to mitigate.

1. Setup SPF immediately. You can validate your records here- http://www.kitterman.com/spf/validate.html

You'll have to know who you send email through and their SPF record, but a quick googling of "provider name SPF" should get you what you need.

Depending on your DNS provider the results may be instant.

2. Filter those bounces keep them out of your inbox - it's going to take while until this clears up.

3. Make sure that YOU are not hacked, check the headers of the bounce back messages here - http://mxtoolbox.com/EmailHeaders.aspx

Ensure that your IP or hostname is not listed there. (This includes web servers that your domain is hosted on, apps that send on your behalf etc)

4. You can check to see if your domain is black listed - http://mxtoolbox.com/blacklists.aspx probably not...but worth a check.

TL;DR - I run one of the largest spam filtering companies in the world. Happens all day to clients...it's one of the reasons people switch to us.

linkregister
UPDATE: The OP is using GMail. This doesn't apply to her/him but it's still good advice so I'm keeping it up.

I think it's also worthwhile to mention DMARC: https://dmarc.org/overview/. Most of the major Email Service Providors (ESPs) support it.

SPF and DKIM signatures are two data points to help form an opinion about whether a message is legitimate. DMARC is your published policy about what to do with email that fails SPF and DKIM. If you have the strictest DMARC policy along with good SPF and DKIM records, and you're signing all your outgoing email correctly with DKIM, then this should solve your problem.

It's recommended to start with the most permissive DMARC settings (p=none) so you can make sure you don't prematurely block your own outgoing email.

I work for one of the larger (by market share) "send email via an API" services. This is a common issue we come across with our customers.

jsvaughan
+1 for DMARC - you can set your policy to ask the recipient to reject (or mark as spam) anything that fails the DMARC check. But yes, it is tricky to get right, so go for no action initially and monitor the reports.
Mafana0
Thanks for the informative post. I know you didn't make it to advertise, but do you mind sharing your product name/info? It might be interesting to people following the discussion who have a similar situation or concern.
bks
duocircle.com
exhilaration
Those tools are very nice, thanks for putting them together.
kogir
I had this problem. Back when I finally took action I was receiving 500+ bounce notifications a day.

If you fully and correctly implement SPF[1], DKIM[2], and DMARC[3], you'll see a massive improvement as much of the SPAM gets dropped completely at recipient MTAs.

To fully solve the problem, you need something to filter the backscatter[4] . At the time I purchased Postini, but now that Google has bought them, Google Apps for Work seems to have this feature built in. There may also be software you can run on your own server, or other proxy services like Postini. I've not looked since I use Google Apps for work. Such filters simply track all outgoing messages you send, and reject bounces from addresses and domains you never emailed.

This has complete solved my problem. Now I only get regular SPAM, a fact of life now.

In practice, all these things together look like this for kogir.com:

    @ IN TXT "v=spf1 redirect=_spf.google.com"
	_dmarc IN TXT "v=DMARC1; adkim=r; aspf=r; p=reject; pct=100; rf=afrf; ri=86400; rua=mailto:dmarc@kogir.com; ruf=mailto:dmarc@kogir.com; sp=reject;"
    mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCFlfDA1Gpz8BQVpcNsiDkSp6ayVCWKlfeYXhiW0CaCgJJJkBpZj9E9OGMGUSAFFgEhCs8wf/fZCx9jsWkH34joEuylNnBnGt8exPSokLwrtubTQajOZcUgbpUlxwyCkyuE41mbpYUfWkPCOaRTa1VqZVWYs+ZdEkYaKXh9UALYeQIDAQAB"
The sp=reject in the DMARC record is very important, but only works if all valid email from your domain will pass both the SPF and DKIM checks.

[1] http://www.openspf.org/

[2] http://www.dkim.org/

[3] https://dmarc.org/

[4] https://en.wikipedia.org/wiki/Backscatter_(email)

Sephr
> The sp=reject in the DMARC record is very important

sp=reject is already implied by your p=reject. You only ever need to specify sp= when it is different from your p=.

Additionally, adkim=r; aspf=r; pct=100; rf=afrf; and ri=86400; are all implicit defaults.

kogir
You're right, I just looked for reject and picked the first I saw.

As for the defaults, you have much more faith in other people's correct implementation of them than I do. Why not just be explicit?

nostrebored
do you think QA has done a better job testing the default implementation or flag permutations?
spdustin
Postmark has a free tool to set up and monitor DMARC, which is another policy setting that can be used (if you own your domain) so that major email providers know whether or not to trust an email claiming to be from you. Postmark's tool lets you get digests and nice visuals of these automated ISP reports rather than you figuring out how to parse the XML they'd normally send directly to you.

Disclosure: I'm not at all affiliated with Postmark, I use their free tier transactional emails, and I use their DMARC tool.

https://dmarc.postmarkapp.com

tacone
In addition to all the other excellent answers:

Change your password. Check your settings for unknown API tokens or any app you may have given to the permission to access your Google account.

OSButler
It's extremely annoying, but usually the attacker will switch to another domain after a few hours or days. The mail notifications can be delayed by a few days, depending on the individual mail server's settings, so you should see a slowdown of the incoming bounce messages after a while before it will stop eventually.
paste0x78
This actually just happened to me yesterday. The spammer actually added a SPF record for another host he apparently had control of.

Removing the bad SPF record and updating passwords fix it for me.

Still waiting on my web hosting provider to see if it was changed from my account with a valid login or if they were compromised in some way.

Animats
I had to deal with a joe-job problem once, but it was over a decade ago. I was getting over 20,000 email bounces an hour. I looked at the spam emails, and put considerable work into hassling the hosting providers that were hosting the spam targets. I had the advantage that I owned the domain name as a registered trademark, and could go after the hosting site as assisting in trademark infringement.

Once I discovered that the spammer was doing credit card fraud, and paying for their hosting with stolen credit cards, my conversations with hosting companies became even more effective, and the target sites were shut down within hours. Finally, the spammer retreated to an ISP in St. Petersburgh, Russia. It took a while, but it turned out that the CEO was an American expat, and we had some mutual friends. We had a nice chat. He told me the problem would be taken care of. The spam stopped shortly thereafter and never resumed.

It's much harder now, because spammers use botnets. On the other hand, after the CAN-SPAM act, "legitimate" spamming almost disappeared. Nobody spams from their own site any more, because spam filters will blacklist them. If they spam with phony origination, they're a crook, and can be prosecuted, so nobody legit spams with a phony source. The stuff that's left is all criminal, and because the number of spammer crooks really isn't that large, the spam gets picked up by classifiers that can see the commonality across destinations. (That's Gmail's edge.)

gargalatas
Everyone here told you that you have to use spf. But beaware that you need to put the directive -all and not the ~all. Just take care of this point as it's very important!

Second please check all of your systems that your email password is entered atleast once. Maybe a system has a spyware or virus or something.

Third change your email's password.

Except you are 100% sure that the spammer is not using your MTA then you just use an spf with the -all directive!

mod
Not very helpful, but a neat story:

When I was a kid on AOL in ~2000 I made some script-kiddie mad and he did this to me. One angry person replied to me, and I explained what was going on. He took some convincing, but eventually he believed me. He became my good friend--I've even met him in person. I'm really thankful it happened.