Sign In with your
Trend Micro Account
Need Help?
Need More Help?

Create a technical support case if you need further support.

Best practice guide for DMARC Authentication in Trend Micro Email Security (EMS)

    • Updated:
    • 3 Apr 2020
    • Product/Version:
    • Trend Micro Email Security All
    • Platform:
    • N/A
Summary

Domain-based Message Authentication, Reporting & Conformance (DMARC) is an email authentication, policy, and reporting protocol. It builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (From:) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.

To leverage the DMARC protection, the sender domain owner should publish corresponding SPF, DKIM, DMARC records to DNS, send the message from the designated hosts or sign the message before sending; the message receiver (MTA, MUA) should get the instructions, including alignment criteria and actions in the record, combined with the local settings to do the verification and take necessary actions. For more details on DMARC, refer to RFC7489.

In this guide, we will introduce the DMARC feature in Trend Micro Email Security (EMS), how to use it, and how to solve problems or violations.

Details
Public

Introduction on EMS' DMARC

EMS' DMARC feature will prevent the spoofed messages by checking following two sides:

  • DMARC-SPF: SPF check and its alignment match between RFC5321.MailFrom domain and RFC5322.From domain.
  • DMARC-DKIM: DKIM check and its alignment match between RFC5322.From domain and “d” tag in signature.

Either DAMRC-SPF or DMARC-DKIM side gets a Pass result, the DMARC will also get a Pass result. If the both sides get a Fail result, the configured action will be taken.

EMS’ DMARC feature contains two modes, the default mode and the enforced mode.

  • Default mode: after the feature is enabled, all senders are under this mode by default.
  • Enforced mode: if the sender is added to the “Enforced Peers” list, it will be under this mode.

The difference of the two modes is the DMARC pass criteria in the enforced mode will be stricter than the default mode.

The following list describes the acronyms and definitions for terms used throughout this document:

TermDefinition
UIUser Interface
RFCRequest for Comments
SPFSender Policy Framework
DKIMDomainKeys Identified Mail
envelop sender
RFC5321.MailFrom
The field value of "Mail From:" command described in RFC5321. For example, "Mail From: <test@example.com>", envelop sender is test@example.com.
header sender
RFC5322.From
The field value of "From:" header described in RFC5322. For example, "From: <test@example.com>", header sender is test@example.com.
Organization domainThe main domain combined with the domain extension, found by checking a list of public DNS suffixes, and adding the next DNS label. For example, "a.b.c.d.example.com.au" and "example.com.au" will have the same organizational domain, because there is a registrar that offers names in ".com.au" to customers.

The SPF check follows the SPF protocol, using the connecting IP of the message to compare with the designated hosts in sender’s SPF record, and the check result may be Pass, Fail, SoftFail, None, Netural, PermError, and TempError. Refer to RFC7208 about detailed explanation for these results.

Only the Pass or Fail result is definitely to show the actual relationship between sender and the connecting IP. But others are meaningless which will have different understandings leading to different final results. To avoid confusing, it is better to clear such intermediate status that ask sender to correct the SPF DNS record if possible.

The SPF alignment match has two modes, which is decided by the “aspf” tag in sender’s DMARC DNS record, “r” for relaxed mode and “s” for strict mode. If it is strict mode, the RFC5321.MailFrom domain should be same as RFC5322.From domain; if it is relaxed mode, the RFC5321.MailFrom domain should be same organization domain with RFC5322.From domain. The alignment check result will be Pass and Fail.

The DKIM check follows the DKIM protocol, checking the signatures in the message to verify whether the message is modified during the transmission, and the check result may be Pass, Fail, None. Refer to RFC8601 about detailed explanation for Pass and Fail result. But the None result in EMS has been extended as that EMS does not verify any signatures in the message, it may be caused by following reasons:

  • No DKIM signatures at all.
  • Syntax invalid signatures.
  • No valid public key for corresponding signature.
  • Signature is signed by 3rd-party domain, that means the “d” tag is not same organization domain with RFC5322.From.

Only the Pass or Fail result is definitely to show the message’s non-change or not. But the None result is meaningless which will have different understandings leading to different final result. To avoid confusing, it is better to clear such intermediate status that ask the sender to correct the DKIM DNS record and sign the message with correct identity if possible.

The DKIM alignment match has two modes, which is decided by the “adkim” tag in sender DMARC DNS record, “r” for relaxed mode and “s” for strict mode. If it is strict mode, the RFC5322.From domain should be same as “d” tag in the signature; if it is relaxed mode, the RFC5322.From domain should be same organization domain with “d” tag in the signature. The alignment check result will be Pass, Fail and None. None result is suitable for the situation that DKIM result is None.

