The goal of email spoofing is to trick the user into thinking an email is from a known and trusted source. Spoofing is done through the manipulation of email elements that are visible to the recipient, primarily the "Body From" field.
A spoofed email can be partial or full:
However, there are certain technical circumstances where the use of either SPF or DMARC is not possible. This may be due to the number of valid sources extending beyond the capacity of SPF, a technical constraint, or your own DMARC infrastructure. This leaves you exposed to spoofing.
|Bad Partial Spoof (unknown or malicious source):||Bad Full Spoof (unknown or malicious source):|
In both spoof examples, the IP addresses are unknown sources, which are not allowed to spoof you). The Body From is masked to look like your domain; the Envelope Sender may or may not be masked to match your domain.
|Good Partial Spoof (valid or approved source):||Good Full Spoof (valid or approved source):|
Spoofed email does not necessarily mean that the email you receive is spam or bad; it can be legitimate and important to you. Today's businesses rely heavily on legitimate spoofing for their business to function. Common email marketing services like MailChimp, Amazon SES, and Zoho Campaigns are typical mail service providers for sending newsletters.
|Bad Ghost Spoof (unknown or malicious source):||Good Ghost Spoof (valid or approved source):|
From: “firstname.lastname@example.org” <email@example.com>
From: “firstname.lastname@example.org” <email@example.com>
A third type of spoof—which we refer to as a ghost spoof— is not technically spoofing, but it does exploit an element of the Body From. This element is the Display Name field.
A ghost spoof deals with an open text field that is not controlled in any way. Your email client will only show the display when one exists, especially if the display name matches the internal naming scheme. Your users would see the text inside the " ", but not the Body From email. This varies between email clients.
Regular expressions are used in this policy. In Symantec.cloud, the Data Protection regular expression engine supports Java 7 based expressions.
Important: When writing regular expressions, test the expressions to ensure that they works as you intend. Use the following pages to test your regular expressions:
Symantec recommends that you check the Oracle Summary of Regex Constructs for instructions on syntax. Ensure that you check the case insensitive option.
|Any character except newline
The character a
a or b
One character of: a, b, or the range x-z
One or more a's
Between (inclusive) 4 and 8 a's
A word character (same as [_a-zA-Z0-9])
|Escapes a special character
The string ab
0 or more a's
Zero or one a's
Exactly 4 a's
9 or more a's
A digit (same as [0-9])
Content Regular Expression List
- Body From Checker
Content Regular Expression List
- Capture Header Information
Content Regular Expression List
- Valid Spoof IP sources
- Valid Spoof Msg-ID sources
Upon resume, the policy triggers if the incoming email contains one of the Body From domains being monitored, and the source IP and source Message-ID are not known. The policy then acts on the email, saving in the process information of the Body From, HELO/EHLO, IP, and/or Message-ID used. The final report also contains the Env-sender address, as well as the subject of the email.
Note: If you are concerned with top-level domain spoofing as well, you can ignore the com in the example as follows:
This also fla emails where your domain is used as a sub-domain of other domains; you may have business partners with this configuration.
IMPORTANT: The Exceptions sources rule serves to list the IPs or Message-IDs of valid senders that can spoof your domain, like business partners, etc. This information is provided in the reports that are run every few days.
From the report, you can review the listed entries and decide how to approve a given valid source. Then you can pick the option that delivers that same result while requiring less effort to do.
If you have a source that has dozens of IPs, but follows patterns with the Message-ID, it is probably easier to approve the Message-ID format. On the other hand you may have a source with few IPs, but quite a different format of Message-IDs every time. Therefore, it is easier to approve the IPs or IP range in this case.
The first valid sources added here are your own outbound routes. It is common for local applications to send email externally before it reaches an internal user. For example, a java mail server. The IPs are added with the following format: \
See Using IPs with Data Protection for more information.
>is where you add the pattern for the domain:
^(Message-ID:(?:.*?)@pattern\.domain\.com>)$, this example covers the follow 2 message id's: "
Message-ID: <randomBit@pattern2.domain.com>" or "
Message-ID: <anotherRandomBit@pattern3.domain.com>", where the section  represents the possibility of the value being a 2 or a 3.
Note: Avoid using your own domain as a valid source as a Message-ID exception; instead, use IPs to approve your own sources. Message-ID sources are useful to approve externals sources when it is easier than approving the IPs. Other conditions are possible as exceptions. For example, HELO commands, and other header elements that may be used to uniquely identity a source. However, be aware that HELO's can be easily forged.
Scenario: If you use Office 365, you can use the following expression to validate Office 365 servers when it is the source of the email:
Before you create the report, ensure that you are using the accountassigned to the "View Sensitive statistics" role or permission. Secondly, ensure that the following Data Protection options are activated.
Note: If you have a partner or you are a partner who creates policies or reports for your clients, your account cannot create this report.
This example shows how a report looks in Microsoft Excel (with non-relevant columns hidden).
|1||Time Period||…||…||…||Email Subject||Email To||Email From||…||Matched Content||…|
|2||16/08/2016 22:48||…||…||…||Subject Linefirstname.lastname@example.orgemail@example.com||…||188.8.131.52, HELO server1.sender.com, From: "Some Name"
|3||16/08/2016 21:31||…||…||…||Some Subjectfirstname.lastname@example.orgemail@example.com||…||184.108.40.206, HELO srv23-exh2.domain.com, From: firstname.lastname@example.org, Message-Id: <201608162122.u7GLMYOw076625@srv23-exh2.domain.com>||…|
With everything in place, begin analysing the report every couple of days, work out the valid spoof sources, and approve them in the Exceptions condition.
This process may take several weeks depending on the email flow and number of individual, valid sources. Symantec recommends that you change the action of the Anti-spoof Domain Control policy only after you can accept the reduced risk of false positives. This risk should be minimal after several weeks of approvals.
After Log Only, the next action suggested is Redirect to Administrator, where emails get sent to the specified admin email used in this policy. You should create this admin email specifically for this purpose, with the goal of keeping emails in the event a false positive occurs. This enables you to retrieve the email if necessary.
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
This will clear the history and restart the chat.