SPF and DKIM

Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) are validation methods that check incoming email messages from specific domains are authorized by the owner of that domain. This helps protect recipients from receiving spoofed email messages. ESET Mail Security also uses Domain-based Message Authentication, Reporting and Conformance (DMARC) evaluation to enhance SPF and DKIM.

SPF

An SPF check verifies that an email was sent by a legitimate sender. A DNS lookup for SPF records of the sender's domain is performed to get a list of IP addresses. If any of the IP addresses from SPF records matches the actual IP address of the sender, the result of the SPF check is a Pass. If the sender's IP address does not match, the result is a Fail. However, not all domains have SPF records specified in DNS. If there are no SPF records present in DNS, the result is Not available. A DNS request may timeout occasionally, in which case the result is also Not available.

DKIM

DKIM is used by organizations to prevent email message spoofing by adding a digital signature to the headers of outgoing messages according to the DKIM standard. This involves using a private domain key to encrypt your domain's outgoing mail headers and adding a public version of the key to the domain's DNS records. ESET Mail Security can then retrieve the public key to decrypt an incoming header and verify the message comes from your domain and the header has not been changed along the way.

Exchange Server 2010 and earlier are not fully compatible with DKIM because headers included in digitally signed incoming messages may get modified during DKIM validation.

DMARC

DMARC is built on top of the existing SPF and DKIM mechanisms. You can use Mail Transport protection rules to evaluate DMARC result and Apply DMARC policy actions.

ARC

The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step. ARC addresses the challenge of intermediary mail servers breaking traditional authentication methods like SPF or DKIM by modifying the email message.

ARC allows internet mail handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled internet mail handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.

ARC-enabled internet mail handlers can process sets of ARC assertions to inform message disposition decisions, identify internet mail handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries.

See ARC use cases for more information about the ARC and message handling use cases that it addresses.

Accept ARC signature

ARC feature is enabled by default. ESET Mail Security Antispam protection evaluates ARC headers as part of defined rules for SPF, DKIM, DMARC and only in the following cases:

•SPF result is FAIL, SOFTFAIL

•DKIM result is FAIL

•DMARC result is FAIL

Trusted ARC sealer

Only ARC signatures from trusted sealers are accepted. The list of default trusted sealers is as follows: google.com, gmail.com, googlegroups.com, messagingengine.com, fastmail.com, fastmail.fm, outlook.com, hotmail.com, office365.com, microsoft.com, yahoo.com, ymail.com, icloud.com, me.com, amazon.com, and aws.amazon.com.

Auto-detect DNS servers

Auto-detect uses your network adapter settings.

DNS server IP address

If you want to use specific DNS servers for SPF and DKIM, type the IP address (in IPv4 or IPv6 format) of the DNS server you want to use.

DNS query timeout (seconds)

Specify a timeout for DNS reply.

Automatically reject messages if SPF check fails

If your SPF check immediately fails, an email message can be rejected before it is downloaded.

The SPF check is done on the SMTP layer. However, it can be rejected either automatically on the SMTP layer or during rules evaluation.

Rejected messages cannot be logged into the Events log when you use automatic rejection on the SMTP layer. This is because logging is done by rule action and the automatic reject is done directly on the SMTP layer, which happens before rule evaluation. Because the messages will be rejected before rules are evaluated, there is no information to be logged at the time of rule evaluation.

You can log rejected messages only if you reject the messages by a rule action. To reject messages that did not pass SPF check and log such rejected messages, disable Automatically reject messages if SPF check fails and create the following rule for Mail transport protection:

Condition

•Type: SPF result

•Operation: is

•Parameter: Fail

Actions

•Type: Reject message

•Type: Log to events

Use Helo domain in SPF evaluation

This feature uses the HELO domain for SPF evaluation. If the HELO domain is not specified, the computer hostname is used instead.

Use From: header if MAIL FROM is empty

The header MAIL FROM can be empty, and can also be easily spoofed. When this option is enabled and MAIL FROM is empty, the message is downloaded and the header From: is used instead.

Automatically bypass Greylisting if SPF check passes

There is no reason to use Greylisting for a message if its SPF check result was Pass.

SMTP reject response

You can specify a Response code, Status code and Response message, which define the SMTP temporary denial response sent to the SMTP server if a message is refused. You can type a response message in the following format:

Response code	Status code	Response message
550	5.7.1	SPF check failed

˄˅