Default mode

EMS’ DMARC pass criteria in default mode is relaxed, the unclear result will keep, and the message will not be blocked due to unclear result. The determine flow will be as following:

Default mode

The final result for DMARC-SPF and DMARC-DKIM side will be as following:

Result of DMARC-SPF side
No.SPF CheckAlignmentDMARC-SPF
1PassPassPass
2PassFailFail
3FailPassFail
4FailFailFail
5None/Netural/SoftFail/PermError/TempErrorPassNone/Netural/SoftFail/PermError/TempError
6None/Netural/SoftFail/PermError/TempErrorFailFail
Result of DMARC-DKIM side
No.DKIM CheckAlignmentDMARC-DKIM
1PassPassPass
2PassFailFail
3FailPassFail
4FailFailFail
5NoneNoneNone

Based on above results of DMARC-SPF and DMARC-DKIM side, the DMARC result will be Pass if there is no apparent Fail result, the results in details will be as following: (* for all possible results)

No.DMARC-SPFDMARC-DKIMDMARC
1Pass*Pass
2*PassPass
3None/Netural/SoftFail/PermError/TempErrorNonePass
4None/Netural/SoftFail/PermError/TempErrorFailFail
5FailFailFail
6FailNoneFail

  

Enforced mode

EMS’ DMARC pass criteria in enforced mode is strict, the sender must publish the DMARC DNS record and the unclear result will be treated as Fail. The determine flow will be as following:

Enforced mode

The final result for DMARC-SPF and DMARC-DKIM side will be as following:

Result of DMARC-SPF side
No.SPF CheckAlignmentDMARC-SPF
1PassPassPass
2PassFailFail
3FailPassFail
4FailFailFail
5None/Netural/SoftFail/PermError/TempErrorPassFail
6None/Netural/SoftFail/PermError/TempErrorFailFail
Result of DMARC-DKIM side
No.DKIM CheckAlignmentDMARC-DKIM
1PassPassPass
2PassFailFail
3FailPassFail
4FailFailFail
5NoneNoneFail

Based on above results of DMARC-SPF and DMARC-DKIM side, the DMARC result will be Pass if there is Pass result in either one side, the results in details will be as following: (* for all possible results)

No.DMARC-SPFDMARC-DKIMDMARC RecordDMARC
1Pass*YPass
2*PassYPass
3FailFailYFail
4**NFail

EMS’ DMARC actions are as actions for other features, containing do not intercept, quarantine and delete, and can be configured by customer from UI console.

But as DMARC protocol says, the action for DMARC can be specified by the sender, so in order to obey the sender’s instruction, EMS’ DMARC action configuration is a mapping between them. The action can be configured separately for different “p” tag values in sender’s DMARC DNS record and for no DMARC DNS record. For example, you can configure the action as quarantine if the “p” tag is “none” and configure the action as do not intercept if there is no DMARC record.

There are some middle actions, such as x-header insertion, tag subjection, and notification, they can be used to show the DMARC violation happens, especially the x-header insertion will insert an X-header in message to record the DMARC information for this message, which will be helpful to solve the violation.

  

How to use EMS’ DMARC

To use EMS’ DMARC protection, just enable the feature on the UI console, and configure the actions which EMS will take when the DMARC violation happens.

But due to complicated mail flow environment, not all the senders implement the DMARC protocol completely and correctly, such as:

  • Network topology is not so clear for sender, it is hard for them to confirm their mail servers at a short time.
  • Sender is sending mails via 3rd-party, but some of them are not DMARC compatible.
  • To avoid the high system resource usage, or due to some business consideration, sender will not sign all the messages.
  • Due to some network issue, sometimes there may be DNS query issue.
  • Due to some DNS limitations, for example too many DNS look-up in a SPF record, sometimes there may be DNS query issue when the sender update the DNS.

So there may be a lot of violations at the beginning which may cause a lot of messages being intercept, even the annoying emotion to use DMARC.

So in order to reduce the impact to mail traffic due to unfamiliar with the protocol, it is preferred that apply the protection step by step, start from monitoring and end with preventing spoofed messages.

Some or all of the following plans can be taken, start from a small scope to a big one, from the non-intercept action to an intercept one, and from the default mode to enforced mode.

EMS’ DMARC protection can be applied to one of the managed domains, so that at the beginning only the messages for that domain will be affected, and experience can be accumulated to solve the DMARC violations.

If all of the violations of that applied domain are positive, DMARC protection can be applied to another domain, even the whole account with the “Default” label.

