DMARC or Domain-based Message Authentication, Reporting, and Conformance safeguards an organization's trusted domains from email spoofing. Given the rapid expansion of email fraud and the fact that domain spoofing attacks account for a significant portion of these attacks, it's no wonder that many firms are eager to use DMARC authentication to examine emails sent on their behalf. In fact, the Department of Homeland Security recently mandated that all civilian government agencies implement DMARC within a short timeframe, and encouraged private businesses to do the same.

Many firms have not yet implemented DMARC since it is difficult to establish. If configured incorrectly, DMARC could end up blocking genuine emails. To further assist businesses and government organizations in protecting their trusted domains, we've identified seven common DMARC authentication mistakes companies make.

Many senders send emails on behalf of other businesses, including third-party recipients. It may be difficult to identify all authentic senders especially when many departments within a company such as marketing, sales, and human resources use third-party email senders. If all valid senders are not located and permitted to send an email on behalf of the firm, essential communications may be disallowed, causing a business interruption. Stakeholders from all linked agencies should be consulted and involved.

DMARC deployment is frequently focused at the top-level domains (for example, acme.com), and enterprises may overlook the significance of creating proper policies for each of their subdomains (ex: mail.acme.com) too. Subdomains are automatically subject to the DMARC policy that is applied to the top-level domain. If not all subdomains are correctly accounted for, this may result in the unintentional blocking of legitimate emails.

DMARC aggregate reports from receiving email service providers give important information about your email environment, but they are difficult to understand. Unless and until you can arrange data in a way that provides value, it is just data. Furthermore, keeping up with the sheer volume of reports received and compiling all of the data in a usable manner may be tough, especially if the firm is attempting to set a deadline for its DMARC implementation plan.

By matching the header 'from' domain name with the 'MFROM' domain name used during an SPF check, as well as the 'd=domain name' in the DKIM signature, DMARC alignment protects the header 'from' address against spoofing. Alignment ensures that your transmitting identity is validated in connection to the domain to which it is intended to belong. Third-party email senders, once again, complicate matters. Third-party service providers, for example, typically have their own 'MFROM' domain. As a result, SPF is passed but not SPF alignment. Third-party vendors, meanwhile, pass DKIM but not DKIM alignment.

While there are criteria for constructing DMARC data, they might be difficult to understand at times. Inappropriate policy values, as well as improper layout and/or content, are also common. Keep the following in mind to avoid DMARC issues.
Remember to add '_dmarc' in your code.
If you have more than one reporting address, use a comma to separate them (no space after the comma). Ensure that the second address begins with 'MailTo.'
Use the appropriate policy values (for example, 'none' instead of 'monitor').
Check for missing or additional characters that aren't meant to be there.

We frequently see firms deploy DMARC and then immediately switch to a ‘Reject’ policy. Going straight to a ‘Reject’ policy is a typical mistake since it will almost surely result in the loss of genuine emails. We recommend installing DMARC policies in stages. Begin by monitoring your traffic and looking for irregularities in your files, such as unsigned messages or evidence of spying. Adjust your dmarc ‘quarantine’ technique to modest degrees until you're pleased with the results. Keep a watch on the findings once more, this time in both your spam capture and your DMARC files. Change your policy to 'Reject' until you are confident that all your communications have been signed. Keep an eye on all reviews to ensure that the outcomes are satisfactory.

The SPF record is a text record published in DNS that comprises a list of IP addresses of approved senders, rules referring to other types of DNS records, and directives that reference SPF records from other domains. While there are several ways to create an SPF record incorrectly, one of the most prevalent errors is creating a record that needs the receiving domain to perform more than ten domain lookups for each message it receives. If a domain's SPF record needs too many lookups, some or all emails sent from that domain may fail to authenticate.

To get around this limitation in the SPF standard, some domain owners ‘flatten’ their SPF record by bringing all the IP addresses of allowed sending services forward into the primary SPF record. Rather than including similar DNS lookups, a flattened SPF record clearly identifies a number of IP addresses.

Avoid these seven mistakes while implementing DMARC to keep hackers and spoofers at bay without compromising on email deliverability. If you already have a DMARC record implemented, use EmailAuth’s free DMARC checkup tool to verify it.

Original source: https://www.evernote.com/shard/s333/sh/ab024d04-bbf2-3bbe-4194-7b4f...