Implementing DMARC to protect your corporate domain from spoofing

A Thief on the Run by Manweri

Hi, Habr! In this post we will again talk about the problem of the fake sender (or the so-called spoofing). Recently, such cases have become very frequent: everything is forged: letters with bills for housing and communal services, from the tax inspectorate, banks, and so on. Configuring a strict DMARC policy helps solve this problem. We, as a postal service, check all incoming letters to DMARC since February 2013. We were the first mail service in runet that supported the DMARC standards. However, to minimize the number of fake letters, this, unfortunately, is not enough. The main thing is that strict DMARC is supported on the sender's side. That is why we do not get tired to download this topic, we are actively engaged in explanatory work and strongly urge everyone to include strict DMARC.

Positive shifts are already there: every month we see a 10 percent increase in the number of corporate senders who have registered DMARC. However, of course, there is still something to work on. Practice shows that IT culture is at a very different level. Someone heard vaguely about DMARC, but is not going to introduce it yet. There are those for whom the fact that there is no verification and protection of the sender's address in the transport protocols of e-mail is still a real revelation. In addition, support for DMARC is not an easy task. Only at first glance it seems that it is enough to publish the record in the DNS, and no additional software or hardware is required (for more details, see our DMARC article : protect your mailing from fakes ). In practice, in a large company with numerous e-mail flows and a spreading structure of e-mail domains, everything is much more complicated. And there are moments that should be foreseen and thought out in advance. For such difficult cases, we wrote this article, trying to collect all the nuances in it.

We want to share our own experience of implementing DMARC and all the rakes we stepped on (crossed out) with the recommendations that we developed in cooperation with large companies and government agencies. We will consider only the implementation of the DMARC policy to protect a domain name. Implementing the server part of DMARC to protect corporate mail server users from fake emails is a separate, completely independent and independent process.
')
DMARC is a policy of actions with incoming letters that have a policy publishing domain in the From field. DMARC allows you not only to specify how to deal with such letters, but also to collect statistics from all recipients who support the server part of DMARC.

The main problem is that DMARC requires the authorization of all legitimate emails. And for this, it is necessary not only to implement authorization methods (SPF and DKIM are used as basic protocols), but also to ensure that for all legitimate emails with return addresses of the domain to pass, the authorization takes place. Therefore, the introduction of DMARC should begin with the following paragraph.

1. Audit legitimate emails from your domain and its subdomains

Typical omissions in this process:

• commercial letters sent through external mailing service providers;
• internal mailing lists;
• redirection of mail from user boxes;
• technological letters generated by servers and equipment;
• delivery reports (DSN) or undeliverable (NDR) letters.

For each category of letters, it is necessary to implement SPF and find out whether it is possible or impossible to sign letters using DKIM.

2. Implement SPF for the main domain and its subdomains

You can often hear that SPF protects the sender's address from being fake. This is not true. SPF only controls the address of the SMTP envelope that the user does not see. However, a large number of domains have not yet implemented it, and many parties do not support SPF-compatible mail forwarding. For this reason, neutral SPF (neutral ? ) Or soft blocking (soft reject, ~ ) is most often used. For sharing with DMARC, it does not matter which default policy (neutral ? Soft reject ~ or reject - ) SPF will be used. We do not recommend using the reject ( - ) policy with the exception of highly security-sensitive domains, as this may adversely affect the delivery of legitimate emails in indirect ways, such as through mailing lists or mailing lists. Although most recipients do not block SPF emails even when they publish strict policies, they use SPFs as part of weight classifiers. Contrary to popular belief, it is this SPF regime that is most often used in practice, and it fully complies with the recommendations of the standard.

You can make the following recommendations for the implementation of SPF:

