The settings listed below are a guide only and cannot meet all use cases. You should Configure DNS Authentication Definition and DNS Authentication Policy to fit your requirements best.
This article contains information on DNS Authentication, including SPF, DKIM, and DMARC protocols, their roles in email authentication, and guidance on configuring inbound DNS Authentication policies, to enhance email security and delivery.
DNS Authentication Standards
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.
- SPF (Sender Policy Framework) is an open standard for email authentication. It ensures that any messages sent using a domain come from permitted sources. It checks the domain from the inbound message's From Address to see if the originating IP address is listed in the domain's DNS record. If the IP address is not listed, a failed result is returned.
- DKIM (Domain Keys Identified Mail) adds a cryptographic hash or signature as a new header to outbound messages. This ensures outbound messages haven't been altered after leaving the sending organization's mail server by matching the hash or signature to the DNS records. DKIM requires a public DKIM key to be published in a TXT record in the DNS record for the sender's domain by the domain owner.
If you're sending all outbound mail through Mimecast and want to implement DKIM, only Mimecast must sign message headers with DKIM signatures. If any servers route mail with signed DKIM messages before it reaches Mimecast (e.g. Microsoft 365, On-Premise servers) the check will likely fail on the recipient side as that mail server didn't deliver the message.
- DMARC (Domain-Based Message Authentication, Reporting & Conformance) is an email validation system designed to detect and prevent email spoofing that builds protection on top of the SPF and DKIM mechanisms. It ensures messages are correctly authenticated using the SPF and DKIM email authentication standards. Should an inbound message fail these checks, an action defined in the sending domain's DMARC DNS record is applied. DMARC also allows domain owners to enable DMARC reports. These allow you to determine if your domain is being used without your permission or if action needs to be taken if messages are being rejected/quarantined unexpectedly. DMARC is implemented by creating a TXT record in the domain owner's DNS record for a domain.
Inbound DNS Authentication Policy Configuration
Listed below is the recommended configuration for Inbound DNS Authentication policies. This approach is designed to balance maintaining email security whilst giving every opportunity to deliver an inbound message.
Should you wish to restrict this configuration further, additional configuration information can be found on Configuring DNS Authentication Definition and Configuring DNS Authentication Policy.
SPF
| Option | Recommended Setting | Notes |
|---|---|---|
| None | Ignore Managed/Permitted Sender Entries | The domain owner has not chosen to implement SPF, meaning that senders using this domain do not need to authenticate to send on its behalf. Therefore, performing spam/reputation-based checks is recommended to minimize unwanted mail. |
| Neutral | Ignore Managed/Permitted Sender Entries | Neutral SPF results are when the domain owner has not specified whether a sender using this domain can send on their behalf. With this in mind, messages returning this SPF result should be spam scanned to minimize unwanted mail being received. |
| Soft Fail | Ignore Managed/Permitted Sender Entries | The Soft Fail result is generally considered temporary while SPF is 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 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 Fail | Reject | Any 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. |
| PermError | Ignore Managed/Permitted Sender Entries | PermErrors are similar to TempErrors. They can be caused by incorrectly formatted SPF records being present and require DNS administrator intervention to correct them. Messages with this status should be accepted after having Spam/Reputation based checks applied. |
| TempError | Ignore Managed/Permitted Sender Entries | TempErrors 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 accepted after having spam/reputation-based checks applied. |
DKIM
| Option | Recommended Settings | Notes |
|---|---|---|
| None | Ignore Managed/Permitted Sender Entries |
Ignoring Auto Allow or Permitted Sender Entries. Spam checks are performed when the DKIM check results in a "None" result.
|
| Fail | Ignore Managed/Permitted Sender Entries | Messages 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. |
| PermError | Ignore Managed/Permitted Sender Entries | PermErrors can be caused by incorrect values 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. |
| TempError | Ignore Managed/Permitted Sender Entries | TempErrors 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 accepted after having spam/reputation-based checks applied. |
DMARC
| Option | Recommended Setting | Notes |
|---|---|---|
| None | Ignore Managed/Permitted Sender Entries | Ignoring Auto Allow or Permitted Sender Entries. Spam checks are performed when the DMARC check results in a "None" result. |
| Fail | Honor DMARC Record | Messages that result in the Fail result should apply the action defined by the domain owners' DMARC policy. |
| PermError | Ignore Managed/Permitted Sender Entries | PermErrors can be caused by incorrect values specified within the domain's DNS records. Messages with this result should be configured to be accepted after having spam/reputation-based checks applied. |
| TempError | Ignore Managed/Permitted Sender Entries | TempErrors 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 accepted after having spam/reputation-based checks applied. |
It is also important to configure a least one Outbound DNS Authentication policy. This ensures unauthorized parties do not use the domains you control to send messages on your behalf.
Confirming Your Configured Checks are Taking Place
After configuring your inbound checks, knowing if they are applied to inbound messages is important. This can be achieved by viewing the headers of an inbound message. Mimecast adds an authentication header entry containing the results of any configured DNS Authentication checks.
For example, an inbound message with 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
To secure outbound messages, you must:
- Implement SPF for outbound email delivery.
- Create a DNS Entry
- Implement outbound DKIM signing.
Considerations
DNS Authentication definitions are required for inbound and outbound checks before configuring DNS Authentication policies. Consider the following before getting started:
-
Inbound Emails: DNS Authentication helps prevent 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 key pair 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.
Example - this is one specific use case/use of policies (and is not intended as a recommended policy set-up):
- A message fails SPF (Hard Fail), DKIM and DMARC; the message would be rejected based on the "SPF - Hard Fail" action, since that is the most restrictive action.
- In this example, to not perform any action despite the failed checks, "SPF - Hard Fail", "DKIM - Fail" and "DMARC - Fail" would all need to be set to "Take No Action", since any of those configured with a more restrictive action would take precedence.
Action Check Reject SPF - Hard Fail Ignore Permitted Sender Entries DKIM - Fail Take No Action DMARC - Fail - If you have enabled both DKIM and SPF with a strict DMARC setting, out-of-office or null senders can be rejected by DMARC. If you have more than one domain configured, configure a bypass policy that applies to null senders as follows:
Option / Field Value Policy Narrative Provide a descriptive name for the policy (e.g., DKIM & SPF - Null Addresses). Select Option Specify your DNS Authentication definition. Emails From: Address Based On Both Emails From: Applies From Individual Email Address Emails From: Specifically <> Emails To: Applies To Everyone Emails To: Specifically This applies to all Recipients Validity: Enable / Disable Enable Validity: Set Policy as Perpetual Always On
See Also...
- Configuring DNS Authentication - configuring DNS Authentication (Inbound/Outbound) Definitions
- Configuring DNS Authentication Policy - configuring DNS Authentication (Inbound/Outbound Policies)
- Securing UK Government Email Guide
- Securing US Government Email Guide
Comments
Please sign in to leave a comment.