SPF / DKIM / DMARC

Recommended Deployment

September 2015
Version 1.0

Hrvoje Dogan
Security Solutions
Architect

The most current version of this document can be found here:

https://cisco.com/go/emailsecurity-customer
 ESA BEST PRACTICES

PURPOSE OF THIS DOCUMENT

Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based
Message Authentication, Reporting and Conformance (DMARC) are three technologies
most commonly used to stop and detect fraudulent or phishing email. All three are part of
the basic functionality (Incoming Mail Handling) on the ESA. This Document will show
how to configure them and propose a simple way to deploy for a small to medium
enterprise.

EMAIL AUTHENTICATION IN THE PIPELINE

Email authentication on the ESA is implemented as a two-step process. Since SPF and
DKIM do not provide the facility for the sending domain to specify the message handling
policy, the first step of SPF and DKIM verification occurs in the Incoming phase of
message processing, right after Recipient Validation. In this step, SPF conformance of
HELO and MAIL FROM identities is verified, and DKIM signature is processed.
Results of the processing are stored in Received-SPF and Authentication-Results
headers respectively. Later on, receiving systems can act on authentication verdicts using
Content Filters or Message Filters.

DMARC, on the other hand, provides a facility for the sending domain to specify desired
message policy. Thus, right after DMARC verification, the desired policy will be applied
and no further action is necessary on the receiving end.

Since SPF is only DNS-based, and DMARC uses a combination of DKIM, SPF and DNS,
the only relevant technology for outgoing mail is DKIM. DKIM signing is done at the very
end of delivery stage in the pipeline, right before applying the Bounce Profile and
delivering the message.

CONFIGURING EMAIL AUTHENTICATION VERIFICATION

This is the easier part of implementing email authentication. While SPF is simple and
straightforward, DKIM and DMARC require profile creation. This chapter will provide an
overview of deployment for Incoming Mail processing.

2
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

Step 1: DKIM Verification Profile configuration

Before enabling DKIM verification, you should check the default profile settings and adapt to your
security requirements. To access it, go to Mail Policies -> Domain Keys / Verification Profiles.

In general, the default settings should be acceptable for most environments. You might
want to reject messages for Temporary Failure (e.g. DNS inaccessible for public key
retrieval), or Permanent Failure. However, at this stage we recommend these messages to
be accepted, and later tagged or quarantined using a filter.

Step 2: DMARC Verification Options and Profile configuration

Unlike DKIM, DMARC settings should be modified for better visibility of reporting
component. To access DMARC Verification settings, go to Mail Policies -> DMARC

3
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

In the Global Settings section, you should modify (click on Edit Global Settings) Entity
Generating Reports and Additional Contact Information for Reports. These should
contain your domain name, and contact information in case that sender domain will need to
contact you. By default, ESA will generate an aggregate failure report for DMARC daily at
midnight. Sending Forensic Reports is currently not supported.

You should also edit the default DMARC Verification Profile. As all other components of
the ESA, the default values are set up in a way to never block any traffic, to avoid any
inadvertent messaging interruptions. However, to properly implement DMARC, messages
must be blocked or quarantined as per sender domains instructions. Thus, you should
modify the following in the default DMARC Verification Profile:

- Reject Policy Message Action: Change to Reject

- Quarantine Policy Message Action: Change to Quarantine To, and select a policy
quarantine to use. You may want to quarantine messages that fail DMARC in a
separate quarantine to do this, create a new quarantine either on the ESA or on the
SMA first
- Other settings should be left at default values at this point

4
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

Step 3: Email Authentication Verification Configuration in the Mail Flow Policies

Now that our profiles are ready, we can configure verification for all incoming mail. This is
controlled by the Mail Flow Policies, and the best way to achieve it is to change the Default
Policy Settings. Go to Mail Policies -> Host Access Table (HAT) / Mail Flow Policies, and
click on Default Policy Parameters in the bottom.