• Do not forget that SPF is checked for the domain from the envelope-from address (it is MAIL FROM and Return-Path). In order for SPF to be used to authenticate the sender of the message, the domain in the envelope-from must match the domain of the From header with an accuracy of the organizational domain (that is, the second level domain in .ru or .com). Using invalid addresses for envelope-from is one of the most common server configuration errors, CMS and server-side scripts.
  
  
• In SMTP, some categories of letters ( NDR , DSN ) have an empty envelope-from address. For such letters, authentication is performed on the domain that the sender's SMTP server uses in the HELO / EHLO command and which, as a rule, is the same as the canonical server name. Incorrect names in the HELO command is another common problem. Make sure that the domain name in HELO is correct, and list the appropriate SPF policy for it, for example, mailserver.example.org. TXT "v=spf1 a -all" mailserver.example.org. TXT "v=spf1 a -all" . In messages about the impossibility of delivery in the sender's address, you can either not specify the domain at all (for example, From: mailer-daemon:; ) or use a domain that matches the HELO domain with an accuracy of the organization's domain (usually a second-level domain, for example, From: mailer-daemon@example.org ).
  
  
• Do not forget that SPF does not affect subdomains. You need to implement it for each subdomain or resort to wildcards DNS .
  
  
• SPF has a limit of 10 name permissions per record. Therefore, you should minimize the use of elements that lead to additional permissions, such as mx and include . For example, for the mx element, one additional request is required to receive the MX record itself and one request for each server in the MX record to obtain its IP address by name.

3. Publish a DMARC record with a policy of none for the main domain and subdomains.

An example of such a record:

 _dmarc.example.com. TXT "v=DMARC1;p=none;rua=mailto:rua@example.com;ruf=mailto:ruf@example.com;fo=s" 

The record instructs the recipient to send daily statistical reports to rua@example.com . From the reports you will see all the IP addresses from which mailings were sent from your domain name, and the authorization status of SPF, DKIM and DMARC for these letters. Especially carefully follow the letters from your IP-addresses. Check the reports to see if you have missed any categories of letters or their sources in your audit. Adjust the SPF if necessary. Some recipients may send reports on individual cases of problems with SPF ( fo=s ) to the address ruf , these reports will be useful for identifying problem mailings.

Typical problems and recommendations:

• We do not recommend publishing a policy even with the none tag until at least one of the SPF or DKIM authentication mechanisms is implemented for the main mail flows.
• The entry must begin with v = DMARC1, and the case of letters matters.
• Some DNS clients show back slashes before the semicolon v=DMARC1\;p=none - but you don’t usually need to add a backslash in the records of the DNS zone.
• The rua / ruf addresses must belong to the same organizational domain for which the policy is published, or the receiving domain must publish a special policy showing consent to receive reports. It will not be possible to accept reports to addresses, for example, public mails.
• If you have not completed the implementation of DKIM, then you will receive quite a lot of DMARC violations from public mail IP addresses (Mail.Ru, Gmail, Hotmail / Outlook, Yahoo, etc.). This is due to the fact that users of these services often use redirections to other mailboxes, and this leads to a violation of SPF authentication. The problem is solved by the introduction of the DKIM signature.
• There are some good tools for visualizing DMARC reports. Dmarcian provides both free and paid (for small volumes of mail) services, and a convenient and convenient free XML-To-Human Converter tool for viewing DMARC reports. Agari and proofpoint also offer commercial services for implementing and maintaining DMARC.

4. Implement DKIM

Recommendations:

• Make sure that the letters generated by the servers comply with the recommendations on the structure, encodings and number of headers, otherwise it is possible that when transmitted by the mail relay the letter will be changed to bring it into compliance with the standards (most often breakdown of long strings occurs), which causes the DKIM signature to be broken.
• Use a key with a length of 1024 or 2048 bits.
• Make sure your DNS server supports resolution of large records. Usually, in addition to access to the server via UDP / 53, it is necessary to additionally allow access via TCP / 53. Make sure that the TXT record with the DKIM key is correctly resolved from external networks.
• Use the relaxed / relaxed canonization mode, it is less likely to cause problems with the normalization of the letter during transmission.
• Do not sign headers that change upon message delivery (such as Received: and Return-Path :), make sure that mandatory headers (Date :, Message-ID :, From :) are formed before applying DKIM signatures
• Implement DKIM on all sources of letters for all subdomains.
• Use separate selectors with separate keys for external sources (mail sending service providers) so that you can revoke the key if necessary.
• For DMARC, it is necessary that the domain used in the DKIM signature matches up to the organizational domain with the domain from the From header. Other DKIM signatures may be present, but they will be ignored.
• Monitor the implementation of DKIM from statistical reports from external services.
• Use fo=1 in the DMARC policy, this will allow you to receive forensic reports on all problems with SPF and DKIM, even for letters that are authorized by DMARC.

