Configuring DNS Authentication (Inbound / Outbound) Definitions and Policies

Document created by user.oxriBaJeN4 Employee on Sep 11, 2015Last modified by user.oxriBaJeN4 Employee on Oct 26, 2017
Version 17Show Document
  • View in full screen mode

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:

  • Sender Policy Framework (SPF): This is an open standard for email authentication, that tells you whether the IP address connecting to us is permitted to send mail for that domain. SPF validates the connecting IP address, by looking up the DNS record for the domain in the envelope MAIL FROM or HELO/EHLO. 
  • Domain Keys Identified Mail (DKIM) Signing: A signature is added to outbound messages, which is used to determine if the contents have been tampered with. DKIM validates the contents of the message body and headers, by creating a cryptographic hash (or signature) and adding it as a new header to the message. It confirms that a message's content was sent from a specific domain, by matching the signature to the DNS records.
  • Domain Based Message Authentication, Reporting and Conformance (DMARC): This is an email validation system that builds protection on top of the SPF and DKIM mechanisms. It is designed to detect and prevent email spoofing.
Mail Transfer Agents (MTAs) can verify SPF or DKIM for inbound mail, if the sender publishes DNS entries for them in their domain records.

Considerations

 

DNS Authentication definitions are required for both inbound and outbound checks, prior to configuring DNS Authentication policies. Consider the following before getting started:

  • Inbound Emails: DNS Authentication is helpful in preventing unwanted and potentially harmful messages from reaching users. When enabled, checks are performed against all messages regardless of any auto allow or permitted sender entries being present. This ensures any messages from the sender to these internal users are not bypassed for spam checks. The following actions can apply, depending on the result of the inbound checks:
    • Reject
    • Ignore Managed / Permitted Sender entries
    • Take no action
  • Outbound Emails: If DKIM signing is required for outbound mail, your organization's DNS record must be populated with the appropriate public key as part of a DNS Authentication Outbound Signing definition. The private key of the same keypair must be populated in a DNS Authentication policy, along with the domain and selector of that record. Once this policy is applied to outbound mail, messages that meet the policy criteria are DKIM signed.
  • Action Severity: If your definition settings conflict with each other, the most restrictive action wins. In the following example, if a message fails DMARC, it is rejected because the "SPF - Fail" option contains the most restrictive action. To not perform an action when a message fails DMARC, set the SPF action to "Take No Action" in a separate DNS Authentication definition for the sending domain.

ActionCheck
RejectSPF - Fail
Ignore Permitted Sender EntriesDKIM - Fail
Take No ActionDMARC - Fail

 

Configuring an Inbound DNS Authentication Definition 

 