Scroll down to Security Features section of the default Mail Flow Policy, and select
DKIM Verification, SPF/SIDF Verification and DMARC Verification to On. If you
have created a verification profile other than DEFAULT, make sure to reference that
profile. Additionally, check the Send aggregate feedback reports box in the DMARC
configuration. After you submit and commit your changes, the ESA will start verifying
incoming messages. Take note that if you are using multiple listeners to receive incoming
email, you will have to do this for every listener. Also, double-check any Mail Flow
Policies with Accept behavior if they are bypassing the default values for email
authentication settings.

You now need to click on the Mail Flow Policies that have the Behavior set to Relay
and turn Off DKIM Verification, SPF Verification, and DMARC Verification. The Relay
5
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

Behavior is for Outgoing Mail Flow and we do not want to enable DKIM/SPF/DMARC
Verification for Outgoing mail.

Step 4: Filter configuration for SPF and DKIM handling

As previously mentioned, because there are no explicit instructions on how to handle

messages that fail SPF and DKIM, this has to be specifically configured using Content
Filters or Message Filters. This document will provide instructions for Content Filter
deployment, however Message Filters should be configured analogous to Content Filters.

There are multiple ways in which a message can pass or fail DKIM or SPF verification. For
DKIM those are:

- Pass (message passed signature verification)

- Neutral (message not signed)
- Temperror (recoverable error e.g. cant reach DNS to retrieve public key)
- Permerror (unrecoverable error e.g. the signature references a non-existing key)
- Hardfail (verification failed)
- None (authentication not performed e.g. DKIM Verification was off in the Mail
Flow Policy)

SPF verification introduces an additional result, softfail. This is due to the fact that when
specifying the SPF record, domain owners can choose to either hardfail or softfail
certain messages. In general, these would translate to reject and quarantine policy
specifications in DMARC, and that is what we will configure in the filters in this section.

Filter 1: Drop SPF-Failing Messages

Create an Incoming Content Filter with the SPF Verification condition set to fail. You
can either reject failing messages by setting the action to Drop, or quarantine them.
Similar to DMARC verification profile, you may create a specific Policy quarantine to
keep SPF-failing messages

6
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

Filter 2: Quarantine SPF-Softfailing Messages

To handle SPF soft fails, we will create a filter similar to Filter 1 above. In the condition
check the Softfail option, and for action choose Quarantine as already mentioned,
configuring a separate quarantine for SPF may come in handy.

7
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

If you choose to quarantine both Hard and Soft SPF fails, you can combine them in a single
filter, by checking both Fail and SoftFail check boxes.

Filter 3: Tag other non-compliant SPF messages

In general, any messages failing SPF check for any other reason should be accepted and
tagged in the Subject:

8
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

9
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

Filter 4: Quarantine DKIM-Failing Messages

Create a filter using DKIM Authentication rule set to Hardfail, and the action to
Drop.

10
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

As with SPF, you can replace the Drop action with Quarantine to a specific quarantine.

Filter 5: Modification of Filter 3 to include messages unable to pass DKIM verification

Since handling of SPF and DKIM messages which fail verification due to errors should be
done in the same way, we can just modify Filter 3 above to include two DKIM verification
results. Add two additional conditions using DKIM Authentication condition and options
Temperror and Permerror.

If you chose to reject messages that produced temporary or permanent failure in the DKIM
Verification Profile, you do not need to include them in the filter.

11
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

REPORTING ON MESSAGE AUTHENTICATION

Reporting on DMARC verification is straightforward Messages rejected by DMARC are
included in the Overview report, and there is a DMARC-specific report in Monitor -> DMARC
Verification.

Unfortunately, there is no direct report for SPF and DKIM verification results. However, since we
are using Content Filters to handle messages failing SPF and DKIM, we can use Content Filters
report to view how many times each filter was matched. If you need reporting for DKIM and SPF
verified messages, you can create an additional content filter looking for them, and setting the
action to Add Log Entry

12
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

13
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.
 ESA BEST PRACTICES

14
2015 Cisco and/or its affiliates. All rights reserved. This document is Customer facing.