5. Start switching to strict policies.

Do not use the quarantine policy for a long time, as it may mask the existing problems. You are guaranteed to learn about the existence of problems only from aggregated reports, which may take more than a day to get.

You can start by turning on the reject policy at 10% ( p=reject; pct=10 ) to track potential problems with delivery errors. But it is not recommended to keep such a policy for a long time: the quarantine policy will be applied for the remaining 90% of the operations, and you can skip isolated problems

Be sure to follow the server logs and reports about the inability to deliver letters for errors related to DMARC. The standard recommends that recipients implementing the server part of DMARC be sure to include it as the cause in the error message, so you can use “DMARC” as the key word in the error message to identify the problem. According to the server logs, you will see the problem much earlier than the reports and you will know exactly which addresses which emails were not delivered.

You can implement a policy that is different from the policy of the main domain on separate subdomains by publishing separate policies for them or specifying the policy of the main domain ( p=none; sp=reject ): the sp policy will affect subdomains that do not publish their own policies.

When all subdomains are transferred to a strict policy, you can remove the policy of subdomains - or leave, at your discretion. This only affects the generation of reports in accordance with established practice (in the standard, this point is not negotiated). If a subdomain publishes its policy, separate reports will come to it; if there is no separate policy, then reports on the subdomain will be included in the report of the parent domain.

6. Tuning DMARC policy

Below is an analysis of some optional DMARC entry fields, examples and recommendations for their use.

p ( p=reject ) - DMARC policy. Tells the recipient how to deal with unauthenticated emails. It can be none (deliver letters to the recipient), quarantine (deliver letters to the Spam folder) and reject (not accept letters).

sp ( sp=quarantine ) is a policy for subdomains that do not publish independent policies. If the subdomain has its own DMARC policy, then sp does not affect it. If there is no sp field in the DMARC entry for subdomains that do not have their own policy, the policy from the p field is applied.

pct ( pct=20 ) - the percentage of emails that this policy applies to. For example, if you set a reject policy with pct=20 reject policy will be applied to the received letter with a probability of 20% and a quarantine policy with a probability of 80%.

rua ( rua=mailto:ruamailbox@example.com ) - the address to which recipients will send an aggregated (statistical) report. The address must belong to the same organizational domain. We recommend that you always publish an address for aggregated reports and monitor them at least during the implementation phase of the DMARC policy.

ruf ( ruf=mailto:rufmailbox@example.com ) is the address to which forensic reports (that is, research reports) will be sent by individual letters. By default, forensic reports are sent only for DMARC violations. You can use the fo option to regulate behavior. Currently, a relatively small number of recipients send forensic reports.

fo ( fo=1 ) - for what violations to send notifications. fo=0 (default behavior) sends reports only when both authentication fails: SPF and DKIM. fo=1 - when any of the authentication fails, even if an alternative method passes. fo=s sends forensic reports on problems with SPF authentication. fo=d - for DKIM problems.

adkim ( adkim=r ) - mode for checking compliance with the DKIM domain. The default mode is r (relaxed) and only the organizational domain should match. In strict ( s ) mode, a complete match of the domain from the sender's address to the domain from the DKIM signature is required. It makes sense to use strict domain matching, if part of your subdomains are delegated to untrusted parties.

aspf ( aspf=r ) - similarly for the domain from envelope-from, for which SPF and From is checked. For aspf=s these domains must be exactly the same in order to pass SPF authentication.

ri ( ri=86400 ) - the desired interval for receiving aggregated reports (in seconds). By default, reports are sent once a day, but some recipients (not all, because the server does not support this parameter) support sending reports at shorter intervals. At the stage of policy implementation, you can try using smaller ri, for example ri=3600 .

We are very pleased that domain owners have begun to think about protecting their domain name in electronic correspondence. Help on setting up DMARC is available here . If you have questions or need advice or help with setting up SPF, DKIM, DMARC, contact dmarc_support@corp.mail.ru or ask a question here. We hope that together we can make email safer for all users.