To configure an Inbound DNS Authentication definition:

  1. Log on to the Administration Console.
  2. Click on the Administration toolbar menu item.
  3. Click on the Gateway | Policies menu item. The Gateway Policy Editor is displayed.
  4. Click on the Definitions drop down. A list of the definition types is displayed.
    Definitions List
  5. Select the DNS Authentication - Inbound definition type from the list.
  6. Either click on the:
    • Definition to be changed.
    • New DNS Authentication - Inbound Checks button to create a definition.
  7. Complete the DNS Authentication - Inbound Check Properties section as follows:
    FieldConfigurable ActionsDescription
    DescriptionN/AEnter a description for the definition that allows you to easily identify it at a later date.
    Verify SPF for Inbound MailEnabled / DisabledSelect this to enable SPF checks on inbound messages. We'll only be able to perform these checks if the sender has published at least one SPF record for their domain. 
    Verify DKIM for Inbound MailEnabled / DisabledSelect this to enable DKIM checks on inbound messages. We'll only be able to perform these checks if the sender has published a valid DKIM public key for their domain.
    Verify DMARC for Inbound MailEnabled / DisabledSelect this to enable DMARC checks on inbound messages. We'll only be able to perform these checks if the sender has published a valid DMARC record for their domain. If selected, you don't need to select either the "Verify SPF for Inbound Mail" or "Verify DKIM for Inbound Mail" options.

    If selected, DKIM checks are enabled by default. Should a message be received from a sender that hasn't published a DMARC policy, the MTA falls back to checking whether a valid DKIM signature has been applied to the inbound message. This ensures the inbound message is legitimate, rather than just allowing it to pass through untouched. When this occurs, the configured action for a DKIM check result is applied, even if the DKIM check is disabled in the definition.

  8. Configure the action to apply for each of the possible results that can occur below, based upon the enabled inbound checks:
    SPF:
    Scan Result
    Configurable Actions
    None
    • Reject: Inbound messages are rejected when the SPF check returns a "None" result.
    • Ignore Managed / Permitted Sender Entries: Reputation, greylisting, and spam checks are performed when the SPF check returns a "None" result.
    • Take No Action: No specific actions are applied to a message when the SPF check returns a "None" result.
    Neutral
    • Reject: Inbound messages are rejected when the SPF check returns a "Neutral" result.
    • Ignore Managed / Permitted Sender Entries: Reputation, greylisting, and spam checks are performed when the SPF check returns a "Neutral" result.
    • Take No Action: No specific actions are applied to a message when the SPF check returns a "Neutral" result.
    SoftFail
    • Reject: Inbound messages are rejected when the SPF check returns a "SoftFail" result.
    • Ignore Managed / Permitted Sender Entries: Reputation, greylisting, and spam checks are performed when the SPF check returns a "SoftFail" result.
    • Take No Action: No specific actions are applied to a message when the SPF check returns a "SoftFail" result.
    HardFail
    • Reject: Inbound messages are rejected when the SPF check returns a "HardFail" result.
    • Ignore Managed / Permitted Sender Entries: Reputation, greylisting, and spam checks are performed when the SPF check returns a "HardFail" result.
    • Take No Action: No specific actions are applied to a message when the SPF check returns a "HardFail" result.
    PermError
    • Reject: Inbound messages are rejected when the SPF check returns a "PermError" result.
    • Ignore Managed / Permitted Sender Entries: Reputation, greylisting, and spam checks are performed when the SPF check returns a "PermError" result.
    • Take No Action: No specific actions are applied to a message when the SPF check returns a "PermError" result.

    TempError

    • Reject: Inbound mail is rejected when the SPF check returns a "TempError" result.
    • Ignore Managed / Permitted Sender Entries: Reputation, greylisting, and spam checks are performed when the SPF check returns a "TempError" result.
    • Take No Action: No specific actions are applied to a message when the SPF check returns a "TempError" result.

    DKIM:

    Scan ResultConfigurable Actions
    None
    • Reject: Inbound messages are rejected when the DKIM check returns a "None" result.
    • Ignore Auto Allow or Permitted Sender Entries: Spam checks are performed when the DKIM check results in a "None" result.
    • Take No Action: No specific actions are applied to a message when the DKIM check returns a "None" result.
    Fail
    • Reject: Inbound messages are rejected when the DKIM check returns a "Fail" result.
    • Ignore Auto Allow or Permitted Sender Entries: Spam checks are performed when the DKIM check results in a "Fail" result.
    • Take No Action: No specific actions are applied to a message when the DKIM check returns a "Fail" result.
    PermError
    • Reject: Inbound messages are rejected when the DKIM check returns a "PermError" result.
    • Ignore Auto Allow or Permitted Sender Entries: Spam checks are performed when the DKIM check results in a "PermError" result.
    • Take No Action: No specific actions are applied to a message when the DKIM check returns a "PermError" result.
    TempError
    • Reject: Inbound messages are rejected when the DKIM check returns a "TempError" result.
    • Ignore Auto Allow or Permitted Sender Entries: Spam checks are performed when the DKIM check results in a "TempError" result.
    • Take No Action: No specific actions are applied to a message when the DKIM check returns a "TempError" result.

    DMARC:

    Scan ResultConfigurable Actions
    None
    • Reject: Inbound messages are rejected when the DMARC check returns a "None" result.
    • Ignore Auto Allow or Permitted Sender Entries: Spam checks are performed when the DMARC check results in a "None" result.
    • Take No Action: No specific actions are applied to a message when the DMARC check returns a "None" result.
    Fail
    • Reject: Inbound messages are rejected when the DMARC check returns a "Fail" result.
    • Ignore Auto Allow or Permitted Sender Entries: Spam checks are performed when the DMARC check results in a "Fail" result.
    • Honor DMARC DNS Record Action: Applies the action specified in the DMARC record for the sending domain specified by the domain owner.
      If a DMARC policy uses the 'Quarantine' action, Mimecast places the message in hold for review.
    • Take No Action: No specific actions are applied to a message when the DMARC check returns a "Fail" result.
    PermError
    • Reject: Inbound messages are rejected when the DMARC check returns a "PermError" result.
    • Ignore Auto Allow or Permitted Sender Entries: Spam checks are performed when the DMARC check results in a "PermError" result.
    • Take No Action: No specific actions are applied to a message when the DMARC check returns a "PermError" result.
    TempError
    • Reject: Inbound messages are rejected when the DMARC check returns a "TempError" result.
    • Ignore Auto Allow or Permitted Sender Entries: Spam checks are performed when the DMARC check results in a "TempError" result.
    • Take No Action: No specific actions are applied to a message when the DMARC check returns a "TempError" result.
  9. Click on the Save and Exit button.

 

