Prevent spoofed messages with spoofed senders detection

Products

• Email Security.cloud

Issue/Introduction

 How to protection your users from receiving spoofed messages.

Resolution

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.

• Within the Client portal, add the IP addresses of outbound servers for the protected domain or the IP of the partner(s) authorized to spoof the protected domain to the Approved Senders list, then block the protected domains.
• Use Sender Policy Framework (SPF) to block spoofed senders in the SMTP MAIL FROM: command.
• Use SPF to SoftFail spoofed senders in the SMTP MAIL FROM: command, then filter based on "Recipient-SPF: SoftFail" header.
• Use DMARC policy to reject messages with spoofed senders.
• Use DMARC policy to quarantine messages with spoofed senders.

 
For specific steps related to using SPF with Email Security.cloud:

• See Implement SPF records in Email Security.cloud

For specific steps related to using DMARC with Email Security.cloud:

• See Enabling spoofed sender detection with DMARC
• See How SPF and DMARC interact during Anti-Spam scanning

To add an IP address as an Approved Sender in the Client portal:

1. Select Services > Email Services > Anti-Spam.
2. Ensure that Global Settings is selected in the domains drop-down list.
3. On the Approved Senders tab, click the Add Entry option.
4. In the Domain/Email/IP field enter the IP address for the approved mail server.
5. In the Description field, enter brief details.
6. To add the entry to the list, click Update.
7. Repeat steps 3-7 for each additional IP address.
   
   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:

1. Select Services > Email Services > Anti-Spam.
2. Ensure that Global Settings is selected in the domains drop-down list.
3. On the Blocked Senders tab, click the Add Entry option.
4. In the Domain/Email/IP field enter the domain/Email/IP.
5. In the Description field, enter brief details.
6. To add the entry to the list, click Update.
7. Repeat steps 3-6 for each additional domain.

About ramifications for each spoofed sender technique

• Within the Client portal, add the IP addresses of outbound servers for the protected domain to the Approved Senders list, then blacklist the protected domains.

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.

• Use Sender Policy Framework (SPF) to block spoofed senders in the SMTP MAIL FROM: command.

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.

• Use SPF to SoftFail spoofed senders in the SMTP MAIL FROM: command, then filter based on "Recipient-SPF: SoftFail" header.

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.

• Use DMARC to reject messages with spoofed senders.
  Check that the envelope sender is valid and matches the sender on the From: line. For any domain in the SMTP MAIL FROM: command, DMARC filters mail messages where a single FROM: header exists in the SMTP DATA, but does not match the SMTP MAIL FROM: which passed SPF and DKIM.

DMARC also rejects:

• • • Messages with multiple RFC5322.From fields
    • Messages with a single RFC5322.From field containing multiple senders
    • Messages without an RFC5322.From field
    • For messages that fail DMARC checks where the domain has a 'reject' policy. Our mail servers will reply to the SMTP DATA verb with "553-DMARC domain authentication fail..."