General
Safely delivered email is one of the most important communication tools for organizations and companies. However, because of the large number of spam and phishing attacks, the ability to identify the sender is extremely important. One way of doing this is the usage of common email authentication protocols SPF, DKIM and DMARC.
Different email providers all have their own set of rules that determine which emails are placed in the receiver’s inbox and which belong to junk mail, so the rules are applied on the receiver’s end. Because of this, we highly recommend that all our customers set up these authentication methods to ensure that their emails are delivered and not labelled as junk or blocked by the receiver’s email service. To enable these methods, you need to set up an email address in the system from which your domain name emails will be sent. For more detailed instructions on how to do this, as well as instructions on how to deploy SPF and DKIM, please see Set email sending addresses and authentication methods.
For DMARC in general, see the end of this article. For more information about DNS, check the article What DNS Means.
SPF
The Sender Policy Framework (SPF) verifies that the IP address of the sender matches the list of the domain’s authorized IP addresses. The list of authorized sending hosts for a domain is published in the Domain Name System (DNS) records for that domain. If the IP address matches an authorized sending host address, the email is considered legitimate and is more likely to be delivered to the recipient’s inbox. If the IP address does not match, the email will be either blocked or quarantined (sent to the spam folder).
You can think of SPF as a guest list of a party – if you are on the list, the security guard will let you in (email delivered). If you are not found on the list, you get rejected (block) or you have to wait on the door until the host of the party comes to see if you are allowed to enter (quarantine).
DKIM
DomainKeys Identified Mail (DKIM) is an encrypted private key that is associated with the domain. So, when the email is sent, the key is attached to the email and the receiving server will then compare the key to the public DNS record of the sender’s domain. If the key matches the DNS record, it will confirm that the email is truly sent by the authorized domain and that it has not been tampered with during the process.
DKIM and SPF work together, and DKIM alone cannot be used to make the full verification process. So if for example, you are going to the party mentioned in the SPF metaphor, Your name has to be on the list (SPF) so the security guard can let you in. However, to make sure that it is truly you and someone hasn’t stolen your identity on your way from your home to the party, you have to also give the security guard a secret key (DKIM) that was given to you when you were invited to the party, or you are not allowed to enter. But you can’t just give the guard a key (DKIM) to be let in, you also must provide a name that is on the list (SPF).
DMARC
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is used together with SPF and/or DKIM. DMARC determines the rules on how email should be handled if it fails both SPF and DKIM checks. The options for DMARC are to do nothing (none), send the email to the spam folder (quarantine) or block the email (reject).
So how does the DMARC check that the mail your domain sends is authentic? Let’s imagine that you must check in a hotel (receiver’s inbox) using two forms of ID, so you give the receptionist (receiving server) your ID card (SPF) and your passport (DKIM). You get in if both of your IDs are valid and match who you say you are and what the receptionist can see on their records (DNS). So, in the case of the email, it will be successfully delivered.
If both IDs fail the check, security (DMARC) will take the appropriate action determined by the DMARC rules determined in the DNS. You have a chance to get in (DMARC none) but your entry might also be denied (DMARC reject). Or they might take you to a separate room for questioning (DMARC quarantine).
Because the security in the hotel is tight, one valid form of ID is not enough. So, if your passport is valid but your ID card is not, you will not be able to get in and DMARC rules will be enforced. If both of your forms of ID are valid but do not give the same information, like another says that you are Mr. Smith and another says that you are Mr. Blacksmith, DMARC rules will be enforced.
As of February 2024, the DMARC has been added as a requirement to email providers like Google and Yahoo. This is why we highly recommend our customers set up a DMARC to ensure the delivery of emails they send. However, this is something that has to be done on the management side of your domain host, which means that CRM-service is not able to set this up for you. It has to be done by your IT department or company that is hosting your domain, depending on how your website is set up because the DNS file of your domain has to be modified to set up the DMARC.
The information below is just an example; you will need to set up DMARC to match your domain information and the functionality you want. DMARC is very domain-specific, so all the information in the example is for demonstration purposes only, and parts like yourcompany.com need to be replaced with your company information for DMARC to work.
Like DKIM and DMARC, there is however a certain format that DMARC must follow. The following is an example of what parts DMARC record has, just replace parentheses and their contents with the information of your organisation:
_dmarc.(insert domain name here)
v=DMARC1; p=none; rua=mailto:(insert email here);
In the example _dmarc is at the beginning of the DNS hostname, followed by the domain, which is the part where the domain of your website where policy will be added. This part is always required because it is the name of the TXT Record.
Another constant in the DMARC Record is v=DMARC1; – this part indicates that the DNS has a DMARC policy, and this tag is always required. Another required part is p=, which in this example is p=none. This tells DMARC what to do if mail fails the SPF and DKIM checks. In this part p=none means that mail will still go through, p=quarantine marks the mail as spam and p=reject blocks the message. We recommend p=quarantine since it stops unwanted messages by placing them in the spam folder, but the receiver can recover mistakenly placed emails from their spam folder manually if necessary.
Part rua=mailto:(insert your email here) is optional, but we recommend this because it helps troubleshoot if the emails for some reason do not reach their destination or end up in the spam folder. Here rua= tells that you want to receive reports, and it is followed by mailto: and email address where you want the reports. However, this might result in a very high volume of report emails, and for this reason, we recommend that you create an email address dedicated to DMARC records or use the email address that is used to handle large amounts of other automated emails.
In any case, it is never recommended to use your personal email or any other email used for communication here, because large amounts of report emails might result in your inbox filling up and prevent you from sending and receiving emails.
Other optional tags can be used in DMARC if you like, but we are not covering them here because we only want to show you a basic example and not overcomplicate this part.