Configuring an Outbound DNS Authentication Definition

 

This definition allows you to select the appropriate internal domain, and generate the public DKIM key for outbound mail. It also provides all of the information needed to be inserted into your domain's DNS entry.

 

To configure an Outbound DNS Authentication definition:

  1. Log on to the Administration Console.
  2. Click on the Administration toolbar menu item.
  3. Click on the Gateway | Policies menu item. The Gateway Policy Editor is displayed.
  4. Click on the Definitions drop down. A list of the definition types is displayed.
    Definitions List
  5. Click on the DNS Authentication - Outbound Signing definition type from the list. The list of definitions is displayed.
  6. Either click on the:
    • Policy to be changed.
    • New DNS Authentication - Outbound Signing button to create a definition.
  7. Complete the DNS Authentication - Outbound Signing Properties section as follows:
    Field / OptionDescription
    DescriptionEnter a description for the definition that allows you to easily identify it at a later date.
    Sign Outbound Messages with DKIMSelect this to enable DNS authentication checks on outbound mail.
    DKIM Key LengthAllows you configure the key length of the DKIM signature to be generated. You'll have the choice between creating DKIM keys with the length of 1024 or 2048 bits. This option is only displayed after an internal domain is selected.
    Using a DKIM key length of 2048 bits, will exceed the 255 character limit imposed in TXT records. Contact your DNS provider who should be able to assist you in creating the required TXT records.
    DomainUse the Lookup button to select an internal domain. This field is only displayed if the "Sign Outbound Messages with DKIM" option is selected.
    SelectorSelectors allow a domain to have more than one public key advertised in DNS. The default selector is "mimecastYYYYMMDD". Although this text entry can be adjusted, we recommend regularly switching to a new DNS Authentication policy. For this reason use "YYYYMMDD" in your selector. This field is only displayed if the "Sign outbound messages with DKIM" option is selected.
    Public KeyThis field is only displayed if the "Sign Outbound Messages with DKIM" option is selected.
    1. Click the Generate button to create the private and public key pairs. The private key is automatically saved in Mimecast, but is not be displayed for security reasons. The public key is displayed in the Public Key field.
    2. Copy the Public Key value to your clipboard.
    3. Add the Public Key to the DNS TXT Record for 'selector._domainkey.domain' where:
      • 'selector' equals the selector you have configured.
      • 'domain' equals the domain you are creating the DNS Authentication policy for.
    4. Click the Check DNS button to perform a DNS TXT lookup for 'selector._domainkey.domain'.
    5. Compare the string with the published string in the Public Key field.
    If the test fails due to Mimecast not finding a TXT record, allow up to 72 hours of propagation time after publishing the TXT record in DNS. It is important to ensure that the correct TXT record has been published, so that it matches the Public Key field entry. The definition will only activate after a successful DNS check.
  8. Click on the Save and Exit button.

 

