Policies - Configuring DNS Authentication Policy

This article contains information on configuring DNS Authentication policies in Mimecast for email security, detailing setup steps for inbound and outbound policies, and best practices for SPF and DKIM verification.

DNS Authentication policies control the types of email authentication checks performed when we send or receive a message. The following systems work by defining extra DNS records for the sending domain. See the DNS Authentication Configuration Guide before configuring any DNS Authentication definitions.

Mail Transfer Agents (MTAs) can verify SPF or DKIM for inbound mail if the sender publishes DNS entries for them in their domain records.
 

Configuring a DNS Authentication (Inbound or Outbound) Policy

To configure an Inbound or Outbound DNS Authentication policy:

  1. Log into the Mimecast Administration Console.
  2. Navigate to Policies | Gateway Policies.
  3. Either click on the:
      • DNS Authentication - Inbound menu item to configure an inbound policy.
      • DNS Authentication - Outbound menu item to configure an outbound policy.
  1.  Either click on the:
      • Policy to be changed.
      • New Policy button to create a policy.
  1.  Complete the Options section as required:
Field / Option Description
Policy Narrative Provide a description of the policy to allow you to easily identify it in the future.
Select Option Select the required DNS Authentication definition for the policy. See the Configuring DNS Authentication Definition page for full details.
  1. Complete the Emails From and Emails To sections as required:

Field / Option Description
Addresses Based On

Specify the email address characteristics the policy is based on. This option is only available in the "Emails From" section. The options are:

  • The Return Address (Mail Envelope From): This default setting applies the policy to the SMTP address match based on the message's envelope or true address (i.e., the address used during SMTP transmission).
  • The Message From Address (Message Header From): This policy applies based on the masked address used in the message's header. 
  • Both: Applies the policy based on the mail Envelope From or the Message Header From, whichever matches. If both match the specified value, the Message Header From is used.

    If this option is specified and the "Verify SPF for Inbound Mail" option is enabled in the definition, the MTA performs an SPF check. It uses the domain in the Envelope From: address to decide on an action. Having previously evaluated the SPF result, it won't be reevaluated at the header level. This means an SPF check can fail if the Header From: address isn't aligned correctly, even if the Envelope From: address is. Additionally, if you have two Inbound DNS Authentication policies, where one checks the envelope address and the other checks both the header and envelope or header address only, you may see SPF failures as outlined above. When two inbound DNS Authentication checks are performed (usually SPF checks based on the Envelope and Header From: addresses), the most restrictive action applies. To bypass a message that fails on a Header-based SPF check, specify the Take No Action option, and ensure no Envelope-based SPF check is configured to either Reject or Ignore Permitted Sender Entries.

Applies From / To

Specify the sender characteristics the policy is based on. For multiple policies, you should apply them from the most to least specific. The options are:

  • Everyone: Includes all users (i.e., internal and external). This option is only available in the "Emails From" section.
  • Internal Address: Includes only internal organization addresses.
  • External Address: Includes only external organization addresses. This option is only available in the "Emails From" section.
  • Email Domain: This enables you to specify a domain name to which this policy is applied. The domain name is entered in the Specifically field.
  • Address Groups: This enables you to specify a directory or local group. If this option is selected, click the Lookup button to select a group from the Profile Group field. Once a group has been selected, you can click the Show Location field to display the group's path.
  • Address Attributes: This enables you to specify a predefined Attribute. The attribute is selected from the Where Attribute drop-down list. Once the Attribute is specified, a value must be entered in the Is Equal To field. This can only be used if attributes are configured for user accounts.
  • Individual Email Address: This enables you to specify an SMTP address. The email address is entered in the Specifically field.
  1. Complete the Validity on page section as required:

Field / Option Description
Enable / Disable Use this to enable (default) or disable a policy. Disabling the policy allows you to prevent it from being applied without having to delete or backdate it. Should the policy's configured date range be reached, it is automatically disabled.
Set Policy as Perpetual Specifies that the policy's start and end dates are set to "Eternal," meaning the policy never expires.
Date Range Specify a start and end date for the policy. This automatically deselects the "Eternal" option.
Policy Override Select this to override the default order that policies are applied. If there are multiple applicable policies, this policy is applied first unless more specific policies of the same type have also been configured with an override.
Bi-Directional If selected, the policy also applies when the policy's recipient is the sender, and the sender is the recipient.
Source IP Ranges (n.n.n.n/x) Enter any required Source IP Ranges for the policy. These only apply if the source IP address used to transmit the message data falls inside or matches the range(s) configured. IP ranges should be entered in CIDR notation.
  1. Click on the Save and Exit button.

Best Practice Configuration - Inbound

To configure a DNS Authentication - Inbound policy best practice setup:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Policies | Gateway Policies.
  3. Select DNS Authentication - Inbound.
  4. Click on the New Policy button or select an existing active policy.
  5. Set the following options as follows:
    Field / Option Required configuration 
    Policy Narrative Enter a name for the policy
    Select Option  Select the DNS Authentication Inbound Definition
    Addresses Based On The Return Address (Email Envelope From)
    Applies From Both
    Specifically  Applies to all Senders
    Applies To Internal Addresses
    Specifically  Applies to all Internal Recipients
    Enable / Disable  Enable
    Set policy as perpetual  Always On
    Date Range  All time
    Policy Override  Leave the checkbox unchecked
    Source IP Ranges (n.n.n.n/x) Leave the text box blank
  6. Click on Save and Exit.

