Documentation
System StatusPortal Login

Email spoofing best practices

Suggest Edits

This article explains email spoofing and describes the steps that you can take
to combat it.

Prerequisites

  • Applies to: Administrator and User
  • Difficulty: Moderate
  • Time needed: 15 minutes
  • Tools required: Email access

For more information on prerequisite terminology, see
Cloud Office support terminology.

If you prefer a video tutorial, see
Rackspace Email - Spoofing: How to identify & protect your organization.

What is email spoofing?

The word spoof means falsified. A spoofed email is one in which the
sender purposely alters parts of the email to make the message appear as though
someone else authored it. Commonly, the sender’s name, email address,
and the body of the message appear from a legitimate source. Sometimes, the
spoofer makes the email appear to come from a private citizen.

A spoofed message can appear to come from a coworker, a bank, a family member,
or any number of seemingly trustworthy sources. A good spoof looks like any
other email that you normally receive.

Warning: If you suspect that you have received a fraudulent message, DO
NOT click any link in the message or enter any requested information.

Why do people spoof email?

Often, the spoofed email is part of a phishing (scam) attack. In
other cases, someone uses a spoofed email to dishonestly market an online service or
sell you a bogus product. The intent is to trick the recipient into making a
damaging statement or releasing sensitive information, such as passwords. If
you receive bounced (returned) emails for messages that you never sent,
this could be a case of spoofing.

Identify a spoofed message

Scammers alter different sections of an email to disguise who is the actual
sender of the message. To view the following properties, you must open the
email headers of a suspected spoofed message. Following are
some examples of spoofed properties:

  • FROM [email protected]: This appears to come from a legitimate
    source on a spoofed message.
  • REPLY-TO: This can also be spoofed, but a lazy scammer might leave the
    actual REPLY-TO address. If you see a different sending address here,
    it might be a spoofed email.
  • RETURN-PATH: This can also be spoofed, but a lazy scammer might leave the
    actual RETURN-PATH address. If you see a different sending address here,
    it might be a spoofed email.
  • SOURCE IP address or “X-ORIGIN” address: This is typically more difficult
    to alter, but it is possible.

A spoofer can alter the first three properties by using settings in Microsoft
Outlook, Gmail, Hotmail, or other email software. They can also alter the fourth
property, IP address, but that requires more sophisticated user knowledge to
make a false IP address convincing.

In the following example, it appears that the recipient has received a message
from their office assistant requesting money.

The subject line should alert you immediately. This user should contact
their assistant through another form of communication to confirm that they did
not send this message. Next, you want to discover who actually sent the message
by opening the message headers. It should look similar to the following:

In this message header snippet, we see that the From: field shows the
message as coming from "Assistant"<[email protected]>.
However, we can also see that the REPLY-TO: field lists [email protected].
That is a clear example of a spoofed message.

You should Blocklist any address you find in the REPLY-TO,
RETURN-PATH, and SOURCE IP field that is not an email address or IP
address from which you normally receive mail.

For more information on viewing and understanding email headers, see
View and read Rackspace email headers.

Combat spoofing

User education is the first line of defense against these types of attacks. If
you receive a spoofed message, you should perform the following tasks:

Spoofing is possibly the most frustrating abuse issue to deal with because you
can't stop it. Spoofing is similar to hand-writing many letters and signing
someone else's name to it. You can imagine how difficult that would be to trace.

The most impactful change you can make as an administrator is to implement
SPF, DKIM, and DMARC records in that order. These are DNS records
that add extra layers of protection to prevent malicious email from being sent
out using your domain name.

  • Sender Policy Framework (SPF) records help recipient mail servers identify
    unauthorized use of your domain in the form of forgeries (spoofing). Create
    an SPF record policy     first.

    Note: If you send email from other providers on behalf of your domain,
    be sure to include their sending servers in the same SPF record entry. Do
    not create multiple SPF records.

  • DomainKeys Identified Mail (DKIM) records assign a digital signature to
    mail sent from your domain, marking it as authorized mail sent from your
    domain. If you require instructions to enable DKIM for your Rackspace Cloud
    Office email, see Enable DKIM in the Cloud Office Control
    Panel    .
    Creating a DKIM record is the second step in the process.

  • Domain Message Authentication Reporting and Compliance (DMARC) records
    indicate to recipient mail servers that messages sent from that domain
    employ DKIM and SPF sending policies. The recipient mail server then
    validates the message that you sent by using your DKIM and SPF policies.
    Creating a DMARC record policy
    enables you to enforce DKIM and SPF records. This is the last step in the
    process.

Using record policies protects the integrity of internal emails, as well as the
external reputation of your domain. Implementing this protection is a multi-step
process that you must carefully follow. For more information, see
Create a DMARC policy.

References

Updated about 1 year ago