Configuring a DNS Authentication (Inbound or Outbound) Policy

 

To configure an Inbound or Oubound DNS Authentication policy:

  1. Log on to the Administration Console.
  2. Click on the Administration menu item. A menu drop down is displayed.
  3. Click on the Gateway | Policies menu item. The Gateway Policy Editor is displayed.
  4. Either click on the:
    • DNS Authentication - Inbound menu item to configure an inbound policy.
    • DNS Authentication - Outbound menu item to configure an outbound policy.
  5. Either click on the:
    • Policy to be changed.
    • New Policy button to create a policy.
  6. Complete the Options section as required:
    Filed / OptionDescription
    Policy NarrativeProvide a description for the policy to allow you to easily identify it in the future.
    Select DNS AuthenticationSelect the required DNS Authentication definition for the policy.
  7. Complete the Emails From and Emails To sections as required:
    Field / OptionDescription
    Addresses Based OnSpecify the email address characteristics the policy is based on. This option is only available in the "Emails From" section. The options are:
    OptionDescription
    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)Applies the policy based on the masked address used in the message's header.
    BothApplies 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 based upon the domain in the "Envelope From:" address and decides on an action. Having already evaluated the SPF result, it won't be evaluated again at the header level. This means that an SPF check can fail due to the "Header From:" address not being aligned correctly, even though the "Envelope
    From:" address is.

     

    If you've 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 / ToSpecify the sender characteristics the policy is based on. For multiple policies, you should apply them from the most to least specific. The options are:
    OptionDescription
    EveryoneIncludes all users (i.e. internal and external). This option is only available in the "Emails From" section.
    Internal AddressIncludes only internal organization addresses.
    External AddressIncludes only external organization addresses. This option is only available in the "Emails From" section.
    Email DomainEnables you to specify a domain name to which this policy is applied. The domain name is entered in the Specifically field.
    Address GroupsEnables you to specify a directory or local group. If this option is selected, click on the Lookup button to select a group from the Profile Group field. Once a group has been selected, you can click on the Show Location field to display the group's path.
    Address AttributesEnables 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 AddressEnables you to specify an SMTP address. The email address is entered in the Specifically field.
  8. Complete the Validity section as required:
    Field / OptionDescription
    Enable / DisableUse this to enable (default) or disable a policy. Disabling the policy allows you to prevent it from being applied without having to delete or back date it. Should the policy's configured date range be reached, the it is automatically disabled.
    Set Policy as PerpetualSpecifies that the policy's start and end dates are set to "Eternal", meaning the policy never expires.
    Date RangeSpecify a start and end date for the policy. This automatically deselects the "Eternal" option.
    Policy OverrideSelect 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-DirectionalIf 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.
  9. Click on the Save and Exit button.

 

Implementing SPF for Outbound Email Delivery

 

To ensure a successful implementation of SPF with us, 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. You can ensure your record is always up to date by including the "_netblocks.mimecast.com" statement. Some typical examples are below as a starting point for constructing an appropriate record:

 

ScenarioDescriptionExample
Simple CaseRelaxed configuration which only sends external mail for a given domain."v=spf1 include:_netblocks.mimecast.com ~all"
Strict CaseImplements 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've 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 a -all"
New"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a include:_netblocks.mimecast.com -all"
Customers with an Existing SPF Include Record for a Given DomainCustomers with existing SPF records should review their entries to ensure Mimecast servers are referenced only once. Any previous Mimecast references should be removed in favour of _netblocks.mimecast.com. Customers using a domain include mechanism to refer to a DNS entry which already references _netblocks.mimecast.com, need 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'll need to configure a corresponding TXT DNS record. 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.

See Also...

 

1 person found this helpful

Attachments

    Outcomes