DNS Authentication Recommended Configuration Guide

Document created by user.3AEuBpAOr2 Expert on Jan 25, 2017Last modified by user.Yo2IBgvWqr on Sep 14, 2017
Version 9Show Document
  • View in full screen mode

DNS Authentication combines three industry-standard email authentication technologies that allow domain owners to control who sends on behalf of their domains. It also validates the authenticity of inbound messages.

This page should be read in conjunction with the DNS Authentication - Inbound Checks and DNS Authentication: Outbound Signing pages.

SPF (Sender Policy Framework)

 

SPF (Sender Policy Framework) helps ensure that any messages sent using a particular domain come from permitted sources.

 


Click image to enlarge

 

SPF checks work by taking the domain from the 'from address' of an inbound message and confirming if the originating IP address is listed in the domain's SPF record. If the IP address is not listed a failed result is returned.

 

DKIM (DomainKeys Identified Mail)

 

DKIM (DomainKeys Identified Mail) allows domain owners to sign outbound messages using private / public key signing techniques. This ensures outbound messages have not been altered after leaving the sending organization's mail server.

 


Click image to enlarge

 

The implementation of DKIM requires a public DKIM key to be published within a TXT record in the DNS record for a particular domain by the domain owner.

 

DMARC (Domain Based Message Authentication, Reporting & Conformance)

 

DMARC (Domain Based Message Authentication, Reporting & Conformance) ensures that messages are correctly authenticated using the SPF and DKIM email authentication standards. Should an inbound message fail these checks, an action is applied which is defined in the sending domain's DMARC DNS record. DMARC also allows domain owners to enable DMARC reports. These allow them to determine if their domain is being used without permission, or if action needs to be taken if messages are being rejected / quarantined unexpectedly.

 


Click image to enlarge

 

DMARC is implemented by creating a TXT record within the DNS record for a particular domain by the domain owner.

 

Below is the recommended configuration for Inbound DNS Authentication policies. This approach is designed to achieve a balance between maintaining email security, whilst giving every opportunity to deliver and inbound message. Should you wish to restrict this configuration further, there is additional configuration information that can be found in the Inbound DNS Authentication policy article.

 

Inbound DNS Authentication Policy Configuration

 

SPF

 

OptionRecommended SettingNotes
NoneIgnore Managed/Permitted Sender EntriesThe domain owner has not chosen to implement SPF, meaning that senders using this domain do not need to authenticated to send on its behalf. Therefore it is recommended to perform spam / reputation based checks to minimize the level of unwanted mail.
NeutralIgnore Managed/Permitted Sender EntriesNeutral SPF results are for when the domain owner has not specified whether a sender using this domain are permitted to send on their behalf. With this in mind messages returning this SPF result should be spam scanned to minimize the level of unwanted mail being received.
Soft FailIgnore Managed/Permitted Sender EntriesThe Soft Fail result is generally considered to be a temporary setting, whilst SPF is being configured. It does not cause any restrictions to be applied. All that is added is a header value containing the check result. However once all of the sending IP Addresses are added to the relevant SPF DNS record, the SPF failure action should be changed to Hard Fail. This is why inbound messages with this result should have spam / reputation based checks applied rather than rejected.
Hard FailRejectAny inbound messages that result in an SPF Hard Fail should be rejected. In these cases the sender is not sending the message from an authorized IP address. 
PermErrorIgnore Managed/Permitted Sender EntriesPermErrors are similar to TempErrors. They can be caused by incorrectly formatted SPF records being present, and require DNS administrator intervention to correct. Messages with this status should be accepted after having Spam / Reputation based checks applied.
TempErrorIgnore Managed/Permitted Sender EntriesTempErrors are normally caused by transitory DNS issues that cause SPF record lookups to fail. Due to the temporary nature of this problem, messages should be a accepted after having spam / reputation based checks applied.

 

DKIM

 

OptionRecommended SettingNotes
FailIgnore Managed/Permitted Sender EntriesMessages that result in the Fail result should be subjected to spam / reputation based checks to ensure that the appropriate steps are taken and messages are not incorrectly rejected.
PermErrorIgnore Managed/Permitted Sender EntriesPermErrors can be caused by incorrect values being specified in the domain's DKIM DNS record. Messages with this result should be configured to be accepted, after having spam / reputation based checks applied.
TempErrorIgnore Managed/Permitted Sender EntriesTempErrors are normally caused by transitory DNS issues that cause DKIM record lookups to fail. Due to the temporary nature of this problem, messages should be a accepted after having spam / reputation based checks applied.

 

DMARC

 

OptionRecommended SettingNotes
FailHonor DMARC RecordMessages that result in the Fail result should apply the action defined by the domain owners DMARC policy.
PermErrorIgnore Managed/Permitted Sender EntriesPermErrors can be caused by incorrect values being specified within the domain's DNS records. Messages with this result should be configured to be accepted, after having spam / reputation based checks applied.
TempErrorIgnore Managed/Permitted Sender EntriesTempErrors are normally caused by transitory DNS issues that cause DNS record lookups to fail. Due to the temporary nature of this problem, messages should be a accepted after having spam / reputation based checks applied.

 

It is also important to configure a least one Outbound DNS Authentication policy. This ensures the domains you control are not used by unauthorized parties to send messages on your behalf.

 

Confirming Your Configured Checks are Taking Place

 

After you have configured your inbound checks, it is important to know if they are being applied to inbound messages. This can be achieved by viewing the headers of an inbound message. Mimecast adds an authentication header entry there containing the results of any configured DNS Authentication checks. 

 

For example, here is an inbound message having SPF, DKIM, and DMARC checks applied and the appropriate headers entries added.

Authentication-Results: mimecast.com; spf=pass (spfCheck: domain of _spf.google.com designates 209.85.217.195 as permitted sender) client-ip=209.85.217.195; envelope-from=this_is_an_example_message@gmail.com; helo=mail-ua0-f195.google.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=allow dis=allow) header.from=gmail.com

Securing Outbound Messages

 

Implementing SPF for Outbound Email Delivery

 

For full details, see the "Implementing SPF for Outbound Email Delivery" section of the DNS Authentication: Outbound Signing article.

 

Creating the DNS Entry

 

For full details, see the "Creating the DNS Entry" section of the DNS Authentication: Outbound Signing article.

 

Implementing Outbound DKIM Signing

 

For details on implementing outbound DKIM signing please refer to the DNS Authentication: Outbound Signing article.

1 person found this helpful

Attachments

    Outcomes