All of the DMARC actions can be configured as do not intercept, so that at the beginning all of the messages will not be blocked even DMARC violates. So that solving the violations will not affect the mail traffic.

After all the violations are positive, DMARC actions can be changed to intercept, such as quarantine and delete, according to the requirements.

As described above, the default DMARC mode is relaxed, but it is just a compromise for those senders who are not easy to implement DMARC, such as use a Softfail but not Fail for SPF result due to complex network topology, do not sign the messages due to some reason.

After all the violations are positive, and confirmed with the senders who will always obey to the DMARC authentication requirements, that means the senders will send messages from definite hosts or sign the messages with corresponding identity all the time for every message, it is better to put those satisfied senders into “Enforced Peers” list to enable enforced mode, so that the check will be strict, and the spoofed message will be blocked without hesitation.

  

Solve the DMARC violations

After applying the DMARC authentication, the violations will be inevitable, some of them are positive but some of them are false positive, it will be a great work to let the world be clean.

As for those positive violations, there is nothing to be good but take necessary action on them, it is just the effect and aims of DMARC. But as for those false positive violations, they may cause the legitimate messages to be blocked and delayed, affecting the business or order, so it is important to eliminate such violations.

DMARC is to protect senders from impersonation, so the senders should take responsibility to meet the DMARC authentication demand as possible as they can. To not be cheated by the fake sender, the receivers should push their peer sender, especially for those VIP partners to make sure the sending messages are satisfied with DMARC authentication.

DMARC violations may happens in SPF check, the SPF alignment check, the DKIM check, the DKIM alignment and no DMARC DNS record.

To eliminate the SPF check failure, the sender should publish a correct SPF DNS record with all the designated hosts, and send the messages from those hosts only. Of course, if the hosts are changed, adding or removing, the DNS record should be updated.

As for how to create SPF record, here is a guide from internet for reference.

To eliminate the SPF alignment mismatch, the simple way is that the sender should always send the messages with same envelop sender(RFC5321.MailFrom) and header sender(RFC5322.From), at least they are with same organization domain. There is no evident advantage, except cheating the receiver, to send a message with different envelop sender and header sender, especially for those business messages.

Sending via 3rd-party

Now many messages are sent by 3rd-party organizations, but they are also different in the sending behavior. Some of them can use the information for the original sender, such as RFC5321.MailFrom, the SPF alignment will match for such situation; but some of them do not, at least by default, so the sender need to communicate with the 3rd-party organization to try to use the correct information.

Null sender

Null sender is a special scenario for SPF alignment check, there are two possible ways to solve this. One is to sign the message, so that the DMARC will be a Pass result due to DMARC-DKIM side pass. The other one is to correct the Helo domain to be align with header sender (RFC5322.From).

To eliminate the DKIM check failure, the sender should publish a correct DNS record with DKIM public key, and sign the messages with corresponding identity before sending.

As for signing the messages, the signing identity should be the header sender (RFC5322.From) or at least with same organization domain. Otherwise, EMS will not verify such those 3rd-party signatures. Another popular reason for DKIM check failure is that the signature is signed in a future time, the sender server should install NTP or other tools to keep the right time synced to avoid this issue.

As for how to add DKIM public key DNS record, it is different to generate the key for different platforms or providers, here is a guide from EMS online help if customer is using EMS’ DKIM signing feature.

To eliminate the DKIM alignment mismatch, the simple way is that sign the message directly with header sender (RFC5322.From) , at least with same organization domain. Otherwise, EMS will get a None result for DKIM alignment check, which is treated as failure in enforced mode.

Sending via 3rd-party

Messages sent via 3rd-party will get signed in the 3rd-party, the signing behavior is also different. Some of them support sign using the identity same as header sender(RFC5322.From), the DKIM alignment will match for such situation; but some of them do not, at least by default, so the sender need to communicate with the 3rd-party organization to try to use the correct the identity.

No DMARC DNS record

The sender should publish a correct DMARC DNS record, otherwise EMS will get a DMARC failure in enforced mode.

Premium
Internal
Partner
Rating:
Category:
Configure
Solution Id:
000249236
Feedback
Did this article help you?

Thank you for your feedback!

To help us improve the quality of this article, please leave your email here so we can clarify further your feedback, if neccessary:
We will not send you spam or share your email address.

*This form is automated system. General questions, technical, sales, and product-related issues submitted through this form will not be answered.

If you need additional help, you may try to contact the support team. Contact Support

To help us improve the quality of this article, please leave your email here so we can clarify further your feedback, if neccessary:
We will not send you spam or share your email address.

*This form is automated system. General questions, technical, sales, and product-related issues submitted through this form will not be answered.