7 common mistakes people make with DMARC

4.6
7 common mistakes people make with DMARC

The interest in DMARC is increasing exponentially. However, most companies that use DMARC do not reap the full benefits of its anti-spoofing capabilities.

The interest in DMARC is increasing exponentially. However, most companies that use DMARC do not reap the full benefits of its anti-spoofing capabilities. Here's how you can overcome the most frequent DMARC deployment issues.

In our interactions with thousands of potential and customers, we've discovered that, while interest in DMARC is significant, it's simple to encounter issues in configuring it. It is evident that although over 1 million domains have implemented DMARC, only around 16 percent reach the level where the DMARC records safeguard them from the possibility of spoofing (known by the term DMARC enforcement).

Don't fret if you've created a DMARC record but haven't made it to DMARC compliance yet, and it's not your fault. This endeavor can be quite demanding even for the most renowned experts in security for email.

Here are seven mistakes that domain owners commit when configuring DMARC records and configuring the underlying email authentication standards.

Incorrectly interpreting monitoring as protection.

We've come across instances that believe their domain is secured; however, the DMARC record remains the p=none value for several years. The policy p=none put the domain in monitoring mode so that DMARC-compliant receiving gateways will send reports to the domain owner about messages that have passed and did not pass authentication. Mail gateways, however, only transmit information -- they continue to send emails in a normal fashion, even if they do not authenticate. Monitoring is useful and is a necessary initial step in the DMARC process; however, it doesn't do anything to safeguard against the possibility of spoofing.

In"partial enforcement" as a myth, "partial enforcement."

As a default, the DMARC policy is applied to all mail unless a certain percentage is defined using the tag called pct=. If you're at p=quarantine, and you specify a percentage lower than 100, this means that fake messages are still delivered. There's no such thing as "partial" DMARC enforcement. Although there are methods to use percentages, do not fall to the illusion that you're completely protected if your pct= tag indicates anything lower than 100%.

The subdomains are not being remembered.

The default subdomains' default setting is to adhere to the main policy (e.g., p=reject). In the process of reaching DMARC enforcement, Domain owners concentrate on bringing their primary domain into compliance. At the same time, delay the process needed to bring subdomains under enforcement by establishing a subdomain policy which is "sp=none." However, this means that subdomains could still be faked. Phishing emails sent from whatever@example.com won't get through, but whatever@mail.example.com will. To ensure compliance, Subdomains must be secured just as the main domain.

Records that are out of order

We've observed many records that don't use the proper DMARC syntax. For instance, A DMARC record puts the policy such as the p=reject statement behind another one rather than directly after the v=DMARC1 declaration. If these tags are placed in the wrong order could result in problems, causing DMARC authentication to fail or sending mail gateways to miss the DMARC verification completely.

In the absence of a reporting address

One of the most significant features that are a major benefit of DMARC is that it gives domain owners information about the status of their email authentication, such as successes and failures, through the aggregate data reports. Suppose you don't include an address for reporting (via the tag called rua=). It won't receive the information and will learn little about authentication failures or the possibility of identity theft (spoofing) attacks. The reporting address allows users of the DMARC record to define how to report problems.

Records from SPF that are not properly configured

SPF records are a type of DNS record. SPF record is an informational text record published in DNS that includes the IP addresses of senders that are allowed and rules that refer to different types of DNS records, as well as directives that refer to SPF records for other domains. There are many ways to make a mistake with an SPF record. One of the most frequently made errors is to create records that require the recipient domain to conduct over 10 domain lookups for every email it receives. If the domain's SPF record has too many lookups for each email, some or all messages sent from the domain may not be authenticated properly.

To circumvent this limitation within the norm, certain DNS owners "flatten" the SPF record by incorporating all IP addresses belonging to authorized sending services to the main SPF record. The flattened SPF record includes a variety of IP addresses and does not include equivalent DNS lookups. However, this introduces another issue: the requirement to maintain a listed IP address in a flat format to respond if an email-sending service that you're using can add or remove IP addresses.

Miss-managed DKIM Keys

DomainKeys ID Mail (DKIM) uses the public and private keys to sign emails and confirm that the message originated from the domain its DKIM key is linked to and confirms that the message hasn't been altered during its travel.

DKIM keys are a long string of data that appears random and are easily manipulated wrong with DNS. A simple copy-paste error could cause errors, causing legitimate emails to be rejected by DKIM.

Experts also recommend rotating the keys of DKIM at least every six months to stop hackers from stealing or damaging the keys. Many companies have no system to manage and rotate keys, and some even utilize identical DKIM keys for every email service they employ. If one key is compromised, all services are at risk of being attacked.

Mistakes 6 and 7 are the most crucial to rectify since without correctly set up SPF and DKIM, DMARC enforcement will never take place.

DMARC requires that the email message must pass either the SPF or DKIM authentication. It is also required to align (a to match) to the visible address of the email message, and the Return-Path that is within the record of the SPF or that is in the DKIM signature. It would help if you learned the fundamental protocols for email authentication correctly before safeguarding your domain by using DMARC in enforcement.

original source: https://medium.com/@rawatnimisha/7-common-mistakes-people-make-with-dmarc-2618ba4cd7d6