What is incoming DMARC validation?

When mail is sent to the users who are managed under the mail domain of an organization, the mail typically will pass through the perimeter email security gateway. The email security gateway would perform several checks over the email to validate the legitimacy of the email and if the mail must be delivered to the user or not.

In this validation process, several parameters are checked including the reputation of the IP address, the reputation of the email domain/ID, the presence of SPAM pattern, and other custom rules defined by the administrator of the domain in the filtering gateway.

Among these checks, DMARC is a check which would validate the sender’s authenticity based on the SPF, DKIM, and DMARC. This validation is supported by almost all the major mail gateways. However, it must be manually enabled by the administrator from the gateway console.

Why is DMARC validation required?

There are many ways suspicious mails are identified and blocked and the majority of these filtering technics are static. They work based on reputations and past behavior. However, if the fraudster is hiding behind a domain/server (spoofing) that was not previously identified to be involved in suspicious activity, the mail would easily pass through these filters.

The only way to identify such attacks which are performed by spoofing the identity of legitimate people/domains is through DMARC. Also, DMARC validation is dynamic and decides based on the sending domain owner’s definition of their domain’s legitimate and illegitimate senders.

One more reason to use DMARC validation is its global adoption rate. It is being adopted across countries and industries at a rapid pace and also is being recommended/enforced by regulators and governing bodies across the world.

How should I approach the incoming DMARC configuration?

DMARC is a two-party dependant protocol. This might result in some false positive detections even due to the other party’s configurations. Hence, any organization should take a calculated call when they decide to enable DMARC validation.

ProDMARC recommends a two-stage incoming DMARC deployment that is tested and found success across industries. According to this approach, the email administrator can configure two rules:

1. For the domains owned/managed by the organization: If the administrator is certain about their domain’s DMARC compliance, they can go ahead and configure to block any emails which are received and failing DMARC validation
2. For external domains that are not managed by the organization: In this scenario, the organization can either choose to block the emails that are failing validation or display a strong disclaimer to the users about the mail failing to establish authenticity.

Note: In terms of security, it is recommended to take action based on the sender’s DMARC policy. However, the two-stage deployment is being recommended only from the perspective of ensuring a balance between security and email delivery (to avoid mail interruptions due to misconfigurations of senders)

How do I achieve the two-stage validation?

The mail gateways that would be validating the DMARC would allow only one DMARC configuration and to achieve the two-stage configuration, the administrator should make custom configurations in their gateway (as mentioned below)

1. Enable DMARC validation filter in the gateway and configure it to not take any action. This would make the gateway add a DMARC validation header in the email header but the emails will not be blocked when they fail validation.
2. Configure two custom mail filtering rules in the gateway (one would match when the sending domain is one of the domains owned by the organization and the other would trigger when the sending domain is other than the one owned by the organization) and configure the action according.

Note: The two-stage validation approach mentioned above is just an indicative one and the email administrator shall check with the gateway OEM support for precise configurations. Also, we recommend testing the configured rule among a small set of users before deploying it across your organization.