This question already has an answer here:

I receive Mailer Daemon messages saying certain emails fail. My domain is itaccess.org which is administered by Google apps. Is there any way I can identify who is sending emails from my domain, and how they are doing it without me creating an account for them?

Delivered-To: 7e949ba@itaccess.org
Received: by with SMTP id z34csp12042wfd;
        Wed, 8 Aug 2012 07:12:46 -0700 (PDT)
Received: by with SMTP id in2mr18229790lab.6.1344435165782;
        Wed, 08 Aug 2012 07:12:45 -0700 (PDT)
Return-Path: <whao@www20.aname.net>
Received: from smtp-gw.fsdata.se (smtp-gw.fsdata.se. [])
        by mx.google.com with ESMTP id b9si24888989lbg.77.2012.;
Received-SPF: neutral (google.com: is neither permitted nor denied by best guess record for domain of whao@www20.aname.net) client-ip=;
Authentication-Results: mx.google.com; spf=neutral (google.com: is neither permitted nor denied by best guess record for domain of whao@www20.aname.net) smtp.mail=whao@www20.aname.net
Received: from www20.aname.net (www20.aname.net [])
    by smtp-gw.fsdata.se (8.14.3/8.13.8) with ESMTP id q78EChia020085
    for <7E949BA@itaccess.org>; Wed, 8 Aug 2012 16:12:43 +0200
Received: from www20.aname.net (localhost [])
    by www20.aname.net (8.14.3/8.14.3) with ESMTP id q78ECgQ1013882
    for <7E949BA@itaccess.org>; Wed, 8 Aug 2012 16:12:42 +0200
Received: (from whao@localhost)
    by www20.aname.net (8.14.3/8.12.0/Submit) id q78ECgKn013879;
    Wed, 8 Aug 2012 16:12:42 +0200
Date: Wed, 8 Aug 2012 16:12:42 +0200
Message-Id: <201208081412.q78ECgKn013879@www20.aname.net>
To: 7E949BA@itaccess.org
References: <20120808171231.CAC5128A79D815BC08430@USER-PC>
In-Reply-To: <20120808171231.CAC5128A79D815BC08430@USER-PC>
X-Loop: whao@whao.se
From: MAILER-DAEMON@whao.se
Subject: whao.se:  kontot avstängt - account closed
X-FS-SpamAssassinScore: 1.8

    Detta är ett automatiskt svar från F S Data - http://www.fsdata.se

    Kontot för domänen whao.se är tillsvidare avstängt.
    För mer information, kontakta info@fsdata.se

    /F S Data


  This is an automatic reply from F S Data - http://www.fsdata.se

  The domain account "whao.se" is closed.
  For further information, please contact info@fsdata.se

  Best regards,
  /F S Data

marked as duplicate by Chris S Dec 18 '13 at 19:27


  • 15
    Just in case you wish to further search the web for that problem, the common term for that kind of email misuse is called Joe Job. – Oliver Aug 8 '12 at 14:56
  • 15
    The problem is NOT that someone is claiming to be YOU (your domain), but rather, that someone (else) is believing them. If I send email to you claiming it is FROM Barack Obama, would you believe me? Of course not. You are getting "backscatter". Complain to those who have accepted the spoofed email ("joe job") and accepted that the from address was correct. But do this ONLY if your domain offers SPF records that show where (addresses, hosts) the only valid mail can come from. – Skaperen Aug 9 '12 at 1:36

Since it hasn't been explicitly stated yet, I'll state it.

No one's using your domain to send spam.

They're using spoofed sender data to generate an email that looks like it's from your domain. It's about as easy as putting a fake return address on a piece of postal mail, so no, there's really no way to stop it. SPF (as suggested) can make it easier for other mail servers to identify email that actually comes from your domain and email that doesn't, but just like you can't stop me from putting your postal address as the return address on all the death threats I mail, you can't stop someone from putting your domain as the reply-to address on their spam.

SMTP just wasn't designed to be secure, and it isn't.

  • 47
    +1 for the postal mail analogy. That's the one I always use with non-technical people. Nobody has to break into your house to send an outgoing piece of mail with your return address on it. They just need to be able to drop it into a mailbox. – Evan Anderson Aug 8 '12 at 20:42
  • 2
    You may want to explicitly link to answers instead of just saying "as suggested" – Thorbjørn Ravn Andersen Aug 8 '12 at 21:56
  • 18
    Really? You're the one sending all those death threats?!? :) – John Robertson Aug 9 '12 at 0:15
  • It's funny that everyone I work with, plus everyone here, always uses the veritable barakobama@whitehouse.gov example. – Captain Hypertext Mar 23 '16 at 23:23
  • To be more correct, you should say: No one's using your (domain's) server to send spam. Because they do use the domain, namely as the FROM-address. Of course SPF is no barrier at all, because the sender will use a hop-server which does not do SPF checks. Solution would be simple: The responsible Server for the TO-address should reject with 450 to the server the mail originates, not to send a DSN to the server which is responsible for the FROM-address – roothahn Jul 13 '16 at 13:43

It is the nature of SMTP (the protocol used to transfer mail) that no validation is done on the sender address listed in an email. If you want to send an email that appears to come from president@whitehouse.gov...you can go ahead and do that, and in many cases there's nothing anyone can do to stop you.

