Spam delivered by mx.google.com despite SPF fail

Question

Some spammer use our e-mail address as sender in forged e-mails. Now we got thousands of bounced messages from no longes existing e-mails.

We set up SPF and DKIM records but it does not stop.

procrastination.com TXT v=DMARC1;p=reject;sp=reject;pct=100;aspf=r;fo=0;ri=86400;rua=mailto:info@procrastination.com    IN  3600

procrastination.com TXT v=spf1 ip4:77.240.191.234 ip4:83.167.254.20 ip4:83.167.254.21 ip4:83.167.254.22 ip4:81.95.97.117 ip4:81.95.97.100 a -all

Form mail headers it looks like spammer use Google SMTP mx.google.com at his e-mail are delivered dispite SPF result for them is fail.

Example headers follows:

    Delivery to the following recipient failed permanently:

     r.fiores@webmail.flcgil.it

Technical details of permanent failure: 
Google tried to deliver your message, but it was rejected by the server for the recipient domain webmail.flcgil.it by webmail.flcgil.it. [109.168.127.232].

The error that the other server returned was:
550 5.1.1 <r.fiores@webmail.flcgil.it>: Recipient address rejected: User unknown in virtual mailbox table


----- Original message -----

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-original-authentication-results:x-gm-message-state:message-id
         :reply-to:from:subject:date:mime-version:content-type
         :content-transfer-encoding:delivered-to;
        bh=DWSqotpOUM1r96KR6EV4WUBt9g/4xHl2j4TzsRWmYtM=;
        b=Z/uEm+/nMjD5ynw2bKuAtnqTFvpJ6QbUnJbXtPyYU1xONdOI+630z8WGZPfCkEjrR8
         +iIrp9EH7y+3xOpEL2N5JoKtkMpcbgUuyC8N6dH5Mx1aZZXAylg1mXc6uMne2NhQAZVW
         XGVmikat0wxCsgSYt+T8nHXULU/OY5LlAbGiKD0EQ96nvRB0fyquVyHFvQfKLi7gORlD
         939MMe1QiEw/4aH4oEigEOgMoAZe+1SxoiyJfj/M80iHtsh97bhHCukB4Yni9aX9LJEc
         edS2ZS9c5IBnTmTmLbQwlZXx65u9Z3FIUSU82GQSWOF6Upp2ZzHwt7Az3hbfn+Or5Sy/
         lGvg==
X-Original-Authentication-Results: mx.google.com;       spf=fail (google.com: domain of info@procrastination.com does not designate 66.84.38.179 as permitted sender) smtp.mail=info@procrastination.com
X-Received: by 10.42.50.81 with SMTP id z17mr14637142icf.57.1430488267890;
        Fri, 01 May 2015 06:51:07 -0700 (PDT)
X-Gm-Message-State: ALoCoQkCSb7aXwRPbIiUnV3a6JAZsPok55aOGUIsgkMbXM4B9QOW7RY14KvVmumEXab7Rh5k2YlELm1N9oWNNCvASrmS2cavQKBK4Kp7sNFkm6YKqjisbzTMuq6cso3vvh4X/KsH8bgCx7+Yg5E7IVbLsSgjr+rRlicTI1tXLVq88gyQdAE/3bE=
X-Received: by 10.42.50.81 with SMTP id z17mr14637132icf.57.1430488267815;
        Fri, 01 May 2015 06:51:07 -0700 (PDT)
Return-Path: <info@procrastination.com>
Received: from procrastination.net (s179.n38.n84.n66.static.myhostcenter.com. [66.84.38.179])
        by mx.google.com with ESMTPS id z2si3656962icq.16.2015.05.01.06.51.07
        for <r.fiores@flcgil.it>
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Fri, 01 May 2015 06:51:07 -0700 (PDT)
Received-SPF: fail (google.com: domain of info@procrastination.com does not designate 66.84.38.179 as permitted sender) client-ip=66.84.38.179;
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of info@procrastination.com does not designate 66.84.38.179 as permitted sender) smtp.mail=info@procrastination.com
Received: from User ([154.118.4.5])
    (authenticated bits=0)
    by procrastination.net (8.13.1/8.13.1) with ESMTP id t41DosSm007397;
    Fri, 1 May 2015 09:50:59 -0400
