3

A spammer seems to be running spam through SES and spoofing our domain.

We are using SPF and DKIM so I’m not sure what is going on.

This is our SPF record:

v=spf1 a mx include:amazonses.com include:_spf.google.com include:secureserver.net ~all

I had one of the recipients of the spam send me their header file. I've attached the results from Google's Email Header Analysis Tool for both the spam email and a legit email from our domain.

Here's the analysis of the spam email headers:

Here's the analysis of the legit email headers:

As can be seen in the reports, the SPF and DKIM results show as “neutral” for the spam email and “pass” for the legit email. The spam one also gets routed through a third party server that looks suspect.

Does anyone have any ideas what might be going on and how to stop it?

  • Your SPF record is permissive: the ~all part allows anybody to send e-mail on your behalf (with status neutral). Can you add also your _domainkey and _dmarc records? – Piotr P. Karwasz Jan 7 at 11:58
  • 1
    The Message-Id looks fake (genuine SES are all hex and dashes), and it should not be possible for a spammer to actually be sending email from your domain with SES, since SES only allows a given AWS account to send mail from a domain after validating that account's control of the domain. It is not likely to have been "routed through" the 3rd party server. It more likely originated there with forged headers to make it appear to have come from SES... but to a trained eye, the actual headers would likely tell a better story than this mechanized analysis does. – Michael - sqlbot Jan 8 at 1:32
  • 2
    @Piotr. The Softfail switch (~) should not result in a Neutral evaluation, but rather a FAIL. The Neutral switch is the ? sign. If a restrictive DMARC policy was in place these emails surely would have been rejected. – Reinto Jan 8 at 14:35
0

The actual headers might tell you more than the analysis from Googles Header Analysis tool. The Authentication-Results header will tell you about the precise checks performed on which domains.

As Michael commented it could very well be a forged message-ID and set of headers. Amazon SES does make you verify your email address or domain before you can send out emails.

However, seeing that the SPAM was possibly sent through a service you use and to a client of yours, it could be that the your API keys or credentials got leaked and your SES account is being abused. In your case it seems that the messages are being forwarded by the suspicious serer, after replacing the Return-Path header (on which SPF is checked) and stripping the DKIM signature(s).

You should be able to see the Return-Path value and connecting IP address (to Google's sevrers) in the raw headers. That should give you a clue about what's going on. Also, you might want to log a support ticket at Amazon to check the specific Message-ID.

To prevent this situation from happening, you may want to consider setting up DMARC. This will actually protect the domain used in the FROM header from being spoofed.

| improve this answer | |

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.