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:

• Partial Spoof: A partial spoof occurs when only the "Body From" is masked, with the Envelope Sender being set to something else. This spoof type can be managed with Domain-based Message Authentication, Reporting & Conformance (DMARC), which is an email authentication, policy, and reporting protocol.
• Full Spoof: A full spoof occurs when both the "Body From" and Envelope Sender are spoofed. This spoof type can be managed with Sender Policy Framework (SPF). SPF is an email-validation system designed to detect email spoofing by providing a mechanism to allow mail exchangers to check that incoming mail comes from an authorized host.

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.

Table: Unknown, untrusted spoof examples

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.

Table: Known, trusted spoof examples

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.

Table: Ghost spoof examples

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.

Before you start

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:

• Regex Planet
• Debuggex.com or Regex101. Neither supports Java POSIX classes like \p{Punct}

Symantec recommends that you check the Oracle Summary of Regex Constructs for instructions on syntax. Ensure that you check the case insensitive option.

Policy logic

Policy summary

Rule 1:
Control BodyFrom
 Condition 1:
  Content Regular Expression List
   - Body From Checker

AND

Rule 2:
 Feedback Conditions
  Condition 1:
   Content Regular Expression List
    - Capture Header Information

AND

Rule 3:
 Exceptions
  Condition 1:
   Content Regular Expression List
    - Valid Spoof IP sources
    (AND)
    - Valid Spoof Msg-ID sources 

• Rule 1 is true if the condition is satisfied
  • Condition 1 is true if it finds a match to one (1) domain from the listed domain entries in Body From Checker.
• Rule 2 is true if the condition is satisfied
  • Condition 1 is true if it finds a HELO, IP, Reply-to, and/or Message-ID. One or more may be absent, which can occur with Message-ID, for example.
• Rule 3 is true if the condition is satisfied
  • Condition 1 is true if none of the entries in the selected lists are found. This only triggers when the source is unknown or not listed, effectively being a non-approved source.

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.

Policy implementation

1. Log in to the Symantec.cloud Management Console.
2. Navigate to Services > Data Protection.
3. Create a new Data Protection policy, and define the following options:
   • Name: Anti-spoof Domain Control
   • Apply to: Inbound email only
   • Execute if: ALL rules are met
   • Action: Log Only
   • Administrator email: Enter a non-production administrator email address; do not use a personal email address. Data Protection policy administrators are automatically whitelisted from all Data Protection policies to avoid mail loops.
   • Notification: None
     
     
      
4. Add a new rule. Click Add Rule, and define the following options:
   • Name: Control BodyFrom
   • Execute if: ALL conditions are met
     
     
      
   1. Add a new condition. Under Content - Regular Expression Lists, click Create a new Regular Expression List.
   2. Define the condition as follows:
      • Name: Body From Checker
      • Add your domains to the list with format: ^(from:.*?@yourdomain\.com.*)

        Note: If you are concerned with top-level domain spoofing as well, you can ignore the com in the example as follows: ^(from:.*?@yourdomain\..*)

        This also fla emails where your domain is used as a sub-domain of other domains; you may have business partners with this configuration.

      • Email contains: a number of matches for the regexes in the selected lists
      • At least: 1
      • Count only unique matches: No
      • Case sensitive: No
      • Look in: Header
      • Matched text: Log matched text
        
         
         