Message-Id: <201505011350.t41DosSm007397@procrastination.net>
X-Orig: [154.118.4.5]
X-Authentication-Warning: procrastination.net: procrast owned process doing -bs
Reply-To: <wwwxxx5@konin.lm.pl>
From: "INTERNATIONAL MONETARY FUND"<info@procrastination.com>
Subject: Attn: Your Long Over due payment claim/change of account?
Date: Fri, 1 May 2015 14:51:05 +0100
MIME-Version: 1.0
Content-Type: text/plain;
    charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Antivirus: avast! (VPS 150501-0, 05/01/2015), Outbound message
X-Antivirus-Status: Clean
Delivered-To: r.fiores@flcgil.it

Any idea how we cam make this stop? Why SPF did not help?

If I understand your question correctly, this problem is called [backscatter](http://en.wikipedia.org/wiki/Backscatter_%28email%29). [Possible duplicate ?](http://serverfault.com/questions/61583/how-i-stop-spam-backscatter-rendering-email-on-my-domain-unusable) — , May 02 '15 at 14:29
Well basically yes. But my question is why adding of SPF and DMARC records did not help? Is there anything I do wrong? Or is there anything else I can do? — Martin Mystik Jonáš, May 02 '15 at 14:36
This is not backscatter. It's just spammers abusing Gmail/Google Apps. — Michael Hampton, May 02 '15 at 22:18

score 5 · Accepted Answer · answered May 02 '15 at 14:56

5

You cannot compel others to filter their incoming mail based on SPF and DKIM, or indeed any other criteria at all. If google chooses to ignore SPF, so be it; you've done your bit, all you can do now is sit tight and ignore any complaints from people who don't filter on SPF.

That said, having a valid SPF record does tend to reduce backscatter, because a rational spammer will prefer to forge emails from a domain that doesn't have a valid SPF record ending in -all, as yours does. You may find that after this current wave of backscatter has passed, things do indeed improve.

answered May 02 '15 at 14:56

MadHatter

78,442
20
178
229

Ok. So, you think I did all I can to stop this? – Martin Mystik Jonáš May 02 '15 at 15:01
What you did won't help with the current wave of backscatter, but it should help with future ones. You can go further, and reconfigure your mail servers to use custom envelope-froms on each outgoing email, which can then be used as validators on mails that claim to be bounces/returns, but that can be quite painful to setup (depending on MTA). – MadHatter May 02 '15 at 15:07
Regarding the question of why Google tried to deliver the message in the first place despite an SPF fail: SPF allows the receiving mail server to block noncompliant incoming mail, and is not meant to stop services like gmail handling it in transit, so we still get backscatter from domains that aren't set up to check SPF even though mx.google.com spotted it. (That's my understanding anyway, though I'm not any sort of expert or server admin.) – William Robertson May 03 '16 at 16:05

BillThor · Answer 2 · 2015-05-03T14:56:00.320

Your DMARC record should be under _dmarc.procrastination.com. This is a new specification and not widely supported. If you want reports you also need a TXT record containing v=DMARC1 at *._report._dmarc.procrastination.com or procrastination.com._report_dmarc.procrastination.com. You will know this is working when you start getting reports. Both Google and Yahoo are likely to send you reports.

SPF does tend to be effective in reducing the amount of spoofed email (spam) using your domain. However, many sites do not use SPF to block email as many sites have incorrectly configured records. I found I need to whitelist certain domains to ensure I do not bounce legitimate mail.

You may want to implement BATV (Bounce Address Tag Verification) on outgoing email so that you can reject backscatter spam notifications. However, you should allow a week or two after setting up BATV before you block incoming bounce messages.

Implementing DKIM (Domain Keys Identified Mail) and adding that to your DMARC policy may help reducing delivery of spoofed messages.

There are some news sites which allow emailing notifications to friends that incorrectly use the email address of the person as both the envelope and from addresses. These may be blocked by a strict interpretation of SPF.

Spam delivered by mx.google.com despite SPF fail

2 Answers2