DKIM stands for DomainKeys Identified Mail and is used for the authentication of an email that’s being sent. Like SPF, DKIM is an open standard for email authentication that is used for DMARC alignment. A DKIM record exists in the DNS, but it is a bit more complicated than SPF. DKIM’s advantage is that it can survive forwarding, which makes it superior to SPF and a foundation for securing your email.
Starting in 2004 from merging two similar efforts, “enhanced DomainKeys” from Yahoo and “Identified Internet Mail” from Cisco and has since been widely adopted for email authentication.
What is a DKIM Record?
A domain owner adds a DKIM record, which is a modified TXT record, to the DNS records on the sending domain. This TXT record will contain a public key that’s used by receiving mail servers to verify a message’s signature. The key is often provided to you by the organization that is sending your email, for example SendGrid, Postmark, or Google Apps.
What is a DKIM Signature?
DKIM gives emails a signature header that is added to the email and secured with encryption. Each DKIM signature contains all the information needed for an email server to verify that the signature is real, and it is encrypted by a pair of DKIM keys. The originating email server has what is called the “private DKIM key,” which can be verified by the receiving mail server or ISP with the other half of the keypair, called the “public DKIM key.”
These signatures travel with the emails and are verified along the way by the email servers that move the emails toward their final destination.
How does DKIM work?
When an inbound mail server receives a message, it will detect the DKIM signature and look up the sender’s public DKIM key in DNS. The variable or DKIM selector provided in the DKIM signature is used to determine where to look for this key. If the key is found, it can be used to decrypt the DKIM signature. This is then compared to the values retrieved from the received mail. If they match, the DKIM is valid.
Read about DKIM Selectors and how to discover which ones your domain may be currently using.
Why use DKIM for Email?
Implementing DKIM for email provides major benefits:
Protection of message integrity. The content of the email can be verified that it hasn’t been changed while being sent.
Increases domain reputation and email deliverability.
One of the foundational methods of email authentication for DMARC.
How do I know if DKIM is working?
Test your domain’s DKIM settings – Our DKIM Inspector is a free diagnostic tool that check if the public part of your DKIM signature—using the selector—has been implemented correctly in the DNS of your domain. Our free DKIM Validator can help you verify that your DKIM record is properly formatted.
What happens when DKIM fails?
When DKIM alignment fails—or when the d= value in the Header From does not match the d= value in the DKIM signature—it can negatively impact deliverability as mailbox providers may send the message to the spam folder or block it entirely.
It is important to examine all messages that have failed to identify the sources as valid or as malicious. If you recognize a source as legitimate, you can investigate and set up DKIM correctly. If a source is not recognized, make sure to research it because this could indicate an attempt to send malicious emails on behalf of your domain.
Why DKIM-Only Isn’t Safe Enough
DKIM on its own isn’t a reliable way of authenticating the identity of the email sender and does nothing to prevent the spoofing of the domain visible in the header of the email. DMARC solves the problem by guaranteeing that the domain the end user sees is the same as the domain that is validated by DKIM and SPF. Learn more about DMARC alignment.
Furthermore, the addition of DMARC provides email received instructions on what to do with emails which do not match these checks via DMARC policy enforcement.
Domain-based Message Authentication Reporting and Conformance (DMARC) is a free and open technical specification that is used to authenticate an email by aligning SPF and DKIM mechanisms. By having DMARC in place, business owners large and small can fight the massive cybersecurity problems caused by phishing and reputation damage caused by spoofing.
With DMARC you can tell the world how to handle the unauthorized use of your email domains by instituting a policy in your DMARC record. The three DMARC policies are:
Monitors your email traffic. No further actions are taken.
Sends unauthorized emails to the spam folder.
The final policy and the ultimate goal of implementing DMARC. This policy ensures that unauthorized email doesn’t get delivered at all.
How does DMARC work?
DMARC is based upon the results of SPF and/or DKIM, so at least one of those has to be in place for the email domain. To deploy DMARC, you need to publish a DMARC record in the DNS.
A DMARC record is a text entry within the DNS record that tells the world your email domain’s policy after checking SPF and DKIM status. DMARC authenticates if either SPF, DKIM, or both pass. This is referred to as DMARC alignment or identifier alignment. Based on identifier alignment, it is possible that SPF and DKIM pass, but DMARC fails.
A DMARC record also tells email servers to send XML reports back to the reporting email address listed in the DMARC record. These reports provide insight on how your email is moving through the ecosystem and allow you to identify everything that is using your email domain.
Because reports are written in XML, making sense of them can be tricky, and they can be numerous. dmarcian’s platform can receive these reports and provide visualization on how your email domains are being used, so you can take action and move your DMARC policy towards p=reject.
What is a DMARC Record?
As a mission-driven company, dmarcian is focused on spreading the adoption of DMARC. Because of this, we interface with a wide range of people with varying degrees of knowledge. We thought we’d take a step back and take a look at something fundamental: What is a DMARC record?
A DMARC record is a text entry within the DNS record that tells the world your email domain’s policy when it comes to checking to see if your SPF and/or DKIM has passed or failed.
A DMARC record also tells the servers that touch your email on its way to its final destination to send XML reports back to the reporting email address listed in the DMARC record. These reports provide insight on how your email is moving through the ecosystem and allow you to identify everything that is using your email domain.
More information on publishing DMARC records can be found here.
The DMARC Record; what does it look like?
“v=” indicates this is a DMARC record
“p=” indicates the DMARC policy
“rua=” indicates where data should be sent
RUA is reporting that provides an aggregate view of all of a domain’s traffic. The other option is RUF reports that are redacted forensic copies of the individual emails that are not 100% compliant with DMARC. While RUA reports show the traffic of the email, RUF reports contain snippets from the actual emails themselves. While RUA reporting is all that is needed for DMARC deployment, more advanced users may also add the RUF tag, which will send more sensitive information.
These reports are in Extensible Markup Language (XML), which isn’t easy to read:
There are tools that can translate these XML files into a human-friendly format. Services like Dmarcly, where the RUA reports can be pointed to, automatically process the reports and give you insight via a powerful dashboard to make identifying the valid uses of your email domain easier while disallowing abuse. A dmarcian account will store past reports so you can observe trends and be alerted when new threats arise.
Why Use DMARC for Email?
Email is involved in more than 90% of all network attacks and without DMARC, it can be hard to tell if an email is real or fake. DMARC allows domain owners to protect their domain(s) from unauthorized use by fighting phishing, spoofing, CEO fraud, and Business Email Compromise.
By always sending DMARC compliant email, the operator of an Internet domain can tell the world “everything I send is easy to identify using DMARC—feel free to drop fake email that pretends to be me.”
DMARC’s utility as an anti-spoofing technology stems from a significant innovation; instead of attempting to filter out malicious email, why not provide operators with a way to easily identify legitimate email? DMARC’s promise is to replace the fundamentally flawed “filter out bad” email security model with a “filter in good” model.
If you’re curious about the health of your domain or anyone’s, use this free Domain Checker for a quick check. It inspects DMARC, SPF and DKIM and tells you which actions you need to take to reach compliance.
Benefits of DMARC
If you use email, you’ll benefit by incorporating DMARC.
When strong security controls are deployed against fraudulent email, delivery is simplified, brand reliability increases and visibility is granted to domain owners on how their domains are being used around the Internet.
Security Disallow unauthorized use of your email domain to protect people from spam, fraud, and phishing.
Visibility Gain visibility into who and what across the Internet is sending email using your email domain.
Delivery Use the same modern plumbing that mega companies use to deliver email.
Identity Make your email easy to identify across the huge and growing footprint of DMARC-capable receivers.
If you are interested in a fully managed email security, domain alignment, Dmarc service
Sender Policy Framework (SPF) is used to authenticate the sender of an email. With an SPF record in place, Internet Service Providers can verify that a mail server is authorized to send email for a specific domain. An SPF record is a DNS TXT record containing a list of the IP addresses that are allowed to send email on behalf of your domain.
How does SPF work?
To take advantage of SPF, you publish an SPF record in the DNS. The record is a list of all the IP addresses that are allowed to send email on behalf of the domain.
The SPF mechanism uses the domain in the return-path address to identify the SPF record. When a sender tries to hand-off an email to an email “receiving” server for delivery, the server checks to see if the sender is on the domain’s list of allowed senders. If so, then a link has been established between the piece of email and the email domain. If not, then the server continues processing the email as usual without this link, as any number of things could be going on.
The email might be real, but the list of senders might not be accurate. Real email might have been forwarded which means the email could have come from anywhere and the list of allowed senders doesn’t help too much. Or, the email is fake and unwanted. Too many possible outcomes makes it difficult to attach meaning to the absence of the link that SPF can provide. DKIM fills the gap in the DMARC technical framework as an additional way to try and link a piece of email back to a domain.
Already have an SPF record? We have also developed a comprehensive guide to SPF record formatting to increase your understanding and help troubleshoot any SPF issues that our free SPF Surveyor may bring to your attention: SPF Record Syntax
SPF and DMARC for Email
By itself, SPF can associate a piece of email with a domain. With the DNS records in place, DMARC ties the results of SPF to the content of email, specifically to the domain found in the return path or From: header of an email. For SPF to work correctly in the context of DMARC, the return-path address has to be relevant to the domain of the From: header, which is the item that ties together DMARC alignment.
Why is SPF Important?
SPF has become exceedingly vital to help verify which sending infrastructure can relay email on behalf of your domain. Implementing SPF for email provides major benefits:
Increases domain reputation and email deliverability.
Fights domain impersonation and email spoofing to protect your brand reputation.
One of the foundational methods of email authentication for DMARC.
How do I check my SPF Record?
Check your domain’s SPF settings – dmarcian’s SPF Surveyor is an SPF diagnostic tool that presents a graphical view of SPF records. It allows you to quickly identify which servers are authorized to send on behalf of a domain.
Why SPF-Only Isn’t Safe Enough
Though SPF is a layer of proven email authentication that has been around since the late 1990s, it does have its challenges. Simply put, forwarding of email happens on the Internet and the SPF mechanism doesn’t survive the forwarding process. Forwarding typically happens when you send email to [email protected] and that person has set their email to be forwarded to another address, like [email protected] In this example, your email appears to be coming out of infrastructure that appears to have nothing to do with you.
DKIM signing can survive forwarding. If your domain is covered with DKIM, dmarcian’s ability to detect forwarding increases. SPF does not work in the context of forwarding, as SPF is simply a list of servers that are authorized to send on behalf of your domain, and it isn’t possible for a domain owner to maintain a list of forwarders.
Companies often misunderstand how SPF works and instruct their customers to include the company’s own SPF record. However, this ends up doing nothing if the company uses its own domain in the bounce address. When an email receiver processes a piece of email, it will look at the company’s SPF record—not the SPF record of the customer.
Two unwanted things happen because of this misconception:
Unnecessary “includes” are added into their SPF records. This causes SPF records to bloat and introduces management challenges.
Confusion is introduced as people just want to get SPF into place to complete their DMARC deployment. The result is that SPF passes, but DMARC fails.
For SPF to work correctly in the context of DMARC, the bounce address has to be relevant to the domain of the From: header. Unfortunately, many companies that send email on behalf of others do not currently allow their customers to change the bounce address to the customer’s domain. This is slowly changing, but companies first have to understand the basics of how SPF works. We have resources available to help companies send DMARC compliant email on behalf of others.
Note: There is obsolete technology called SenderID that tried to perform SPF-like checks, except it used the From: header domain (among others) as the item to check. SenderID also attempted to reuse existing SPF records, causing even more confusion.