5. Add a new rule. Click Add Rule, and define the following options:
   • Name: Feedback Conditions
   • Execute if: ALL conditions are met
     
     
      
   1. Add a new condition. Under Content - Regular Expression Lists, click Create a new Regular Expression List.
   2. Define the condition as follows:
      
      Note: These lists may already exist among your regular expressions lists, if you've followed the steps in Prevent name-based email spoofing. In this case, use the search option to find the lists, and set the condition options as shown.
       
      • Name: Capture Header Information
      • Add the following entries to the list.
        

        (?:1)?\(((?:HE|EH)LO(?!=)\n?(?:.*?))\)[\s]{1,2}?\((?:\d{1,3}\.){3}\d{1,3}\).*?\n?.+?messagelabs\.com
        (?:2)?\(((?:\d{1,3}\.){3}\d{1,3})\).*?\n?.+?messagelabs\.com
        (?:3)?^(Reply-to:(?:.*?\n){1,2}?)(?=^[\w-]+?:)
        (?:4)?^(Message-ID:(?:.*?\n){1,3}?)(?=^[\w-]+?:)

        
        Note: This expression set will register the HELO, IP, Message-ID and Reply-to. Not all values need to be present; any values that are found are automatically registered.
         
      • Email contains: a number of matches for the regular expressions in the selected lists
      • At least: 1
      • Count only unique matches: No
      • Case sensitive: No
      • Look in: Header
      • Matched text: Log Matched text
         
        
         
6. Add a new rule. Click Add Rule, and define the following options:
   • Name: Exceptions
   • Execute if: All conditions are met
     
     

     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.

   1. Add a new condition. Under Content - Regular Expression Lists, click Create a new Regular Expression List.
   2. Define the condition as follows:
      • Name: Spoof Valid IP sources VIP

        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: \b123\.123\.123\.123\b
        
        See Using IPs with Data Protection for more information.

   3. Add a new condition. Under Content - Regular Expression Lists, click Create a new Regular Expression List.
   4. Define the condition as follows:
      • Name: Spoof Valid Message-ID sources
        
        This list serves to approve sources based on the Message-ID. Here is a sample and first temporary entry:
        
        ^(Message-ID:(?:.*?)@dummy\.domain\.symantec\.cloud>)$
        
        The following segments of the entry are static. The area between @ and > is where you add the pattern for the domain:
        
        ^(Message-ID:(?:.*?)@
>)$
        
        Example: ^(Message-ID:(?:.*?)@pattern[23]\.domain\.com>)$ , this example covers the follow 2 message id's: "Message-ID: <[email protected]>" or "Message-ID: <[email protected]>", where the section [23] represents the possibility of the value being a 2 or a 3.

        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:
        
        ^(Message-ID:(?:.*?)@[a-z0-9]{3,6}pr[0-9]{2,4}mb[0-9]{3,4}\.[a-z]{3}prd[0-9]{2,4}\.prod\.outlook\.com>)$

        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.
         
      • Email contains: a match for none of the regexes in the selected lists
      • Case sensitive: No
      • Look in: Header
      • Matched text: Log Matched text
         
        
         
7. Review your choices and save the policy.

Reports

Report requirements

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.

1. Log in to the Symantec.cloud Management Console.
2. Navigate to Services > Data Protection > Settings.
3. Check the following options:
   • Show matched content on reports.
   • Show surrounding text on reports. (Optional, depends on your needs)
4. Click Save.

Create an anti-spoof control policy report

1. Log in to the Symantec.cloud Management Console.
2. Navigate to Reports > Report Requests.
3. Start a new report. Enter a name such as Anti-spoof Control Report.
   
   
4. In the left pane, select the data to include:
   1. Check Email Detailed Report (CSV).
   2. Check Data Protection.
   3. Click advanced settings.
5. In the floating pane (right in the image below), under Policy Name, ensure that the policy name matches the exact name of the policy. For example, earlier we defined the policy name as "Anti-spoof Domain Control".
   
   
    
6. Set the reporting period:
   
   
    
   • Time zone: GMT (select your time zone)
   • Report period: last 3 day(s) (this is good value to start with)
   • Check Schedule.
   • Set Run the report request as follows:
     • Daily at 8:00 AM (choose a time that suits you)
     • every: 3 Days
     • Until: forever
7. Set the delivery preferences:
   • Report available: as an email attachment
   • Recipient(s): you can add up to 5 recipients
     
     
     
     Note: Leave other options as is.
      
8. Review your choices and save the policy.

Report example

This example shows how a report looks in Microsoft Excel (with non-relevant columns hidden).

Final steps

With everything in place, begin analyzing 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.