Having said that, if you establish SPF records for your domain, there's a better chance that receiving systems will recognize the forged email as spam. An SPF records identifies systems that are allowed to originate mail for your domain. Not all receiving systems pay attention to SPF records, but larger email providers will use this information.

  • 19
    Specifically for Google Apps you can follow these steps. – MichaelHouse Aug 8 '12 at 21:51
  • 1
    I have this problem at the moment, too, and my SPF records are correct. Unfortunately, a lot of big mail providers ignore SPF records. Including such luminaries as Yahoo. :-( – staticsan Aug 9 '12 at 1:58
  • 7
    Don't forget about DomainKeys. DKIM. – desbest Aug 9 '12 at 13:22

I endorse the answers already given regarding SPF (+1, each of you!) but please note that if you decide to go this way - and it's a good way - there is no point in doing it unless you identify and advertise all hosts that are approved to send email for your domain, and hard-disallow all others with -all.

Not only will ?all and ~all not have the desired effect, but some mail admins on SF regard them as a sign of a positively-spammy sender domain.

  • 9
    Google's guidance on creating an SPF entry for domains using Google Apps to send mail: "Publishing an SPF record that uses -all instead of ~all may result in delivery problems." – Ariel Aug 8 '12 at 21:32
  • 10
    Yes, it may, that's the whole point of it. As long as you've exhaustively listed those hosts who may legitimately send your mail, you want all other hosts to have delivery problems; the problems will only affect you if you've failed to list all your valid sending hosts, and that's what google's referring to. See Chris S's comment on serverfault.com/questions/374452/… for one example of an admin who takes against useless (lacking a -all) SPF records. – MadHatter Aug 9 '12 at 5:50
  • But if you use -all, anyone who uses mail forwarding will not receive the mail. I believe people still use mail forwarding (whether they should use it is another question) – netvope Sep 24 '12 at 13:56
  • 1
    You're absolutely right, but that's what SRS (Sender Rewriting System) is for. I'd argue that it should be understood that SPF and simple (non-SRS) forwarding are mutually-exclusive and that admins should pick just one, not that you can still use SPF alongside simple forwarding if you just change -all to eg ~all. That's essentially not using SPF at all. – MadHatter Sep 24 '12 at 14:12
  • 1
    Mail admins may be using -all, but every shared host includes email these days. An outright fail is considered a misconfiguration that shouldn't be taken seriously while a softfail is. That's why after analyzing tons of spam and SPF usage, SpamAssassins default SPF_SOFTFAIL score is higher than the default SPF_FAIL. What exactly is the problem with DMARC? If your mailing lists are affected by a DMARC policy then your mail blasts aren't properly configured. It provides more control over your SPF and gives feedback reports. You tell all Yahoo users they aren't going to receive your bulk mail? – J.Money Apr 4 '16 at 23:16

Sender Policy Framework (SPF) can help. It is an email validation system designed to prevent email spam by verifying sender IP addresses. SPF allows administrators to specify which hosts are allowed to send mail from a given domain by creating a specific SPF record (or TXT record) in the Domain Name System (DNS). Mail exchangers use the DNS to check that mail from a given domain is being sent by a host sanctioned by that domain's administrators.


It doesn't look like a SPF would have helped in this particular example. A machine that was bothering to check SPF records to reject mail is unlikely to be so broken as to accept mail for a nonexistent domain, then decide it can't deliver it and generate the bounce message. If mail-gw01.fsdata.se, the machine accepting mail for whao.se, had bounced it properly, your bounce message would be coming from a Google SMTP server.

Sadly, this kind of broken behavior (accepting and later generating a bounce) is not that uncommon. There is not a thing you can do to keep some random machine from pretending it has a message to deliver from your domain. There is also not a thing you can do about delayed bounces.

You can, however, have less of these blowback bounces to read. If 7E949BA is not a real user on itaccess.org, as I suspect it may not be, you're getting the bounce message because you have your catch-all address enabled. A catch-all means that your domain will accept email for any non-existent user and deliver it to you. This is primarily a good way to grow your collection of spam and bounce messages. In Google Apps, to configure your catch-all, it's under "Manage this domain" -> Settings -> Email, about halfway down.


An idea not yet mentioned is to reject the backscatter. All of it that I've seen comes through open mail relays, and there are two blackhole lists which you may find useful for reducing the amount of backscatter you receive.

  • Backscatterer is a DNSBL which explicitly lists SMTP servers that send backscatter and sender callouts.

  • RFC-Ignorant is a DNSBL which lists SMTP servers that do not obey various important RFCs.

Adding these in (along with several other more traditionally focused BLs) reduced the amount of backscatter that I receive by over 90%.


What you are referring to is actually called a BACKSCATTER attack. Now what it is actually is already explained well above.

How to solve it ?

Backscatter can be prevented with self hosted solutions like Postfix, qmail and exim etc, but not with googleapps, as it's popular for not having protection present for dealing with backscatter, Except only SPF records.


As the other answers have mentioned, you're receiving bounces from someone else's emails. SpamCop has previously not called this spam, but these days it accepts reports for this. E.g. I copied the message you quoted (and I've included my Gmail account to determine my mailhosts) and got this result (which I cancelled).

In summary, you can use SpamCop to report the senders of these bounces. It doesn't (directly) stop the initiators of the problem, but it may reduce these bounces.


The mail system relies on From: headers, which are really easy to spoof.

For instance, this PHP code:

mail('someone@live.com', 'Your new Outlook alias is ready to go', 'Ha ha! This is spoofed!', "From: Outlook Team<member_services@live.com>\r\n");

will send an email to someone@live.com pretending to be the Outlook Team.

  • 3
    No, it relies on the SMTP "envelope" sender (and recipients, too) (the ones sent in the MAIL FROM command), which can be completely different than the From: header. – derobert Aug 13 '12 at 18:58
  • @derobert Okay, I didn't know that. Thanks! – uınbɐɥs Aug 13 '12 at 20:35
  • 5
    Please go ahead and edit your post to correct it… that's one of the many encouraged reasons to use the edit link. – derobert Aug 14 '12 at 14:42
