Phishing/Spoofing Made Easy

Before we jump on to the topic of phishing attacks, let us understand the two important aspects that govern the success or failure of these types of attacks.

1. Sender Policy Framework (SPF) records

2. Deployment of SPF check

What is an SPF Record?

SPF is basically a open-standard framework that is designed to prevent the spoofing of sender addresses. This is one reason why it is often used by organizations to protect the their domains from forgery or spoofing.

An SPF record is a TXT record, which is used by the recipient mail servers to validate the credibility of the sender’s domain. However, using an SPF record does not protect the sender’s identity nor does it imply that the e-mail was sent by a valid user.

To view SPF records, at command prompt (for the Windows® operating systems), type the following command.

nslookup -q=txt domain.tld

A SPF record is made up of Mechanisms and Qualifiers.

Mechanisms are evaluated in the order in which they occur. They can be prefixed with one of four qualifiers: +, -, ~, and ? These qualifiers and their descriptions have been given in the following table.

Qualifier Result Explanation MTA action
+ Pass The SPF record designates the host to be allowed to send accept
Fail The SPF record has designated the host as NOT being allowed to send Reject
~ SoftFail The SPF record has designated the host as NOT being allowed to send but is in transition accept but mark
? Neutral The SPF record specifies explicitly that nothing can be said about validity accept

If a mechanism results in a hit, its qualifier value is used. The default qualifier is “+“, i.e. “Pass”.

For example:

"v=spf1 -all"

"v=spf1 a -all"

"v=spf1 a mx -all"

"v=spf1 +a +mx -all"

Sometimes, the recipient server may encounter an error while retrieving the SPF record or the SPF record may not be present. Evaluation of an SPF record can return any of these results.

Result Explanation MTA action
None The domain does not have an SPF record or the SPF record does not evaluate to a result accept
PermError A permanent error has occured (eg. Badly formatted SPF record) unspecified
TempError A transient error has occurred accept or reject

If no matching mechanism or modifier is found, the default result returned is “Neutral”. On the other hand, if a domain has no SPF record, the result returned is “None”.

If a domain has a temporary error during DNS processing, you get the result “TempError”. If some kind of syntax or evaluation error occurs (eg. the domain specifies an unrecognized mechanism) the result is “PermError”.

In this paper we shall discuss only the “all” mechanism.

The “all” mechanism


This mechanism always returns a valid result. It usually added at the end of the SPF record.


Record Explanation
"v=spf1 mx -all" Allow the domain’s MXes to send e-mails for the domain.  prohibit all other IP addresses. This type of record is used for very strict checks.
"v=spf1 -all" The domain sends no e-mails at all.
"v=spf1 +all" The domain owner thinks that SPF is useless and/or doesn’t care or just for the sake of sufficing the requirements of a SPF record.
"v=spf1 ?all" The domain owner is not sure which IP address will be used to send e-mails for this particular domain.
"v=spf1 . . . . ~all" The domain owner is not sure which IP address will be used to send e-mails for this particular domain. He also wants to ensure that all other IPs should be marked in the message body and at the same time ensuring that no e-mail gets bounced back.

Warning! +all, ?all and ~all should be used very carefully because these WILL ASSIST an attacker/ spammer in launching a Phishing/Spam attack on the behalf of your domain.

Mail Transfer Agents (MTAs) and Mail AS/AV’s may perform the following tasks.

1.      Performing additional verification of SPF records

2.      Marking the e-mails or allocating “Spam” percentages to these type of e-mails based on the qualifiers prepended to the “all” mechanism

3.      Notifying the senders and the recipients of the anomaly

4.      Adding the word “suspicious” in the subject line

The thumb rule should be: Let the user know.

System admins should re-evaluate their SPF records and their e-mail flow from all the computers and make better use of SPF.

An Example Scenario

One of the leading multinational bank has the following SPF record.

v=spf1 ip4:a.b.c.67 ip4:a.b.d.50 ip4:a.b.e.88 ~all


A typical Phishing attack against the customers of this bank would be something similar to this.

The Phish artist generates an e-mail asking for the login credentials and sends it to the customers of the bank. The recipient MTA, tags the message as SOFTFAIL because the SPF record has “~all”, but DELIVERS the message to the user’s mailbox.

The customer is aware that his e-mail service provider has enabled SPF Verification and also knows that his trusted bank has an SPF record. But, there’s a slim chance that the customer would open up the message headers and look into them.

This is what most computer users do on receiving an e-mail: open the e-mail, read it, and if they feel it is suspicious, then they try to be careful. If the users are either unaware or not careful, the phish attack is 100% successful because there is nothing within the displayed contents to warn the user that this mail has failed the SPF check. The phish artist has achieved the one important goal in this attack and that is—“The Trust” of the user.

A sample message header looks like this:

And the displayed message is:

Here’s another example.

v=spf1 mx/24 –all

This is another example of an SPF record deployed by one of the leading IT consulting/facility management organization.

This record means that the subnet hoisting the MX  is allowed to send mails and rest all other IPs should be rejected. System Admins should be careful if they do not own the entire subnet, otherwise, any IP that is a part of this subnet will be able to spoof e-mails of this domain.

But this organization has failed to provide the proper SPF record to their client. They have provided the following record to their client:

v=spf1 ip4:202.a.b.c ip4:124.d.e.f ip4:124.d.e.g +all

Example of the thumb rule : Let the user know

Gmail’s initiative of letting the user know about the integrity of sender mail id is based on DomainKeys (DKIM). The Key icon next to the user ids is a visual proof that e-mail sender’s domain has been validated.

*This information has been gathered during research and affected organizations were notified.

This entry was posted in MailScan and tagged , , , . Bookmark the permalink.

4 Responses to Phishing/Spoofing Made Easy

  1. I think you hit the nail on the head

    Like or Dislike: Thumb up 0 Thumb down 0

  2. If you are open to having a guest blog poster please reply and let me know. I will provide you with unique content for your blog, thanks.

    Like or Dislike: Thumb up 0 Thumb down 0

  3. Really nice post,thank you, best website ever

    Like or Dislike: Thumb up 0 Thumb down 0

  4. Pingback: 2010 – Year of Social Engineering Attacks | Welcome to the eScan Blog

Comments are closed.