The Ultimate Guide – DMARC DKIM SPF
How To Implement DMARC/DKIM/SPF To Stop Business Email Compromise
In this ultimate guide, you’ll learn how to implement DMARC, DKIM, and SPF to protect against business email compromise (BEC) and improve email delivery. We’ll suggest the best practices to set up these email authentication protocols and clear up any confusion you may have about DMARC, DKIM, and SPF.
Also, we’ll discuss the benefits of implementing DMARC, DKIM, and SPF, such as halting email phishing or spoofing attacks from your domain and improving your reputation as an email sender.
This guide is beneficial for the following audiences:
- Brand owners;
- Domain owners and administrators;
- IT networks;
- Anyone who wants to stop cybercriminals from sending fraudulent emails from their domain;
- Those who have been affected by BEC.
Note: if you would like to determine if your domain is compliant with DMARC, SPF, and DKIM policies, then send an email to INSERT EMAIL HERE. We will send a report to your inbox with the requested information.
What is Business Email Compromise?
Business email compromise (BEC) refers to any type of fraudulent activity involving your email domain. Common examples include phishing or spoofing attacks, which occur when an email header is forged and someone else sends an email on behalf of you. Phishing occurs when a fraudulent website or email is deployed in an attempt to steal your information. These emails appear to have originated from you, but they are instead sent by a cybercriminal. The goal of these attacks is usually to obtain sensitive information, such as the recipient’s financial details or passwords.
These types of emails usually contain a message indicating that there has been a security breach and the recipient must take immediate action to remedy the problem. The “from” address might appear to be from a reputable source, such as [email protected]. This prompts the recipient to click on the link provided in the email and is taken to a fraudulent website that looks like the bank’s official site. From here, recipients mistakenly enter their personal information and the website uses these credentials to withdraw money from the recipient’s account.
Spoofed emails could also look like they come from your business partner. These types of emails may include an invoice that your partner wants you to pay. Again, the recipient clicks on a link and it is taken to a false website that steals the recipient’s financial information. Phishing emails are common among money wire transfers as this is an easy way for attackers to get their hands on your money.
Here’s another scenario. A cybercriminal may pretend to be someone from senior management sending out emails to their staff, including accounting managers. They may claim that they need you to wire transfer money to another account (usually overseas) to one of their business investors. An employee may make the mistake of transferring the company’s funds to the cybercriminal as the email appears to be legitimately from management.
Here is an example of a spoofed email:
INSERT EXAMPLE HERE
In this email, the cyber criminal is impersonating Google and warns the user of a suspicious login attempt. The email then asks the recipient to confirm by clicking on the link, which allows the attacker to steal their credentials. Spoofing emails may also be deployed in an attempt to spread ransomware. Opening one of these emails can seize an entire business operation.
Again, these emails always appear to come from trusted sources. Once the recipient opens the email, he may be asked to click on a link or download attachments. The ransomware then takes over the device and locks everyone in the business out. The hacker may demand money before releasing your account. One report indicated that approximately 90% of all phishing emails have attached ransomware.
- Business email compromise (BEC) may include email phishing or spoofing, which occurs when someone impersonates an email that looks legitimate and tricks the recipient to transfer money, give up important information, or download ransomware;
- Cybercriminals can use your email to send fraudulent emails to customers, employees, and business partners even if you are not aware of it.
What Are The Consequences of BEC?
One of the primary reasons why BEC is so common is because it’s fairly easy to do. It doesn’t require an extensive technology background. Anyone with basic administrative email server skills can do it, and it has a high ROI. Today, many companies rely on spam filtering to prevent these attacks. However, spam filters do not always stop certain phishing attacks and many emails can pass a spam filter undetected. Spam filters aren’t designed to stop spoofing. You will need another mechanism to stop phishing attacks from reaching your recipients.
When a phishing email reaches your inbox, it jeopardizes many things, such as your business or brand reputation. Other risk factors include stolen intellectual property, financial loss, suspension of business activity due to ransomware holding up your company, and more.
Email is crucial for any business operation. It’s the primary way that most businesses communicate. However, email is also responsible for marketing, customer service support, sales, internal communication, and financial data transfers. Therefore, it’s imperative that business email is secure. Failing to secure your business email can lead to security breaches that cause severe losses. It’s like keeping a safe full of money and personal information unlocked for anyone to steal or opening a corporate bank account without a password.
- BEC causes irreversible consequences to your business and reputation, including ransomware that seizes your account, financial loss, and stolen intellectual property.
How To Stop Business Email Compromise?
Although email spoofing and phishing attacks might seem scary, the good news is that you can prevent many of these attempted attacks by implementing DMARC, SPF, and DKIM. These modern email security measures are the gold standard when it comes to email authentication, as long as they are implemented correctly.
When implemented correctly, DMARC, SPF, and DKIM work together by publishing DNS records to secure the domain. Together, these systems work with email service providers, such as Gmail, and prevent unauthorized attacks from delivering fraudulent messages from your domain. This guide will highlight what DMARC, SPF, and DKIM are, how they work together and on their own, and, most importantly, how they protect your domain against BEC.
- Setting up DMARC, DKIM, and SPF properly is the best way to protect your domain against BEC and stop hackers from sending fraudulent emails
Do I Really Need DMARC, SPF, and DKIM?
The short answer is yes! You absolutely need DMARC, SPF, and DKIM if you are serious about protecting your business and sensitive information. Even if your business has been lucky enough not to be impacted by email phishing or spoofing, there are many instant benefits of implementing DMARC, DKIM, and SPF, including the following:
- Recently, Microsoft Office 365 adjusted its anti-spoofing policy so that authenticated emails go to your spam folder automatically. This means that if you do not have DMARC, DKIM, or SPF installed, emails that come from your domain may not end up in the inbox. A warning such as this one may pop up:
INSERT WARNING HERE
- Gmail uses the following red question mark to indicate when an email is unauthenticated, which creates a sense of insecurity and distrust:
- Research shows that implementing a p=reject DMARC policy can boost your email deliverability by as much as 10%, which means that more of your emails will reach the inbox. Remember that DMARC, DKIM, and SPF work together to protect your domain from BEC.
Another reason why implementing DMARC is absolutely necessary is because it improves your email deliverability. Many people assume that all of their legitimate emails are delivered to the inbox. However, this is not always true. Legitimate emails may not reach the inbox for several reasons, which may include the following:
- SPF or DKIM updates in your DNS, including those from third parties;
- New third-party email domains are added;
- The SPF record goes over the 10 DNS lookup limit;
- And many more!
Emails that are unauthenticated are usually treated as spam or rejected entirely, which means that your perfectly legitimate email might not make it to the inbox at all. You can prevent this from happening by keeping an eye on your legitimate emails and making sure they are properly authenticated. Enabling DMARC helps with this. However, neglecting to monitor your DMARC policy may also cause some legitimate emails to be rejected, too.
Real-Life Business Email Compromise Example
What’s an example of a real-life business email compromise? Let us show you. Every time your company communicates with someone else, like a customer or employee, it’s very likely that you have outsourced to a third party. If not, it’s a good idea to do this because you will get better deliverability and anti-spam features.
When you send a business email to someone using a third-party service, here is what happens:
- The third-party delivery service is contacted with directions such as email address, message body, subject, and attachments
- Once the third party receives all the information it needs, it initiates a simple mail transfer protocol (SMTP) session (which occurs when messages are sent between computers) with a server hosted by the recipient’s email service provider (such as Yahoo or Gmail)
- Next, the email service provider looks over the incoming email, determines the domain, looks up the DMARC, SPF, and DKIM records from the sender’s domain, and puts it through a series of authentication checks
- Once the results are obtained, the email will either be sent to the inbox, spam folder or rejected altogether.
An easy way to understand the email protocol is to think of it as snail mail. Both forms of message delivery have similarities when it comes to destruction and anatomy. The following is an image that shows the differences and similarities between regular mail (from a letter) and email:
As shown in the image, postal mail contains an envelope and a letter. Each has its own “to” and “from” or sender and recipient. Most of the time, this information is the same, but sometimes it’s different. Additionally, the email message also contains a “to” and “from”.
The message part of an email is a letter itself and the envelope contains the directions that are issued in the SMTP conversation between two computers. Both the letter and the envelope of the email have their own “to” and “from” information. However, the information in the message might be different from what’s on the envelope.
Adding the sender to the letter and the envelope is necessary for proper SMTP functioning. However, because these can be different, it makes spoofing attacks possible. An email moves through several processes when it gets sent, just like postal mail does. For example, here is the chain that snail mail moves through:
- Sender sends a letter through post office or mailbox;
- Local post office picks up the letter and places it in a distribution center;
- The letter is sent to the destination post office;
- Finally, it reaches the recipient.
Similarly, an email moves through several servers on the internet before reaching its final destination. We’ll discuss this later when we talk about an email header.
What Happens During SMTP Transactions?
The following is a real-life example of an SMTP transaction, which occurs between a sending and a receiving server. For this example, we will be connecting to one of Gmail’s servers to start. Then we will issue a few SMTP rules as an example to send an email. Here is the transaction:
Connected to alt2.gmail-smtp-in.l.google.com.
Escape character is ‘^]’.
220 mx.google.com ESMTP p7si628819iom.85 – gsmtp
250 mx.google.com at your service
mail from: <[email protected]>
250 2.1.0 OK p7si628819iom.85 – gsmtp
rcpt to: <[email protected]>
250 2.1.5 OK p7si628819iom.85 – gsmtp
354 Go ahead p7si628819iom.85 – gsmtp
From: Doug <[email protected]>
Reply-to: <[email protected]>
This is an example.
.250 2.0.0 wDSAAusO0109812 Message accepted for delivery
Here is a breakdown of the above example and what each line means:
- First, the sending host issues a command (in this case, “hello”) to identify itself. This is the same thing as saying, “Hi, my name is … “
- Then, the host initiates the email transfer and identifies the sender by issuing the mail from the command. The address in this example is called the “envelope from.” It tells the mail server where to bounce back to if the message cannot be delivered for whatever reason. This may occur if the email address cannot be found. Similarly, it’s like a return address that you put on an envelope when you mail a letter. If the address that you are sending the letter to isn’t found, then you will receive the letter at the return address with “return to sender” stamped on the front.
- Next, the recipient is specified. This command might be repeated several times if there are multiple email recipients listed on the outgoing email.
- Finally, the message starts to send the email. The domain accepts all of the data in a command until it sees a period or a dot followed by a blank line. You can use this command to specify many end users. Here is what this line means:
“From” – this header is from an address. It appears as the email sender when you email a client. If this is left out, then it will be the same address as the envelope. In this example, the recipient is [email protected].
“Reply to” – this is an optional header in which you can send direct replies to
“Subject” – this line indicates the topic of the email
The rest of the text is the message body, or the actual message itself.
Email authentication does not usually check the email message. DMARC is mostly concerned with the header field and SMTP commands as these are what are most commonly hacked.
What Is An Email Message?
An email message is made up of a header (which can contain several fields) and a body. The header is where the information is entered that tracks the origin of the email. It’s also where the authenticity is checked. The body is where the message itself goes. DMARC focuses on protecting your email header because this information is needed to verify your domain.
If you use Gmail as your email provider, then you can use the “show original” feature to dissect the makings of your email message. When you analyze an email header, it’s important to keep in mind that the orders of events start at the top. So, if you want to trace the email from the time it’s sent to the time it’s received, you will want to start at the bottom. An email goes through several servers while on its journey, and each pit-stop might add more information to the header.
Here is a breakdown of the different stops an email may take after you send it:
- Stop one: the first “stop” isn’t really a stop at all. It occurs when you compose the email from your computer.
- Stop two: during the second “stop,” your email delivery service receives the email and prepares to send it.
- Stop three: during stop three, the recipient email server receives the email. This is where the recipient SMTP gets the email messages, authenticates them, and adds the appropriate authentication fields to the header.
- Final stop: the final stop occurs when the email message is delivered.
What’s The Difference Between An “Envelope From” and a “Header From?”
Every email contains two different “from” addresses. The first is the “envelope from” and the other is the “header from.” The email address specified by the mail from command in an SMTP transaction is the envelope from. It’s also known as the bounce back address, Mail From, RFC5321, reverse path, return path, return address, envelope sender, and more.
The header from address is the address in the “from” header area when you compose an email. It’s also known as the display from, from, RFC5322, and more. The header from address is what you see when you email someone. Also, the header from address is what email recipients see when they want to determine who sent the email.
Here is an example:
As you can see, the envelope from address is part of the SMTP transaction, and the header from address is part of the email’s message. Most people would think that the envelope from address and the header are always the same. However, this is not always true. Sometimes, like when an email is forwarded, they can be different.
For example, let’s say someone named Joe sends an email with the same envelope from and header from addresses ([email protected]) to a customer at [email protected]. The email server at help.com has a rule set up in its policies that forwards all messages to another email address of [email protected].
When the email arrives at the first server (@help), it will be connected to the second server (@outsourcedhelp) where the message will be delivered. In the process, the envelope from address becomes different than the original one, while keeping the message itself the same (including the header from address).
The purpose of this is – Joe can always see the original content that was sent. However, the final message will contain a different envelope from address since the two servers contain different addresses. Cybercriminals can change the envelope from header to send a spoofed email from your domain. We’ll discuss how this works later on.
What Is SPF?
Sender Policy Framework, or SPF, is the first of the three modern email authentication processes. SPF is an email authentication protocol that only allows authorized senders to send emails on behalf of a domain. All unauthorized users will not be able to send an email from that domain. SPF also allows receiving email servers to check any email that comes in from a domain to make sure that it matches its IP address from that domain to ensure that it’s authorized.
How Does SPF Work?
To understand how SPF works, it’s a good idea to use an example. Let’s say that your business email domain is company.com. The email domain from which you will send emails to your customers and employees is [email protected]. Your email delivery server (the service that you use to send emails) has an IP address of 192.168.02. A cybercriminal uses a fraudulent email with an IP address of 184.108.40.206 to try to send an email from your domain.
When your email delivery service (Gmail, Yahoo, etc.) connects your email to the recipient’s domain, several things happen. First, the email server takes some of the domain names from the envelope from address. In this case, it’s company.com. Next, the email server looks at the host’s IP address to determine if the domain is published in the SPF records. The SPF check will pass if the IP address is listed. The check will fail if the IP address is not listed.
For example, your SPF record contains the following: v=spf ip3:220.127.116.11 -all. This means that IP addresses that contain 18.104.22.168 will pass the SPF check. All other emails from any other IP address will not pass. This means that emails from servers at IP address 22.214.171.124 will not be accepted.
It helps to think of SPF records as a list of secure IP addresses that are allowed into an exclusive club. Only IP addresses from this list will be given the green light to make it through to the inbox. SPF records also ensure that no other hosts can send an email from your domain. This process is one of the first steps used for DMARC authentication, which we will describe later.
For example, if you use Gmail as your email delivery service, then you can check to see whether an email passes or fails an SPF check by logging into your account, clicking on the message, and use the “show original” feature. This will show you all details of the message.
How To Create An SPF Record?
An SPF record allows domain owners to use specific IP addresses in a unique way by providing qualifiers, modifiers, and mechanisms. For example, in the example v=spf1 ip4:126.96.36.199 – all, here is what each section means:
- v=spf1 refers to the version of SPF that you are using. Right now, SPF1 is the current version
- Everything that follows the SPF1 refers to a bunch of qualifiers, modifiers, and mechanisms that determine whether the host is allowed to send emails
- The ip4 refers to an IPv4 address that is allowed to send emails from that domain. In this example, the IP address of 190.168.01 is a qualified domain that can send emails
- The -all mechanism refers to the domain’s settings. In this case, if none of the mechanisms listed before this matches the SPF record, then the check will fail.
What Do SPF Mechanisms Mean?
There are eight total SPF mechanisms, which refer to a specific way to identify an IP address. We’ve listed out their meanings below:
- IP4: this indicates that the SPF record will match if the sender is in an IPv4 range
- IP6: the SPF record will match if the domain user is sending from an IPv6 range
- A: domain addresses that have an A or AAAA can be matched to the sender’s address
- MX: domain addresses that have an MX record will be a match (for example, if the email comes from one of the domain’s incoming servers)
- PTR: if the domain’s PTR record for your address is in the given domain and this domain defaults to your address, then it will be a match. It should be noted that this mechanism should no longer be used as it is depreciated.
- EXISTS: this mechanism is rarely used because it contains complex matches. It refers to domain names that match any address, no matter the address.
- INCLUDE: this refers to another domain’s policy. If the other policy domain passes the check, then this mechanism passes. However, if the policy fails, then processing will continue. The redirect extension must be used to completely delegate another domain’s policy.
- ALL: this refers to always a match and is used for default, such as -all for all IPs that are not matched by other mechanisms.
What Are SPF Qualifiers?
An SPF qualifier determines the result of the mechanism evaluation. Every SPF qualifier is combined with any of the above mechanisms.
Here is a breakdown of SPF qualifiers:
- + means that SPF checks pass; it can be omitted;
- ? is a neutral result that can be defined as NONE or no policy;
- ~ (tilde) refers to soft fail, which is an aid that falls between neutral and fail. Messages that are tagged with a soft fail are accepted but flagged;
- – refers to fail; in other words, the SPF check fails.
What Are SPF Modifiers?
There are two SPF modifiers that are widely used.
- Exp=any.example.com – this gives us the domain of the domain along with a DNS TXT record and provides an explanation for failed checks. This type of modifier is rarely used;
- Redirect-any.example.com – this modifier is used instead of the ‘all’ mechanism. It links to the policy of another domain.
SPF modifiers allow the framework to contain extensions in the future. Redirect modifiers work differently. For example, ‘include’ is a mechanism and if it fails, the next mechanism in the SPF record is checked. Additionally, ‘redirect’ is a modifier that relies on the SPF record’s evaluation to determine its influence over the results.
Example of an SPF Record
Here is a generic example of an SPF record to help you understand how SPF works. You can adjust this as needed:
v=spf1 a mx include:_spf.record.com – all
In this example, the following IP addresses are allowed to send emails on behalf of your domain:
- If the domain address has an address record of A or AAAA that is resolved, then the resolved value is allowed (which is the a mechanism)
- If the domain has a record of mx that can be resolved, then the resolved value is allowed (which is the mx mechanism)
- IP addresses that pass the SPF mechanism using another domain’s SPF record can be allowed as long as they include _spf.record.com (they must include the _spf.domain.com mechanism)
If you’re using a third-party email delivery service, then they will probably ask you to add their SPF record to your domain’s records with the ‘include’ mechanism. For example, Google may ask you to add include:google.com to your SPF record so that emails sent from here will pass the SPF check.
Here is an example of a special SPF record that would prevent any email from being sent on behalf of a domain:
v=spf1 – all
This record indicates that no IP address will be allowed to send emails from that domain. It helps to publish an SPF record on all domains that are not allowed to send emails, even parked domains. If you don’t do this, then it makes them a target for spoofing attacks and may cause the domain that it is associated with to lose its trusted reputation. It may also affect the domain’s email deliverability if you decide to use it later on.
It’s important to run an SPF record on all IPs that will be sending emails from your domain. Otherwise, emails sent from some of the email domains may fail SPF record checks, and affect email deliverability and your reputation.
How To Publish SPF Records?
After you’ve created an SPF record, you will need to publish it in your DNS because it can be picked up by a receiving server. To do this, you’ll need to create a special TXT record on your domain. We’ll provide an example below. Here’s how to publish an SPF record if you are using Google as your domain service provider.
- Log into Google or Gmail and click on the DNS button. If you have never published an SPF record on your domain before, then you will need to click on the “add” button, which is located underneath the ‘records’ section. If you already have an SPF record published, then you need to click “edit” instead. You can check to see if there is an SPF record already published by locating a TXT record with a mechanism that starts with “v=spf1.”
- Click on the TXT to display the drop-down menu. For the host field, enter “@” then enter the SPF record as the TXT value and save.
You should have published your first SPF record. You can go back and check to make sure that you did it correctly. However, it may take up to one hour before it appears due to DNS rules.
What is the DNS Lookup Limit?
Every time an email reaches the email service’s host, the host looks it up in the DNS to do an SPF check. During this process, SPF records are protected against denial of service (DOS) attacks. The SPF records process assumes that the number of modifiers and mechanisms that perform DNS lookups do not exceed ten times per check. This includes any lookups that use the ‘include’ mechanism or ‘redirect’ modifier.
A PermError will be returned if this number is exceeded during one check. However, the “a,” “mx,” “ptr,” and “exists” mechanisms, as well as the redirect modifier, will not count against this number. Also, the “ip4,” “ip6,” and “all,” mechanisms do not require a DNS lookup. Therefore, they will not count toward the number of SPF lookups. Lastly, the “exp” modifier does not count because the lookup occurs after the SPF record has been evaluated.
Let’s look at the following example from Google:
v=spf1 include:_spf.google.com ~all
In this example, the ‘include’ mechanism recorded one count against the limit.
Here is the SPF record for _spf.google.com:
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all
In this example, the 3 ‘include’ mechanisms count for three lookups against the limit. The following records resolve to a flat list of IP addresses, which means that they do not count against the limit:
This means that the total number of modifiers and mechanisms that require DNS lookups is four. You can use the SPF record checker on EasyDMARC’s website to verify the SPF records.
What Happens If Your SPF Record Check Exceeds The Lookup Limit?
Per SPF protocols, if your SPF record lookup exceeds ten attempts, then SPF authentication returns an error indicating that there have been too many DNS lookups. DMARC interprets SPF permanent errors as a fail. So, if you exceed the 10-DNS-lookup limit, it negatively impacts your email deliverability.
It’s a good idea to use the EasyDMARC SPF record check tool to check the count of the SPF record for your domain. This can help ensure your SPF record lookup does not exceed the limit. If you exceed the 10-DNS-lookup limit, then you will need to “flatten” your SPF record to ensure that your legitimate emails make their way to the inbox.
You can manually flatten your SPF records. However, this technique is prone to errors and tends to be tedious. We recommend using a tool to help ensure this process is properly done. EasyDMARC has a tool that offers SPF record flattening.
Helpful SPF Tools
EasyDMARC offers free SPF tools for several tasks, such as checking an existing SPF record and generating an SPF record. We’ve listed out several for you here:
- Go to the SPF record generator to generate an SPF record. You’ll need to enter the qualifier and mechanisms that suit your needs and then press the ‘generate SPF record’ button. That’s it! You’ll have an SPF record that is ready to be published.
- Go to the SPF record lookup to check the SPF record on your domain. To do this, you’ll need to enter the domain you want to be checked. The SPF record checker will fetch the SPF record from the DNS if there is any. Then, it will check to make sure the SPF record syntax is correct. It will also make sure the number of modifiers and mechanisms that the DNS looks up does not exceed ten. Lastly, it will “flatten” the returned SPF record into a list of general IP addresses, which allows you to check them one by one. This is a great way to determine whether there are issues with your SPF records.
Final Thoughts on SPF
There are several things wrong with using SPF alone. Remember when we talked about how every email has two from addresses (the header from and envelope from)? Well, if those addresses are different, then SPF will only check the from address. SPF will NOT check the header from address if it’s different from the envelope address, meaning that the header from address is easier to spoof.
This is dangerous because the header from address is the one that the domain user thinks is from the sender. For example, if an email comes through to your inbox from [email protected] when it’s really from [email protected], then you will probably open it because the first address is the one you see.
To work around this, DMARC uses a concept called identifier alignment that ensures the envelope from address matches the header from address. This prevents the opportunity for hackers to spoof an email from your domain.
Another thing to keep in mind is that SPF does not work if an email is forwarded. When a forwarded email finally reaches the receiving server, and the server’s IP is not what is listed on the white list, then the SPF check fails. This does not happen very often, but it can be fixed by DMARC. We will talk about this later, too.
What is DKIM?
Authenticating every email is an important part of email security. Email messages usually go through several servers before reaching their final destination. It’s possible that emails could become hacked or tampered with somewhere along their journey.
For example, let’s say that an email is sent between two companies asking for a payment of $1,000 USD to be directly deposited into the first company’s bank account. If the email is hacked downstream so that the money becomes wired to a fraudulent account in the amount of $100,000. Without added security measures, it’s hard to detect these changes.
This is where DKIM comes in handy. Domain Keys Identified Mail, or DKIM, is an email authentication process that detects forged headers in emails. DKIM allows the receiving server to determine if the email headers have been altered somewhere along their journey to the inbox.
The best way to understand how DKIM works is to compare a DKIM signature to a postal envelope seal. Try thinking of a DKIM signature located in the email header as an envelope seal. When you write someone a postal letter and seal the envelope, it’s similar to putting a DKIM signature in an email address. When you seal the envelope and put it in the mailbox, DKIM will check to make sure that anyone who “breaks” the seal will be flagged.
- DKIM uses asymmetric cryptography, which means that it uses a pair of private keys only known to the user as well as public keys that can be distributed all over.
Digital signatures are one of the best-known uses of asymmetric cryptography. It occurs when a message is signed with a private key and is capable of being verified by anyone with access to the sender’s public key. This ensures that the message has not been hacked because the signature is bound to the message. Verification will not be granted for any other message even if it’s very similar to the original message.
How Does DKIM Work?
DKIM has two authentication components: signing and verification. A signing server (the DKIM-enabled server) signs email messages on their way out by using a private key that is part of a generated key paid. When the email reaches the recipient’s inbox, the receiving server uses the verification part of DKIM to check and see if there is a DKIM-signature in the header. If there is one, it uses a DKIM public key located in the DNS to authorize the signature.
Emails may or may not pass the DKIM check, depending on the outcome of the DKIM signature check on the receiving server’s end. DMARC uses the DKIM authentication result later on.
In order for DKIM to work, the following must occur:
- User must create a key pair that contains both a private key and public key;
- The private key must be kept with the signing server;
- The public key must be published in the DNS in a DKIM record because it ensures that the verifying server has access to it.
What is a DKIM Selector?
A DKIM selector refers to a string that the outgoing server uses to locate the private key. It is needed to sign an email message. The receiving server also uses the DKIM selector to find the public keys in the DNS and to verify that the email message is valid. Both servers (the receiving and the sending servers) must use the same DKIM selector to use the same private and public key pair.
What Does DKIM Signing Mean?
DKIM signing refers to signing an email message on the original email server’s end. Also, DKIM signing requires users to choose what header fields or body must be included in the data and computing the hash sum of the data, such as the message body and headers. Users must also encrypt the hash sum with the private key, resulting in the “signature.” Finally, a DKIM-signature header that contains the signature to the email is produced.
What Happens During DKIM Verification?
When an email is sent, the receiving server checks to see if a DKIM-signature field exists in the header. The signature is contained in the b=tag. If a DKIM-signature field is present, then the server will pass the authentication check.
Here’s how it works. First, the receiving server will look up the DKIM record in the DNS using the s=tag selector found in the DKIM signature. If there is one found, the server will extract the public key. This can be found in the key pair from the record. The p=tag contains the DKIM public key.
Next, the server will create a hash sum using an algorithm identified by the a=tag that is found in the incoming data specified by the h=tag. The signature will be decrypted with the public key so that the hash sum is revealed by the sender. If the hash sum of 4 is equal to the hash sum of 3, then it passes the check. This means that the message has not been hacked.
It should be noted that the DKIM verification part only checks the header fields in the signing part and all other parts of the email must be the same. Otherwise, the check will fail. On the other hand, the DKIM authentication will fail if there is no change in the non-chosen parts.
Tags in DKIM Signature and DKIM DNS Record
The tag=value lists can be found in the DKIM signature header field of an email message. Here is an example of what a DKIM signature header field looks like:
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
The following is a list of tags that can show up in a DKIM-signature header field:
- x: expire time
- v: version
- a: signing algorithm
- d: domain
- c: canonicalization algorithm for header and body
- q: default query method
- s: selector
- t: signature timestamp
- h: header fields – list of those that have been signed
- bh: body hash
- b: signature of headers and body
DKIM records are published in the DNS with tag= values. Here is an example of a DKIM DNS record:
PLACE EXAMPLE HERE
Here is what the tags in a DKIM record mean:
- v: version; must be DKIM1
- g: granularity
- l: body length limits
- h: mechanisms that can be used to produce message data
- n: DKIM notes
- s: service types that the sector must apply to
- q: various query methods
- k: mechanisms that can be used to decode a DKIM signature
- t: flags that modify the selector’s interpretation
- p: base64 encoded public key
How To Create A DKIM Record?
Creating a DKIM record using a third-party email service provider is pretty easy. All you have to do is use their service to create a private and public key pair that is stored within their service.
For example, you can follow these steps to set up a DKIM record using a third-party service:
- Log into your service provider’s dashboard
- Go to the settings option and click on Sender Authentication or Authenticate Your Domain
- Pick your DNS host and click next
- Enter the domain you want to authenticate (your email address) and click next
- Your service provider should have created two DKIM records for you using s1 and s1 selectors
This method is very easy because you do not have to manage a private or public key. Your third-party email service provider will do all of this for you. All you have to do is to publish the two DKIM records that they created for you in your DNS.
The DKIM record that is generated might be different, depending on what email delivery service you are using. For example, SendGrid generates CNAME records when you install a DKIM record with them. No matter what service you use, you will be responsible for publishing the DKIM records yourself. Additionally, some email service providers will only generate one DKIM record while others (such as the example we used above) will generate two.
How To Publish a DKIM Record?
You need to publish a DKIM record in your DNS first before an email receiver can authenticate your domain using DKIM. This is because the receiving server looks for the DKIM records in the DNS. To publish a DKIM record, you’ll need to create a CNAME record on (selector)._domainkey.example.com.
Here is a step-by-step guide showing you how to publish a DKIM record on GoDaddy:
- Log in to GoDaddy and click on the domain that you want to publish a DKIM record for. Then click the DNS button
- If no DKIM records exist, then click the “add” button located under the “records” section
- If you have a DKIM record generator, then click on edit it. You can check to see if the DKIM record already exists by looking for a CNAME record that looks like this: (selector)._domainkey
- Click on the CNAME for the type drop-down menu. Enter this into the host field: s1._domainkey, which indicates that s1 is the selector. Enter the POINTS TO value in step four, which is listed in the Creating a DKIM Record section. Then save.
Understanding DKIM Key Rotation
DKIM is highly effective when it comes to verifying that an incoming email’s signed fields have not been modified during transit before it reaches the inbox. However, DKIM is only as secure as the weakest link, which is the private key.
The private key of a DKIM key pair can be stolen if a cybercriminal compromises the system that it is stored in. To reduce the risk of active DKIM keys being hacked, it’s important to change them frequently, which is known as key rotation.
Manual DKIM key rotations are needed if you want to run your own email delivery service by yourself. If you are using another service to deliver emails, such as Office 365 or Google, then you don’t have to rotate your keys. This is because DKIM rotation is done automatically for you.
Helpful DKIM Tools
You can use the free online DKIM generator tool on the EasyDMARC site. You can also use our tools to publish a DKIM record or check for an existing one.
- Go to the DKIM record generator on the EasyDMARC website. Enter your domain and selector then hit the button to generate your DKIM record. This tool will generate a private key that can be stored on your domain as well as a DKIM record that is ready to be published in the DNS.
- You can use the DKIM record lookup on the EasyDMARC website by entering your domain and selector. Then it will lookup the DKIM record on selector._domainkey.domain. It will also check to make sure the DKIM record is listed correctly.
Here is a list of what each tag in a DKIM record means:
- v: this refers to the DKIM protocol version, which is “DKIM1” by default
- g: some companies will assign a business function to a certain group, either internally or externally. The ‘g’ tag is used to assign the group to email, and also restrict what signatures they can create. The DKIM g tag helps assist this process
- h: this tag provides a list of mechanisms that can be used to create a portion of the message data
- n: this section contains notes for domain users
- s: this tag provides a list of service types that the sector may apply to
- q: this section provides a list of query methods, such as ‘dns’
- l: the l= tag refers to body length limits, which are subject to cyber attacks
- k: this tag provides a list of mechanisms that are needed to decode a DKIM signature, such as rsa
- t: this tag provides a list of flags that can be used to modify the interpretation of the selector (optional)
- p: this refers to an encoded public key (Base64).
Final Thoughts on DKIM
SPF works by breaking down an email message when it’s forwarded. DKIM signatures do not break down during forwarding. This is because DKIM signatures are part of the message header and not the SMTP envelope. Only the SMTP envelope is altered during email forwarding.
However, DKIM does not require the d= value in the signature to match the header to the domain. This is why receiving email domains need to look at the header to tell where it’s from. A hacker can alter the DKIM signature with a d-value that sends the email to an address controlled by the hacker. This allows DKIM to pass a check even though the address is visible to the owner.
You can fix this by using DMARC identifier alignment, which ensures that the d= value in a DKIM signature matches the header from domain, which is required for the email to pass DMARC.
What is DMARC?
DMARC stands for Domain-Based Message Authentication, Reporting, and Conformance. It’s an email authentication protocol that determines whether an email is authentic or not. In other words, it ensures that any email sent from your domain is actually from you. DMARC works by building on DKIM and SPF, which is why it is important to explain them first before getting into how DMARC works. Additionally, DMARC performs alignment checking and reporting duties to the domain users, improving and monitoring the domain’s protection against spoofing attacks.
How Does DMARC Work?
DMARC works by piggybacking off SPF and DKIM. The combination of SPF, DKIM, and DMARC helps provide long-term protection against business email compromise. Here is how DMARC works:
- First, you will need to publish a DMARC record in your DNS for your email domain. This ensures that whenever an email says that it came from your domain, the receiving email domain will pull up the DMARC record and check it against the email message
- Depending on the outcome of the check, the email will either be sent to the inbox, quarantined (sent to spam), or rejected altogether
- DMARC will send a report to the email address listed in your DMARC record to update you with your progress. The DMARC report will tell you how many emails are being sent to the inbox, which ones are quarantined (and why), and which are rejected.
DMARC works by implementing an identifier alignment that eliminates any discrepancies between the header from and envelope from addresses in SPF. The identifier alignment also addresses any differences between the header from and d=value in DKIM.
Next, DMARC uses reporting abilities to make sure that the domain user understands the email deliverability of their email address. This reporting ability helps ensure that you have complete protection against business email compromise.
DMARC allows you to publish a DMARC policy on your DNS that tells incoming emails what to do if they do not pass a DMARC check. The three options are to send to inbox, send to spam, or reject.
How To Implement DMARC?
Before we learn how to implement DMARC, let’s review organizational domains and what they mean. The term organizational domain refers to a domain’s root or central part. For example, the organizational domain of the example email.sender.com is sender.com. Organizational domains are used to check identifier alignment in relaxed mode.
Emails must contain a primary identifier, which is a piece of information that the user can use to identify where it came from. DMARC uses the domain in the header from address as its central identity because it is a required field. This means that it’s guaranteed to be in every email message. Additionally, most email fields display the header from address as the originator of the email – or who sent the email.
For example, the central identity in an email can be displayed as the following:
INSERT EXAMPLE HERE
DMARC uses the header from address in the domain to identify where an email was sent from. Therefore, if an email passes a DMARC check, then it comes from the email listed in the from address that is displayed to the receiving server.
What Does Identifier Alignment Mean?
Email authentication works by verifying how authentic certain aspects of an email are. SPF works by verifying the domain in the envelope from address, and DKIM verifies the domain in the d=tag located within the header in the DKIM signature. Most of the time, these domains cannot be seen by the receiving server, which means that they are prone to be hacked.
DMARC makes the email authentication process harder because it requires both SPF and DKIM to pass their checks. DMARC takes this process one step further by requiring at least one of the domains used by SPF or DKIM to align with the domain in the central identifier (the header from address). This is known as identifier alignment or domain alignment. It occurs when all aspects of the email authentication processes align and “match.”
- SPF identifier alignment occurs when the envelope from address aligns with the domain in the header from address. If the envelope from field is empty, then the domain is checked against the EHLO domain
- DKIM identifier alignment is when the domain located in the d=tag of the DKIM signature aligns with the domain in the header from address.
To sum it up: identifier alignment means that two domains match. There are two ways in which this happens: strict alignment and relaxed alignment.
Strict mode means that the two domains have to be identical for them to be aligned. So, for example: the email address net.domain aligns with net.domain in strict mode, but it does not align with org.net.domain.
The two domains do not have to match exactly in relaxed mode. They will align with each other as long as the organizational domains match. For example, net.domain aligns with net.domain in relaxed mode as well as org.net.domain.
The email is DMARC aligned when either of the following is true:
- The email passes SPF and has SPF identifier alignment
- The email passes DKIM and has SPF identifier alignment
In other words, DMARC aligns when SPF passes and identifier alignment or DKIM passes and identifier alignment. The email is DMARC aligned when it passes DMARC authentication. This means that the email comes from the email address in the header from address (that is displayed to receiving servers). In other words, DMARC authentication hardened.
DMARC Policies and Records Explained
DMARC policies provide directions to email servers on what to do when an email does not pass a DMARC check. The three options are:
- Do nothing, which is also called monitoring mode (this is when the email is sent to the inbox despite not passing)
- Quarantine, which is when the email is sent to the spam folder
- Reject, which is when the email is not delivered to the inbox or spam (the recipient will never see it)
You can tell your DMARC record how to handle emails in the p tag. For example, p=none means that you want DMARC to take no action if an email fails a DMARC check and send it to the inbox anyway.
DMARC records are TXT records that are published in your domain’s DNS. They are listed under the _dmarc.youremailhere.com – only you would replace ‘youremailhere’ with your domain name or subdomain. DMARC records tell the email what to do if it fails a DMARC check. It also provides an email address to send DMARC reports to for important information regarding email delivery.
Each DMARC record is made up of a list of tags. Here is what those tags mean:
- v=: this tag refers to a DMARC protocol version – “DMARC1” is default
- p=: this tag refers to policies that can be applied when an email fails a DMARC check. For example, you can set the p= tag to none, quarantine, or reject.
- Rua: this tag refers to a list of URLs that email addresses can send reports to. It should be noted that this is NOT a list of email addresses. DMARC requires rua to provide a list of URLs in the form of “sendto:[email protected].”
- Ruf: this tag refers to a list of URLs that forensic reports are sent to from ISPs. Just like with rua – this is not a list of email addresses. The format must be sent in the form of the URLs in the rua tag.
- Sp: this tag refers to a policy that can be applied to a domain from a subdomain if an email fails the DMARC check. It allows the domain users to set a type of wildcard for subdomains.
- Fo: this tag stands for “forensic options.” You can use 0 to create reports as long as DKIM and SPF both fail. You can use 1 to create reports if either DKIM or SPF fails to create a DMARC pass – “d” can be used to create a report if DKIM fails or you can use “s” if SPF fails. These options will tell a DMARC check to pass.
- Rf: this tag refers to forensic report formatting
- Pct: this tag tells the ISPs to only use DMARC policies to a certain percentage of failing emails. For example, “pct=70” will direct receiving emails to only apply the p=policy tag 70% of the time for emails that fail the DMARC check. This tag does not work for the ‘none’ p=tag. It only works for policies set to ‘reject’ or ‘quarantine’ failed emails.
- Adkim: this tag tells DKIM signatures that they must be in ‘alignment mode.’ It can either be relaxed (‘r’) or strict (‘s’). When the DKIM signature is in relaxed mode, emails that share an organizational domain and a ‘from’ domain will pass DMARC checks. However, in strict mode, these two must be an exact match.
- Aspf: this is a tag that sets the alignment mode for SPF. Again, it can be either relaxed or strict.
- Ri: this tag refers to the reporting frequency for how often you want to receive XML reports. You can set this based on your preferences so that the ISP will send the report at different times daily.
How To Create A DMARC Record?
You can follow these steps to create a DMARC record:
- First, verify the email domain that you plan to send your business emails from. If you plan on sending emails from [email protected], then your domain is sales.com.
- Log into the EasyDMARC dashboard and click on Publish DMARC Record. You can find this in the DNS records section.
EasyDMARC will do the work for you! It should be noted that there is a section on the page that allows you to customize your settings for each DMARC record. You can instruct the receiving server how you want to handle emails that fail the DMARC check.
For example, you can set the p= tag to none, quarantine, or reject. By setting the p=tag to none, it tells the domain to enter monitoring mode, which means that you can see how many emails are passing or failing DMARC checks.
This means that receiving emails do not quarantine or reject failed emails when it’s in monitoring mode. Everything will work just like before you enabled DMARC. There is one major benefit of monitoring mode – it allows you to receive reports to gain visibility into your email deliverability.
If you’re new to DMARC, then you can ignore these settings for now and change them later if needed.
What is DMARC External Destination Verification?
It’s important to understand external destination verification when setting up a DMARC policy. For example, let’s say you use the ‘rua’ tag and publish the following DMARC record:
v=DMARC1; p=none; rua=mailto:[email protected]
In this example, you are requesting that email service providers send reports to the email specified in the DMARC record. However, the owner of the receiving domain must give you permission before doing so. If not, these reports will not be sent to the intended address. This process is known as external destination verification or EDV.
Here is how it works:
- The domain owner published an EDV record, such as example.com_report_dmarc.com, meaning that the v=DMARC1 tag in the DNS enables EDV
- Before the server can send reports to the email listed in the example, it needs to check to see if the receiving domain has allowed reports to be sent to it by looking up the address in the DNS. If there is a record present, and the value is v=DMARC1, then the report will be sent through. If not, it will not be sent.
It should be noted that the above EDV example is per domain. In other words, it only allows reports on the example domain to be sent through to the provided address. If you want reports sent on another domain, then you will need to publish a DMARC record for that address. You can also publish a wildcard EDV record to allow reports on any domain to be sent to the example domain.
Here’s how to publish a wildcard EDV report:
If this sounds confusing to you, then don’t worry. You won’t need to do this if you are using EasyDMARC to publish a DMARC record. We will take care of this for you!
How To Publish A DMARC Record?
After you create a DMARC record, you must publish it to the DNS before it can be applied. Here’s why it’s important to publish a DMARC record. When an email gets sent, the receiving email server takes the domain from the email address and checks to see if a DMARC record is published in the DNS entry. If it finds one, it will perform the instructions set in the DMARC record.
Here’s how to publish a DMARC record:
- Log into the management settings of your DNS and verify the domain you want to publish a DMARC record for
- Create a TXT using these tags: type, host, TXT value, and TTL.
Here is an example of what this will look like:
INSERT EXAMPLE HERE
- Publish your record.
That’s it! Your DMARC record will be published in a matter of days. If you have several domains that you want to publish a DMARC record for, then be sure to repeat these steps for each one.
Understanding DMARC Reports
There are two types of reports that DMARC can send: aggregate and forensic reports. DMARC aggregate reports contain information regarding the percentage of emails that pass or fail SPF, DKIM and DMARC checks.
They do not provide as much information about each individual message. However, aggregate reports provide valuable information about the overall health of your email program. They can be used to help you identify any issues with your authentication protocol or identify any fraudulent activity.
To specify aggregate ports in the DMARC record, you’ll need to use the ‘rua’ tag. For example, in the following example, the ‘rua’ tag tells the ESP to send aggregate reports to [email protected]:
On the other hand, DMARC forensic reports are created by email service providers right after an email does not pass a DMARC check. Forensic reports are made up of message header fields, such as authentication results, source IP, “to” and “from” email addresses, and the message body. To specify the recipient of the forensic report (who you want these reports to be sent to), use the ‘ruf’ tag in the DMARC record.
How To Set Up DMARC Reporting?
Setting up DMARC reporting is the final step in fully implementing DMARC. To set up DMARC reporting, you will need to do the following:
- Set up a mailbox to send aggregate and forensic reports to
- Publish the DMARC record
- Analyze the data that these reports contain
- Enter the data into charts
This can seem like a lot of work if you are not familiar with DMARC, especially if you plan on repeating these steps every day. You can use EasyDMARC analytic tools to handle this for you.
How To Update Email Streams?
The primary reason for analyzing DMARC reports is to determine which email sources failed SPF or DKIM checks are actually legitimate. In other words, what email hosts that are part of your email infrastructure are failing when they shouldn’t be.
After you have identified these failed yet legitimate email senders, then you need to update your SPF and DKIM settings so that these emails pass the next time they are sent. You will also need to remove hosts or email addresses that are not supposed to be sending messages on your behalf, but are still passing (if there are any).
How To Set Up DMARC – A Step By Step Guide?
In this quick-guide section, we’ll show you how to jump right into setting up DMARC. We’ve grouped these steps together to prevent you from getting overwhelmed by lots of technical terms. To set up DMARC quickly, the first thing you will need to do is take inventory of all the email domains you want to protect. Then, do the following for each one:
Step one: Set up SPF
To set up SPF, use these steps:
- Create an SPF record. You can use the SPF record generator on the EasyDMARC website.
- Publish the SPF record. (Again, you can use the EasyDMARC website to do this).
- Check the SPF record to make sure it’s set up correctly before moving on.
Step two: Set up DKIM
To set up DKIM, use these steps:
- Use the EasyDMARC website to create a DKIM record
- Publish the DKIM record (you can also use the EasyDMARC website for this).
- Check the DKIM record to make sure it’s set up correctly before moving on.
Step three: Publish a DMARC record
Once you set up SPF and DKIM, you need to set up DMARC. You can do that by following these steps:
- Go to the EasyDMARC website and click on ‘create a DMARC record.”
- Then click on “publish a DMARC record.”
Keep in mind that you should set the DMARC policy to p=none to start. This is your “monitoring mode,” which means that no legitimate email messages will be affected.
Go back and check the DMARC record to make sure it was published correctly after one hour. Once you’re done with this, keep in mind that DMARC aggregate reports will be sent to your inbox every day. But it might take a day or two before they show up in your designated mailbox. This action can be controlled by the ‘rua’ tag in your DMARC record.
Step four: Analyze your DMARC reports
Once your reports are ready, you can analyze your reports. Use a system like EasyDMARC to handle all of your reports rending from here on out. We will take care of all the maintenance work for you. You can also specify the mailboxes that you wish to receive DMARC reports.
Using EasyDMARC to analyze your reports means that your job here is done. We will set up your mailboxes, download reports, parse, render, etc. If you decide to do this part on your own, then you will need to do the tasks mentioned above manually for each DMARC report.
Step five: Rectify your message streams
Rectifying your message streams refers to setting up DKIM and SPF as the source of the stream. This means that all emails from the source that you pick will pass DMARC checks.
In this step, you should identify all unauthorized legitimate email sources. Add these email sources to your steam and get rid of everything else.
You can do this easily from the EasyDMARC dashboard. Simply log into your account and go into your Aggregate Reports. Click on the Unaligned Sources tab.
Next, go through the unaligned sources and add the authorized ones to your stream so that they pass DMARC checks next time.
If you plan to use another email delivery service, then you’ll follow similar steps. However, it’s a good idea to look up how to set up SPF and DKIM within the documents of that system as these steps might be different.
Make sure you keep checking your email streams to locate any additional unauthorized legitimate email sources and edit these as soon as you catch them to improve email deliverability.
If you find emails from authorized sources that should be passing DMARC checks, and everything else says that it’s failing, consider switching your policy to quarantine mode.
This brings us to our next step.
Step six: Move to quarantine (and the reject) mode
Moving your DMARC records to quarantine mode means that any email that fails a DMARC check will be moved to spam. This is a type of in-between action that will give you more monitoring abilities than the p=none or p=reject policies.
Consider leaving this policy in quarantine mode for three months. Then, if everything looks fine, you can implement the reject mode. In the reject mode, all email messages that fail DMARC will not be allowed to go through to the inbox.
This is the best and most effective way to stop email phishing attacks and business email compromise. But it’s important to make sure your email streams are correctly set up before going to this mode as you don’t want important emails to miss their intended recipients.
Step seven: monitor and update your DMARC policies
Congratulations! Once you have made it to this step, you have successfully implemented DMARC. But your job is not done.
Now, you need to monitor your email streams to make sure everything continues to operate smoothly and ensure no business email compromise will happen.
It’s important to monitor your DMARC records because the infrastructure in your organization may change occasionally. This means that the operations used in the past may no longer work after these changes are made.
Your DMARC records will need to be changed as a reflection of these new rules to ensure they continue to work for you. You can do this by analyzing your aggregate reports and updating your DMARC rules accordingly. Doing so will help ensure that your domain keeps delivering emails properly and maintains a good sender reputation.
Other Factors To Consider
To complete your email authentication system based on SPF, DKIM, and DMARC, you should take these factors into account, if they apply.
How To Set Up Reverse DNS Records?
If you send emails from another server other than the one you commonly use, then you should set up a reverse DNS record. Otherwise, many ESPs will block your messages.
A reverse DNS record works by inserting an IP address into a hostname – which is exactly the opposite of what a normal DNS record does.
In fact, all IP addresses that you send emails from should have one of these. It will allow you to take a numeric IP address and identify a hostname. This is beneficial because ESPs will block your email address if no PTR record is found. This ensures that you will be able to view email sources as hostnames instead of IP addresses.
Important Things To Remember
Make sure you implement all three email authentication protocols – SPF, DKIM, and DMARC. This is because authenticated emails will be able to build and monitor the sender’s reputation. Senders in good standing are recognized more easily, while those who are not in good standing will be in a position of disadvantage at first.
SPF is a complex and powerful mechanism, but it shouldn’t be challenging to use. We recommend keeping your SPF records as simple as possible. Do not add more hosts to your SPF records than necessary.
This includes your mechanisms as well. Use as few as possible and avoid including anything that you don’t need to. Never use so many ‘includes’ that you exceed the ten limit lookup. If you identify blocks of addresses using the ‘CIDR’ areas of your SPF records, then be sure to only use ranges that go from /30 to /16. For example, you can use 10.10.10.0/25.
In other words, the higher the number that comes after the slash, the better. This is because it indicates that there is a smaller group of addresses. Avoid anything that is around /1 to /15 because some servers will ignore these blocks completely. We recommend that you never use a record with “+all.” The only way to safely use this is in the “-all” mechanism.
Make sure your DKIM keys are at least 1,024 bits long because signatures made with keys shorter than this will be ignored. This method will become more popular as more senders use keys that contain at least 2,048 keys or longer.
However, it’s a good idea not to go to extremes one way or the other. Don’t use keys that are 4,096 units long as these might not fit within most standard 512-byte DNS UDP packets. Some DNS units do not allow packages larger than 512 bytes. Using large keys might cause DKIM to fail.
Research shows that the science behind the cryptographic digital signatures that DKIM is built on changes over time. One of the ways this technology change is by changing cryptographic keys all the time in an attempt to prevent cybercriminals from attacking them.
However, many people are still using keys that were created years ago. Instead, try switching to a new DKIM key or change out your keys often – at least once per year. This is especially beneficial if you send millions of messages every month. You may even want to change your keys more than once per year if you have a high email message output.
When you publish a DMARC record, it’s a good idea to use DMARC in p=none first. This allows you to benefit from the reporting aspects of DMARC. It also allows you to tell email service providers that they should identify messages that use your domain if they don’t pass checks.
You can gradually advance to p=quarantine or p=reject once you have monitored your account for a few months to ensure there are no errors. This allows fraudulent emails using your domain to be verified and blocked, which improves email deliverability and keeps your business reputation intact.
Many people find it confusing to monitor and manage DMARC reports. For this reason, we recommend leaving it to the professionals. Outsourcing your DMARC needs to EasyDMARC can save you a lot of time and effort. It also ensures that your systems are set up properly.
We hope that this extensive DMARC guide has shown you how important it is to set up proper email authentication to stop business email compromise and improve email deliverability.
If you have any questions, email us at [email protected] and we will get back to you right away!