As a best practice, Symantec recommends that all customers add "include: spf.messagelabs.com" to the existing SPF record of the protected domain even if the outbound delivery route from the protected domain does not use Email Security.cloud.

Adding the Email Security.cloud servers to the SPF record to the protected domain can prevent various mail routing issues, such as those that arise when one customer of Email Security.cloud sends an email message to another customer of Email Security.cloud and the sender has specified "Hard Fail", i.e., "-all" for action under their SPF Record.

For example, if you send an outbound emails to another customer domain which has SPF Check turned on, the following occurs:

• Your sending server connects to the cluster
• Since the sending domain is registered with us, the cluster accepts it as outbound email
• The email is subjected to outbound spam scanning
• It the emails is clean, it is handed over to Delivery Servers for final delivery
• The delivery server looks at the recipient domain and hands it over to the tower for the recipient domain
• The tower then checks the SPF Record of the sending domain
• Now the IP it sees is the last IP that made the connection, which is on of messagelabs' Delivery Server
• If you do not have our SPF Record included and have a hard fail on SPF Record, the email will be rejected
• This is because our delivery server is not authorized to send on your behalf as it is not included in your SPF Record

The above example gives you an idea why it is critical to have SPF Record of Symanctec.Cloud Email Servers included if you have chosen to use a hard fail as the action for your SPF Record.

Another popular reason for implementing and enforcing SPF is to drop mail messages that have a spoofed sender.  This reduces the amount of Backscatter. Backscatter is actually one or more NDRs your users may receive for emails they may never have sent out.  What happens is that a spammer uses one of your emails addresses as the Env Sender address for their spam attack on other systems.  When one or more of the email addresses are not valid on the recipient side, they issue an NDR which ends up sent to your user.  In this case, if the recipient side had SPF Check on and your domain had an SPF record issue with hard fail, all those emails would have been rejected and you would not receive any NDR.



To enforce SPF for a domain protected by Email Security.cloud

1. In the Client portal, enable enforcement of Sender Policy Framework (SPF)
2. In the DNS server which is your Start Of Authority (SOA) server, add Symantec's servers in an SPF record
3. Test to confirm that email with a spoofed envelope sender claiming to be from your protected domain included the "Received-SPF:" header.
4. Monitor for mail flow problems for one week
5. If no mail flow issues occur, change from SoftFail to Fail

To enable enforcement of SPF within the Client portal

1. Login to https://clients.messagelabs.com with the primary username for your organization's account
2. Navigate to Services > AntiSpam
3. If you seek to enable SPF for all domains under your account, skip to step 7
4. Under Anti-Spam, click Global Settings.
5. From the list that appears, click the domain you seek to change
6. Click Use Custom Settings.
7. Under Spoofed Sender Detection, click the checkbox beside Use SPF.

To add the Email Security.cloud mail servers to an existing SPF record

1. Within the DNS server that functions as the Start Of Authority for your protected domain, edit the existing Type 16 DNS Record Resource (RR).
2. Add the following before the "~all" or "-all":
   include:spf.messagelabs.com
   
   NOTE: This entry cannot be "include:messagelabs.com", as most SPF implementations will not iterate through include entries across SPF records for multiple domains. The needed records are in the SOA for spf.messagelabs.com.
    
3. Perform a TXT lookup to confirm that only one SPF record is found and that the record includes "include:spf.messagelabs.com"

About other Anti-Spam features available within the Client portal for Email Security.cloud
Enforcing Sender Policy Framework is only one of many possible ways to reduce spam or other undesired messages to your protected domain. For an overview of the other features available on the Services > Anti-Spam page within the Client portal, see the following help page:

https://techdocs.broadcom.com/us/en/symantec-security-software/email-security/email-security-cloud/1-0/about-anti-spam-detection-settings-and-actions-toc216426968-d2923e687.html



Where to find more information on SPF

• Title: ietf.org: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
  URL: https://tools.ietf.org/html/rfc7208
  Comment: Documentation for the PROPOSED STANDARD for SPF implementation available at the web site of the Internet Engineering Taskforce (IETF)
   
• Title: Email Anti-Spam and Email Quarantine Guides (PDF format)
  URL: https://techdocs.broadcom.com/content/dam/broadcom/techdocs/us/en/dita/symantec-security-software/email-security/email-security-cloud/content/EmailAntiSpamAdminAndEmailQuarantineDeployment.pdf