Technical Reference: What is E-mail Spoofing?

I wanted to explain from a semi-technical standpoint what email spoofing is, and why it is a challenge to stop.

E-mail spoofing” is someone other than the actual owner of an email address sending as them in the “FROM:” field of an email.

When SMTP (Simple Mail Transfer Protocol) was created… the challenge then was really just making it work.  Using computers to send messages over wide area networks was the only intent of its creation.  There was no such thing as “spam” or “junk e-mail”.  The original developers of the protocol weren’t thinking anyone might want to send as somebody else.  Therefore no Sender Verification was built into the standard.

Jump ahead a couple decades, and email is flowing in the billions of messages.  85% of the email going through our servers is rejected as spam, another 10% allowed in as probable spam… leaving only 5% of all email traffic as legitimate.  Because SMTP is so widely adopted, it would be very difficult to have everyone upgrade to a new standard.

Spammers don’t want email administrators to know the source of their mass junk email.  So one of the most common tools spammers use is spoofing.  These spammers typically aren’t targeting your email address specifically, it just happened to be one of the million email addresses included in their database of addresses to send TO:, and FROM:.

You will receive messages back from other mail servers rejecting messages back to you that you never sent.  The rejections are typically due to a recipient no longer existing, or a spam filter rejecting it back to your address.  Unless these messages are being received en masse, there is not much to do about them other than delete them.

There are a few things that we as an email hosting provider to do cut down on this problem:

1. Turn off SMTP "Relay"

Originally any email server would accept email FROM: any addresses.  The new standard practice is to only allow each mail server to send FROM: addresses hosted on itself.  When spammers find a server not properly locked down, it is quickly abused ("hijacked") to send thousands of messages.  If the administrator of the vulnerable server never checks for this problem, it will continue to be abused by several spammers and often passed amongst themselves as a prize.  Some servers have been properly configured, but a software vulnerability exists that has not been patched.

2. Implement SPF (Sender Policy Framework)

SPF is a relatively new protocol that attempts to publish which mail servers should legitimately be allowed to send as a sender by domain name (  When a receiving email server is delivered a new message, it looks up where email from should originate from.  If it is not coming from a published location, it is either rejected or scored higher as likely spam.

One problem with this protocol is that many receiving mail servers are not subscribing to the new SPF protocol.  However, as time goes on, more will.

Some web forms, such as “Send this article to a friend” may attempt to send AS your account that you type into the From: field on the form.  This used to be common practice, and many websites out there still have code that try to do this.  The must be updated to send as an account that the website owner controls.  You may find your QuickBooks program attempts to send FROM: your email address using Intuit mail servers, this also causes your emails not to go out.

3. Implement "Backscatter Protection"

Our mail servers use a new protocol called Backscatter Protection.  When someone other than you sends as your email address, and you receive the rejection emails, this is called backscatter.

The protection assigns a unique serial number to each email that you legitimately send out.  If a rejection notice comes back to your account that does not have a matching serial number… the rejection message is assumed bogus and deleted.  This cuts down on the number of messages that you see come back to you that you never sent.



This article viewed 20912 times as of 07/21/2019 --- First published on 06/14/2009 --- Last modified on 06/14/2009

<< Back to Articles
