↵To prevent messages with spoofed senders from reaching a domain protected by Email Security.cloud, do one or more of the following. For information on the possible ramifications of each procedure, see "About ramifications for each spoofed sender technique", below.
For specific steps related to using SPF with Email Security.cloud:
For specific steps related to using DMARC with Email Security.cloud:
To add an IP address as an Approved Sender in the Client portal:
Note: Do not put your domain name in your own approved senders list. By including your own domain name, you open the organization up to a security exploit. This may occur because spammers sometimes spoof the sending email address to match the target email domain (you) in an attempt to bypass Anti-Spam scanning. Instead, include yours and you partners' sending IP addresses.
Keeping in mind that adding a sender's IP to the approved sender’s list will bypass the Anti-Spam Service completely. This includes bypassing SPF and DMARC checks for the sender domain.
To block a domain as a sender in the Client portal:
Pro: Rejects mail during the initial SMTP conversation at the Email Security.cloud server in response to SMTP RCPT TO: command.
Pro: Saves costs of downstream processing.
Con: Does nothing to prevent backscatter (NDRs from another domain which accepted a message with a spoofed sender containing your domain name). To attempt to prevent backscatter, see User receiving bounce notification for email they did not send (Backscatter).
Con: Does nothing to prevent messages with spoofed senders for domains which do not belong to your organization.
Pro: An SPF record can prevent incoming spoofed senders in the SMTP MAIL FROM: command.
Pro: An SPF record can be checked by every mail server configured to use SPF, not just Email Security.cloud. Therefore, it can prevent backscatter.
Pro: Saves costs of downstream processing.
Con: SPF does not check whether the address issued during the SMTP MAIL FROM: command matches the address in the From: line of the message headers.
Pro: Adds a "Recipient-SPF: SoftFail" header to a mail message, permitting downstream mail servers to perform additional filtering actions. These downstream actions may include prepending "[SPOOFED SENDER]" to the Subject: header of the message, silently dropping the message, or re-directing the message to a mailbox monitored by your organization's local IT Security team.
Pro: When Email Security.cloud does not reject a given message due to SPF, the message is still checked by other AntiVirus and AntiSpam measures.
Con: Does not drop the message during the SMTP RCPT TO: command of the initial connection to Email Security.cloud. This message is accepted and therefore contributes to the maintenance costs of the protected domain's message archiving and bandwidth, including CPU cycles for any further processing downstream.
DMARC also rejects: