With DomainKeys or DKIM email authentication, the sender signs the email using public key cryptography. The verified domain can then be used to detect forgeries by comparing it with the domain in the From: (or Sender:) header of the email.

DomainKeys and DKIM consist of two main parts: signing and verification. AsyncOS supports the “signing” half of the process for DomainKeys, and it supports both signing and verification for DKIM. You can also enable bounce and delay messages to use DomainKeys and DKIM signing.

1. Administrator (domain owner) publishes a public key into the DNS name space.
2. Administrator loads a private key in the outbound Mail Transfer Agent (MTA).
3. Email submitted by an authorized user of that domain is digitally signed with the respective private key. The signature is inserted in the email as a DomainKey or DKIM signature header and the email is transmitted.
4. Receiving MTA extracts the DomainKeys or DKIM signature from the header and the claimed sending domain (via the Sender: or From: header) from the email. The public key is retrieved from the claimed signing domain which is extracted from DomainKeys or DKIM signature header fields.
5. The public key is used to determine whether the DomainKeys or DKIM signature was generated with the appropriate private key.

To test your outgoing DomainKeys signatures, you can use a Yahoo! or Gmail address, as these services are free and provide validation on incoming messages that are DomainKeys signed.

DomainKeys and DKIM signing in AsyncOS is implemented via domain profiles and enabled via a mail flow policy (typically, the outgoing “relay” policy). For more information, see the “Configuring the Gateway to Receive Mail” chapter. Signing the message is the last action performed by the appliance before the message is sent.

Domain profiles associate a domain with domain key information (signing key and related information). As email is sent via a mail flow policy on the appliance , sender email addresses that match any domain profile are DomainKeys signed with the signing key specified in the domain profile. If you enable both DKIM and DomainKeys signing, the DKIM signature is used. You implement DomainKeys and DKIM profiles via the domainkeysconfig CLI command or via the Mail Policies > Domain Profiles and the Mail Policies > Signing Keys pages in the GUI.

DomainKeys and DKIM signing works like this: a domain owner generates two keys — a public key stored in the public DNS (a DNS TXT record associated with that domain) and a private key that is stored on the appliance is used to sign mail that is sent (mail that originates) from that domain.

Note	From Async0S 10.0 and later, you can select whether you want to use the From: header for DKIM Signing option in the DKIM Global Settings page of the web interface. It is mainly important to use the From: header with DKIM Signing for proper DMARC verification.

If a valid address is not found, the message is not signed and the event is logged in the mail_logs.

Note	If you create both a DomainKey and DKIM profile (and enable signing on a mail flow policy), AsyncOS signs outgoing messages with both a DomainKeys and DKIM signature.

If a valid sending address is found, the sending address is matched against the existing domain profiles. If a match is found, the message is signed. If not, the message is sent without signing. If the message has an existing DomainKeys (a “DomainKey-Signature:” header) the message is only signed if a new sender address has been added after the original signing. If a message has an existing DKIM signature, a new DKIM signature is added to the message.

AsyncOS provides a mechanism for signing email based on domain as well as a way to manage (create new or input existing) signing keys.

The configuration descriptions in this document represent the most common uses for signing and verification. You can also enable DomainKeys and DKIM signing on a mail flow policy for inbound email, or enable DKIM verification on a mail flow policy for outbound email.

Note	When you configure domain profiles and signing keys in a clustered environment, note that the Domain Key Profile settings and Signing Key settings are linked. Therefore, if you copy, move or delete a signing key, the same action is taken on the related profile.

A signing key is the private key stored on the appliance . When creating a signing key, you specify a key size. Larger key sizes are more secure; however, larger keys also can impact performance. The appliance supports keys from 512 bits up to 2048 bits. The 768 - 1024 bit key sizes are considered secure and used by most senders today. Keys based on larger key sizes can impact performance and are not supported above 2048 bits. For more information about creating signing keys, see Creating or Editing a Signing Key.

If you are entering an existing key, simply paste it into the form. Another way to use existing signing keys is to import the key as a text file. For more information about adding existing signing keys, see Importing or Entering Existing Signing Keys.

Once a key is entered, it is available for use in domain profiles, and will appear in the Signing Key drop-down list in the domain profile.

Once you have associated a signing key with a domain profile, you can create DNS text record which contains your public key. You do this via the Generate link in the DNS Text Record column in the domain profile listing (or via domainkeysconfig -> profiles -> dnstxt in the CLI):

For more information about generating a DNS Text Record, see Generating a DNS Text Record.

You can also view the public key via the View link on the Signing Keys page:

A domain profile associates a sender domain with a signing key, along with some other information needed for signing.

• A name for the domain profile.
• A domain name (the domain to be included in the “d=” header).
• A selector (a selector is used to form the query for the public key. In the DNS query type, this value is prepended to the “_domainkey.” namespace of the sending domain).
• A canonicalization method (the method by which the headers and content are prepared for presentation to the signing algorithm). AsyncOS supports both “simple” and “nofws” for DomainKeys and “relaxed” and “simple” for DKIM.
• A signing key (see Signing Keys for more information).
• A list of headers and the body length to sign (DKIM only).
• A list of tags you want to include in the signature’s header (DKIM only). These tags store the following information:
  • The identity of the user or agent (e.g., a mailing list manager) on whose behalf the message is signed.
  • A comma-separated list of query methods used to retrieve the public key.
  • The timestamp of when the signature was created.
  • The expiration time of the signature, in seconds.
  • A vertical bar-separated (i.e., | ) list of header fields present when the message was signed.
• The tags you want to include in the signature (DKIM only).
• A list of Profile Users (addresses allowed to use the domain profile for signing).

Note	The domain in the addresses specified in the profile users must match the domain specified in the Domain field.

You can search through all of your existing domain profiles for a specific term. See Searching Domain Profiles for more information.

Additionally, you can choose whether to:

• Sign system-generated messages with DKIM signatures

• Use From header for DKIM signing

  For instructions, see Editing DKIM Global Settings.

Lines such as the following are added to the mail logs upon DomainKeys signing:

Tue Aug 28 15:29:30 2007 Info: MID 371 DomainKeys: signing with dk-profile - matches user123@example.com
Tue Aug 28 15:34:15 2007 Info: MID 373 DomainKeys: cannot sign - no profile matches user12@example.com

Lines such as these are added to the mail logs upon DKIM signing:

Tue Aug 28 15:29:54 2007 Info: MID 372 DKIM: signing with dkim-profile - matches user@example.com
Tue Aug 28 15:34:15 2007 Info: MID 373 DKIM: cannot sign - no profile matches user2@example.com

A DKIM verification profile is a list of parameters that the appliance's mail flow policies use for verifying DKIM signatures. For example, you can create two verification profiles, one that allows 30 seconds before a query times out and a second that allows only 3 seconds before a query times out. You can assign the second verification profile to the Throttled mail flow policy to prevent connection starvation in case of a DDoS. A verification profile consists of the following information:

• A name for the verification profile.
• The smallest and largest acceptable public key size. The default key sizes are 512 and 2048, respectively.
• The maximum number of signatures in the message to verify. If a message has more signatures than the maximum amount you defined, the appliance skips verification of the remaining signatures and continues to process the message. The default is 5 signatures.
• The maximum allowed difference in time (in seconds) between the sender’s system time and verifier’s. For example, if the message signature expires at 05:00:00 and the verifier’s system time is 05:00:30, the message signature is still valid if the allowed difference in time is 60 seconds but it is invalid if the allowed difference is 10 seconds. The default is 60 seconds.
• An option whether to use a body length parameter.
• The SMTP action to take in case of a temporary failure.
• The SMTP action to take in case of a permanent failure.

You can search through all of your existing verification profiles by the profile name.

You can export your DKIM verification profiles as a text file in your appliance's configure directory. When you export the verification profiles, all of the profiles existing on the appliance are put into a single text file. See Exporting DKIM Verification Profiles for more information.

You can import DKIM verification profiles that you previously exported. Importing DKIM verification profiles causes all of the current DKIM verification profiles on the machine to be replaced. See Importing DKIM Verification Profiles for more information.

To use SPF and SIDF with an appliance , publish the SPF record according to the RFCs 4406, 4408, and 7208. Review RFC 4407 for a definition of how the PRA identity is determined. You may also want to refer to the following website to view common mistakes made when creating SPF and SIDF records:

http://www.openspf.org/FAQ/Common_mistakes

If you use the spf-status filter rule, you can check against the SPF/SIDF verification results using the following syntax:

if (spf-status == "Pass")

If you want a single condition to check against multiple status verdicts, you can use the following syntax:

if (spf-status == "PermError, TempError")

You can also check the verification results against the HELO, MAIL FROM, and PRA identities using the following syntax:

if (spf-status("pra") == "Fail")

Note	You can only use the spf-status message filter rule to check results against HELO, MAIL FROM, and PRA identities. You cannot use the spf-status content filter rule to check against identities. The spf-status content filter checks only the PRA identity.

You can receive any of the following verification results:

• None - no verification can be performed due to the lack of information.
• Pass - the client is authorized to send mail with the given identity.
• Neutral - the domain owner does not assert whether the client is authorized to use the given identity.
• SoftFail - the domain owner believes the host is not authorized to use the given identity but is not willing to make a definitive statement.
• Fail - the client is not authorized to send mail with the given identity.
• TempError - a transient error occurred during verification.
• PermError - a permanent error occurred during verification.

The following example shows the spf-status message filter in use:

skip-spam-check-for-verified-senders:


if (sendergroup == "TRUSTED" and spf-status == "Pass"){

skip-spamcheck();

}

quarantine-spf-failed-mail:

