How to stop people from using my domain to send spam? [duplicate]

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.

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 [email protected]...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.

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.

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.

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.

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%.

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('[email protected]', 'Your new Outlook alias is ready to go', 'Ha ha! This is spoofed!', "From: Outlook Team<[email protected]>\r\n");

will send an email to [email protected] pretending to be the Outlook Team.