This document describes different scenarios with Sender Policy Framework (SPF) on the Cisco Email Security Appliance (ESA).
Cisco recommends that you know these topics:
Sender Policy Framework (SPF) is a simple email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is being sent from a host authorized by that domain's administrators. The list of authorized sending hosts for a domain is published in the Domain Name System (DNS) records for that domain in the form of a specially formatted TXT record. Email spam and phishing often use forged sender addresses, so publishing and checking SPF records can be considered anti-spam techniques.
From the CPU prospect, there will not be a huge performance impact. However, enabling SPF verification will increase the number of DNS queries and DNS traffic. For every message, the ESA might have to initiate 1-3 SPF DNS queries and this will result in expiring DNS cache earlier than before. Therefore, the ESA will generate more queries for the other processes as well.
In addition to the previous information, the SPF record will be a TXT record that may be larger than the normal DNS records and could cause some extra DNS traffic.
These instructions are from Advance User Guide on setting up SPF verification:
To enable SPF/System Independent Data Format (SIDF) on the default mail flow policy:
To take action on SPF verification results, please add content filter(s):
If you choose a conformance level of SPF, configure whether to perform a test against the HELO identity. You might use this option to improve performance by disabling the HELO check. This can be useful because the spf-passed filter rule checks the PRA or the MAIL FROM Identities first. The appliance only performs the HELO check for the SPF conformance level.
To pass the SPF HELO check, ensure that you include an SPF record for each sending MTA (separate from the domain). If you do not include this record, the HELO check will likely result in a None verdict for the HELO identity. If you notice that SPF senders to your domain return a high number of None verdicts, these senders may not have included an SPF record for each sending MTA.
The message will be delivered if there are no Message/Content Filters configured. Again, you can take certain actions using Message/content filters for every SPF/SIDF verdict.
To enable the SPF for a certain domain, you might need to define a new sender group with a mail flow policy that has SPF enabled; then create filters as mentioned previously.
The Cisco Anti-Spam considers quite a lot of factors while calculating spam scores. Having a verifiable SPF record may reduce the spam score but there is still a chance of getting those messages caught as suspected spam.
The best possible solution would be to Allowlist the sender IP address OR create a message filter to skip spam check with multiple conditions (remote-ip, mail-from, X-skipspamcheck header, etc.). The header can be added by the sending server to identify one type of messages from others.