Best Practice Configuration - Outbound

To configure a DNS Authentication - Outbound policy best practice setup:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Gateway | Policies.
  3. Select DNS Authentication - Outbound.
  4. Click on the New Policy button or select an existing active policy.
  5. Set the following options as follows:
    Field / Option Required configuration 
    Policy Narrative Enter a name for the policy
    Select Option  Select the newly created and verified definition
    Addresses Based On Both
    Applies From Email Domain
    Specifically  Enter the internal domain that you want DNS Signing for
    Applies To Everyone
    Specifically  Applies to all Recipients
    Enable / Disable  Enable
    Set policy as perpetual  Always On
    Date Range  All time
    Policy Override  Leave the checkbox unchecked
    Source IP Ranges (n.n.n.n/x) Leave the text box blank
  6. Click on Save and Exit.

Implementing SPF for Outbound Email Delivery

To ensure a successful implementation of SPF with Mimecast, include a comprehensive list of our outbound IP addresses in your DNS SPF record. This is a long list (24 distinct IP4 ranges at the time of writing), and new ranges may be added in the future without notice. However, you can ensure your record is always up to date by including the "xx._netblocks.mimecast.com" statement.

To determine what "xx" is for your region, refer to the table below:
 

Field / Option Description
Europe (excluding Germany) v=spf1 include:eu._netblocks.mimecast.com ~all
Germany v=spf1 include:de._netblocks.mimecast.com ~all
United States of America v=spf1 include:us._netblocks.mimecast.com ~all
United States of America (USB) v=spf1 include:usb._netblocks.mimecast.com ~all
Canada v=spf1 include:ca._netblocks.mimecast.com ~all
South Africa v=spf1 include:za._netblocks.mimecast.com ~all
Australia v=spf1 include:au._netblocks.mimecast.com ~all
Offshore v=spf1 include:je._netblocks.mimecast.com ~all
Global (includes all the above) v=spf1 include:_netblocks.mimecast.com ~all


Some typical examples are provided below as a starting point for constructing an appropriate record. While these examples use the global "v=spf1 include: netblocks.mimecast.com ~all" SPF record, you can replace this with your regional one.
 

Scenario Description Example
Simple Case Relaxed configuration, which only sends external mail for a given domain. "v=spf1 include:_netblocks.mimecast.com ~all"
Strict Case Implements a strict SPF reject for unmatched requests. We recommend testing with the relaxed syntax first. "v=spf1 include:_netblocks.mimecast.com –all"
Customers with an Existing SPF Record for a Given Domain If you have an existing SPF record representing a range of possible senders, these examples show how you can include Mimecast as a legitimate sender. Old "v=spf1 mx ~all"
New "v=spf1 mx include:_netblocks.mimecast.com ~all"
Old "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123  -all"
New "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123  include:_netblocks.mimecast.com -all"
Customers with an Existing SPF Include Record for a Given Domain Customers with existing SPF records should review their entries to ensure Mimecast servers are referenced only once. Any previous Mimecast references should be removed in favor of _netblocks.mimecast.com. Customers using a domain include a mechanism to refer to a DNS entry that already references _netblocks.mimecast.com and needs to take no further action. Old "v=spf1 include:example.com -all"
New "v=spf1 include:example.com include:_netblocks.mimecast.com -all"

Configuring a DNS Entry

If you wish to implement SPF for your domain, you must configure a corresponding TXT DNS record. This performs a TXT record lookup and validates the SPF record entry. You can have multiple mechanisms (IP/Host), but Mimecast must be the first one listed.

To check your existing TXT/SPF records, use an available DNS query service. There are many tools for this available on the internet as well as command-line applications.

Some DNS providers don't allow for TXT records to exceed 255 characters. If this is the case, contact your DNS provider for assistance.

Using ARC (Authenticated Received Chain)

ARC allows DMARC-protected messages to pass inbound DMARC checks when forwarded by intermediary services. This is useful when the messages are forwarded by newsletter services or auto forwarders, as they typically fail DKIM checks performed during DMARC validation. This is because the message content has changed, invalidating the applied DKIM signature.

During the forwarding process, the receiving mail server performs DMARC checks to confirm that the message has been received from an authorized source. Once the validity of the sender has been confirmed, the forwarding mail server appends the following:

      • ARC-Authentication results header: This preserves the results of the previously applied SPF checks.
      • ARC Signature: This ensures that the message passes any further DKIM checks.

We currently only offer the ability to add ARC Authentication-Results and ARC signatures to inbound messages. We don't include ARC entries in enforcing configured Inbound DNS Authentication policies. This means that if an inbound message containing ARC entries is received by Mimecast, they are ignored, and any configured Inbound DNS Authentication policies are applied using the information from the previous hop in the delivery path.

To apply ARC signing to inbound messages, all you need is an Inbound DNS Authentication policy with SPF, DKIM, and DMARC checks enabled.

See Also...

Was this article helpful?
1 out of 4 found this helpful

Comments

0 comments

Please sign in to leave a comment.