if (spf-status("pra") == "Fail") {

if (spf-status("mailfrom") == "Fail"){

# completely malicious mail

quarantine("Policy");

} else {

if(spf-status("mailfrom") == "SoftFail") {

# malicious mail, but tempting

quarantine("Policy");

}

}

} else {

if(spf-status("pra") == "SoftFail"){

if (spf-status("mailfrom") == "Fail"

or spf-status("mailfrom") == "SoftFail"){

# malicious mail, but tempting

quarantine("Policy");

}

}

}

stamp-mail-with-spf-verification-error:

if (spf-status("pra") == "PermError, TempError"

or spf-status("mailfrom") == "PermError, TempError"

or spf-status("helo") == "PermError, TempError"){

# permanent error - stamp message subject

strip-header("Subject");

insert-header("Subject", "[POTENTIAL PHISHING] $Subject"); 

}

.

You can also enable the spf-status rule from the content filters in the GUI. However, you cannot check results against HELO, MAIL FROM, and PRA identities when using the spf-status content filter rule.

To add the spf-status content filter rule from the GUI, click Mail Policies > Incoming Content Filters. Then add the SPF Verification filter rule from the Add Condition dialog box. Specify one or more verification results for the condition.

After you add the SPF Verification condition, specify an action to perform based on the SPF status. For example, if the SPF status is SoftFail, you might quarantine the message.

The spf-passed rule shows the results of SPF verification as a Boolean value. The following example shows an spf-passed rule used to quarantine emails that are not marked as spf-passed:

quarantine-spf-unauthorized-mail:

if (not spf-passed) {


quarantine("Policy");

}

Note

Unlike the spf-status rule, the spf-passed rule reduces the SPF/SIDF verification values to a simple Boolean. The following verification results are treated as not passed in the spf-passed rule: None, Neutral, Softfail, TempError, PermError, and Fail. To perform actions on messages based on more granular results, use the spf-status rule.

The following describes how AsyncOS performs DMARC verification.

1. A listener configured on AsyncOS receives an SMTP connection.
2. AsyncOS performs SPF and DKIM verification on the message.
3. AsyncOS fetches the DMARC record for the sender’s domain from the DNS.
   • If no record is found, AsyncOS skips the DMARC verification and continues processing.
   • If the DNS lookup fails, AsyncOS takes action based on the specified DMARC verification profile.

4. Depending on DKIM and SPF verification results, AsyncOS performs DMARC verification on the message.

   Note	If DKIM and SPF verification is enabled, DMARC verification reuses the DKIM and SPF verification results.

5. Depending on the DMARC verification result and the specified DMARC verification profile, AsyncOS accepts, quarantines, or rejects the message. If the message is not rejected due to DMARC verification failure, AsyncOS continues processing.
6. AsyncOS sends an appropriate SMTP response and continues processing.

7. If sending of aggregate reports is enabled, AsyncOS gathers DMARC verification data and includes it in the daily report sent to the domain owners. For more information about the DMARC aggregate feedback report, see DMARC Aggregate Reports.

   Note	If the aggregate report size exceeds 10 MB or the size specified in the RUA tag of the DMARC record, AsyncOS sends delivery error reports to the domain owners.

How to Verify Incoming Messages Using DMARC

1. Identify the users in your organization (for example, executives) whose messages are likely to be forged. Create a new content dictionary and add the names of the identified users to it.

   While creating a content dictionary,

   • Enter the name of the user and not the email address. For example, enter “ Olivia Smith ” instead of “ olivia.smith@example.com .”
   • Do not configure Advanced Matching and Smart Identifiers.
   • Do not choose weight for the terms used.
   • Do not use regular expressions.

   The following figure shows a sample content dictionary created for Forged Email Detection.

   
   

   

   
   

   For instructions to configure a content dictionary, see Adding Dictionaries.

2. Create an incoming content or message filter to detect forged messages and the actions that the appliance must take on such messages. Use the following:
   • Condition/Rule: Forged Email Detection (See Content Filter Conditions and Message Filter Rules)

     Note

     If you want to skip the Forged email detection filter for messages from specific senders, choose the address list from the Exception List drop-down list. You can choose only the address lists that are created using the full email addresses. For more information on adding exception address list, refer to Using a List of Sender Addresses for Incoming Connection Rules.

   • Action: Forged Email Detection or any other actions based on your requirement. (See Content Filter Conditions and Message Filter Rules)
3. Add the newly created content filter to an incoming mail policy. See How to Enforce Mail Policies on a Per-User Basis.

To view data about forged messages detected, see the Forged Email Matches report page (Monitor > Forged Email Matches). This report page includes the following reports:

• Top Forged Email Matches. Displays the top ten users in the content dictionary that matched the forged From: header in the incoming messages.
• Forged Email Matches: Details. Displays a list of all the users in the content dictionary that matched the forged From: header in the incoming messages and for a given user, the number of messages matched. Click on the number to view a list of messages in Message Tracking.

To display details of forged messages detected by the appliance in Message Tracking, make sure that:

• Message Tracking is enabled. See Tracking Messages.
• Content or message filters for detecting forged messages are operational.