Welcome to Red Sift’s ultimate technical guide on email protocol configuration. Designed for email security architects and analysts, this comprehensive handbook explores SPF, DKIM, DMARC, MTA-STS, and more, offering insights and practical tips for enhancing your email security posture. 

Beyond addressing common queries and troubleshooting challenges, this guide also offers comprehensive DNS setup instructions for various email service providers. 

As we journey through the chapters, you'll discover the critical role each email security protocol plays, how they collaborate to ensure email authenticity, and actionable strategies to optimize your organization's email security posture.

If you are looking for a less technical, more high-level guide, visit our Email Security Guide, perfect for beginners looking to understand more about email security, as well as buyers who need guidance on how to choose a DMARC vendor.

Designed for email security architects and analysts, this comprehensive handbook explores SPF, DKIM, DMARC, MTA-STS, and more, offering insights and practical tips for enhancing your email security posture. 

Red Sift’s Technical Email Configuration Guide

Introduction

All you need to know about SPF, DKIM and DMARC

In this chapter, we’ve answered some of the most common questions our Customer Success Engineers are asked about SPF, DKIM, and DMARC - the three pillars of modern email authentication. Let’s dive in!

SPF (Sender Policy Framework) is an email authentication standard that was developed to combat sender address forgery. By verifying the authenticity of the MAIL FROM or HELO/EHLO identities during transmission, SPF compares the sending server's IP address against a list of authorized senders specified in a TXT record within the domain owner's DNS. If the sending IP address aligns with the authorized list, SPF authentication succeeds. 

Which part of the email does the SPF protocol focus on?

SPF focuses on the "domain" found in the email header, known by various names such as Return-Path, MAIL-FROM, Bounce address, or Envelope from. If this header is missing, SPF falls back and looks at the “HELO/EHLO” hostname and checks for an SPF record there.

The Return-Path header is a technical header that is not visible to the end user - unless they know how to display the headers of an email in their mail client they won't see it. 

DKIM (DomainKeys Identified Mail) is used to sign different header fields and bodies to authenticate the sending domain and prevent message modification during transit.

It achieves this by using asymmetric cryptography which consists of a combination of public and private keys. The private key is private to the sender’s domain and is used to sign the emails. The public key is published in the sender’s DNS so it can be retrieved by anyone receiving messages from the sender.

When an email is composed, its headers and body are signed using the private key of the sender to create a digital signature, which is also sent as a header field along with the email. On the receiver’s side (if DKIM is enabled), the server retrieves the public key and verifies if the email was indeed signed by the sending domain. If the signature is successfully validated that proves that the sending domain sent the message and also that the headers and body of the message have not been modified during transmission.

Which part of the email does the DKIM protocol focus on?

DKIM focuses on the “DKIM-Signature” header.

As is the case with SPF,  this header is not visible to the end user unless they know how to display the headers of the email they have received.

While DKIM can verify that an email isn't the exact email that was sent, and SPF can recommend that a receiving server should reject an email based on the IP, neither of these are effective at spoofing prevention.

The main reason for this is the header that is checked for each protocol.

SPF checks the record found at the domain in the return-path header, and DKIM checks the key found at the d= domain (Found within the DKIM header).

Both of the above protocols can be set to check any domain.

In an email, the major domain of the sender is the domain found in the From: header, this header determines the big name at the top of emails - the address that the end-user will see if they check who sent the email.

Given the above, your email domain could be impersonated as attackers could make the From: yourdomain.com and the return-path and d= theirdomain.com.
Provided the SPF and DKIM records at theirdomain.com were correctly configured, the email would pass both SPF and DKIM resulting in a successfully impersonated domain..

SPF and DKIM have their purposes, but neither alone are enough to prevent imitation.

DMARC stands for Domain-based Message Authentication, Reporting and Conformance and builds upon SPF and DKIM, providing an additional layer of email authentication and policy enforcement. 

It takes into account the results from SPF and DKIM 

For DMARC to pass, it requires SPF or DKIM to pass and for the domain used by either one to also align with the domain found in the From: address. If you’re interested in learning more about Identifier Alignment, click here.

It reports SPF, DKIM, and DMARC results back to the domain found in the From: address (ie. sender).

Finally, it tells receivers how to treat emails that fail DMARC validation by specifying a policy in DNS.

By setting the DMARC policy to p=reject an organization can recommend to receiving servers to drop any emails set on behalf of their domain that don't pass the alignment check. This will stop all imitation attempts where the receiving server is correctly implementing DMARC.

Which part of the email does the DMARC protocol focus on?

DMARC focuses on the domain found in the From: or Header from header which is visible to the end user. 

Now that we know what headers each protocol looks at, what is contained in those headers, and what is checked?

SPF verifies if an email was sent by an authorized sender by checking a list of authorized IP addresses you publish in your DNS. The receiving server will take the domain found in the Return-Path header and check for an existing SPF record. It checks the SPF record to see if the sending IP address of the email is contained in the SPF record. If the IP address is contained in the SPF record that means that it is authorized to send emails. This means that SPF PASSED. If the IP address is not in the SPF record then SPF FAILS.

If the sending IP address is contained in the SPF record = SPF PASS

If the sending IP address is not contained in the SPF record = SPF FAIL

The receiving server will check the DKIM-Signature header which contains the selector (s=) and signing domain (d=) which are tags used to look up the public key. Once retrieved, the public key is used to validate the email message. If validation is successful then DKIM PASSES and if the validation process is unsuccessful then DKIM FAILS.

If validation is unsuccessful = DKIM FAIL

DMARC (Domain-based Message Authentication, Reporting & Conformance) 

The receiving server will check if either SPF or DKIM PASSED, then it will check if the Return-Path domain used by SPF and/or the d= domain used by DKIM aligns with From: domain, and finally, it will extract the DMARC policy published by the domain found in the “From” address and comply with the policy.

If SPF PASSED and ALIGNED with the “From” domain = DMARC PASS, or

If DKIM PASSED and ALIGNED with the “From” domain = DMARC PASS

DMARC not only requires that SPF or DKIM PASS, but it also requires the domains used by either one of those two protocols to ALIGN with the domain found in the 

“From” address. Only then will DMARC PASS.

What’s the difference between Strict vs Relaxed alignment?

Strict alignment means that the Return-Path domain or the signing domain “d=” must be an exact match with the domain in the “From” address.

Relaxed alignment means that the Return-Path domain or the signing domain “d=” can be a subdomain of the “From” address and vice versa.

If you’re interested in learning more about Identifier Alignment, click here.

If DMARC fails, the receiving server would typically comply with the policy that you have specified in your DMARC record.

If you are in report-only mode (p=none) the email will be accepted by the receiving server and scanned by other filtering criteria.

If you are in quarantine mode (p=quarantine) the email will be quarantined and typically sent to the spam folder of the recipient.

If you are in reject mode (p=reject) the receiving server will abort the connection with the sending mail server and the email will never reach the end user.

Irrespective of the policy, the metadata for the email will be logged along with the status of the authentication results and forwarded to your DMARC report processor. Learn more about DMARC reports here.

Make sure that you have an SPF record in your Return-Path domain.

Make sure that you have an SPF record in your HELO/EHLO domain in case of bounces where the Return-Path domain is empty.

Make sure there is a single SPF record per domain.

Make sure that the SPF record syntax is correct.

Make sure that your Return-Path domain aligns with the From domain.

Make sure that your authorized senders are part of the SPF record.

Make sure that unauthorized senders are not in your SPF record.

Make sure that you do not go over the 10 DNS lookup limit imposed by SPF. If you have gone over the 10 DNS lookup limit you will have to consider using a feature such as Red Sift’s OnDMARC’s Dynamic SPF.

Make sure that deprecated SPF record mechanisms such as the “ptr” mechanism are not used in your SPF record.

Make sure that the sending systems you use support DKIM.

Make sure that the emails are DKIM signed.

Make sure that the signing domain aligns with the “From” domain.

Make sure that you use a DKIM key size over 1024 bits (a 2048-bit key is advisable)

Make sure, where possible, that the DKIM selectors you choose closely identify the sending service so you can distinguish between them.

Make sure to revoke any keys that have been compromised.

Make sure that the DKIM keys you manage are rotated regularly.

Make sure that the DKIM key syntax is correct.

Make sure that there exists a public key for each corresponding private key that signs your emails.

As DMARC is based on both SPF and DKIM and the domains used by those two protocols, you will have to make sure that the Return-Path domain for SPF is either an exact match or a subdomain of the “From” domain. The same applies to the signing domain used by DKIM.

Make sure that the DMARC record syntax is correct.

Make sure that you have configured all of your systems correctly with SPF and DKIM before moving to a reject policy as your emails will be lost.

Make sure that you use a system or third-party provider such as Red Sift OnDMARC to receive DMARC reports so that you can make sense of those reports and discover any systems that are misconfigured.

Monitor the status of each of your sending sources and make sure that any changes to SPF and DKIM are identified. Red Sift OnDMARC has this feature as a core part of its product.

I have SPF, do I need DMARC to protect my domain? What does DMARC do that SPF does not?

SPF authorizes the sending IPv4/IPv6 addresses.

SPF protects the header of the email that is not visible to the end-user (known as Return-Path, MAIL FROM, "Envelope From", or Bounce address). If this header is missing, the SPF check will be done on the EHLO/HELO address.

SPF does not require any alignment between the From domain and the above-mentioned Return-Path address that it checks, meaning the two don't have to match from an SPF perspective.

SPF does not provide any reporting functionality, meaning the receiver of the email won't send back any reports to the sender, containing results of the email authentication.

SPF does not survive auto-forwarding and indirect mail-flows.

These shortcomings prompted the introduction of DMARC to explicitly tell receivers what to do and provide authentication reports. These reports enabled the sender to take the necessary actions to fix legitimate mail flows.

DMARC makes use of SPF as one of its foundations but also adds additional features as it:

Focuses on the From header which is visible to the end user ("Header From").

Requires that the domain used by SPF aligns (either an exact match or subdomain) with the domain found in the visible From address of the email.

Ignores the nuances of soft fail and hard fail in your SPF configuration i.e. ~all and -all are treated equivalently as an SPF fail.

Provides the reporting functionality to send email authentication results back to the owner of the From so they can find out if their domain is being misused. It also helps with troubleshooting your deliverability as the reporting will aid in discovering any misconfiguration with your legitimate email senders. 

Provides a policy that tells the receivers what to do with an email that fails email authentication. This policy is enforced by the receivers. There is no enforcement when SPF is used without DMARC.

Some mailbox providers have started using visual signs in their mail clients to show if an email is authenticated. For example, Gmail displays a question mark (?) for unauthenticated emails - see the example below.

An include is an SPF mechanism that points to a domain to be queried when checking if the sending IP is allowed or not. If the sending IP is part of the include then it results in a match and SPF passes. 

For example, if you have include:_spf.google.com as part of your SPF record and the originating IP of an email is Google’s IP, it will result in a match as you have authorized Google to send on your behalf and the sending IP is found inside of the include mechanism.

An SPF macro refers to a mechanism used in SPF records to define reusable sets of IP addresses. SPF macros enhance the flexibility and maintainability of SPF records by allowing you to define complex sets of IP addresses in a single mechanism, which can then be referenced within multiple SPF records. This can make it easier to manage large sets of authorized sending servers without duplicating the same information in multiple places.

For example, instead of listing individual IP addresses for each authorized email server in your SPF record, you can define a macro like this:

@spf.salesforce.com IN TXT "v=spf1 exists:%{i}.spf.mta.salesforce.com -all" 


In this example, the macro is the %{i} mechanism, which calls the sender IP of the email. This means the domain becomes something like 233.124.65.65._spf.mta.salesforce.com. 

Managing SPF this way allows you to control a large list of IPs without hitting the SPF lookup limit, and also obscures which IPs you approve for public querying.

The risk with SPF macros is that the majority of legacy email infrastructures do not support them, causing catastrophic deliverability issues. We know from technical studies and our own experience that only about 75% of SMTP servers get macros right.

If an email server does not support SPF macros, the behavior can vary as follows:

If the receiving email server does not support SPF macros, it will not expand or process any macros referenced in the SPF record. Instead, it will treat the macro reference as a literal string. This means that the SPF record effectively loses its intended functionality, potentially leading to incomplete or inaccurate SPF checks. Though macros aren’t used in production SPF records, the no expansion behavior is used in email servers like iCloud. 

Depending on how the SPF record with macros is structured, the lack of macro expansion could result in SPF failures or 'Neutral' results (denoted by the ?all mechanism). In either case, it might not have the desired effect of properly authorizing legitimate sending servers.

If the SPF macros play a critical role in authorizing legitimate sending servers, emails might be more likely to fail SPF checks or be marked as suspicious by email receivers that rely on SPF for authentication.

Learn why you need SPF as well as DKIM and DMARC, what include statements are, and the problem with macros.

Learn more about SPF

An SPF failure occurs when the sender's IP address is not found in the SPF record published. Failures significantly affect the deliverability of your email as they result in the email being sent to spam or discarded altogether. This can be catastrophic for businesses that rely on email to reach customers.

There are two types of SPF failures - SPF softfail and SPF hardfail. A hardfail indicates that an email is not authorized, whereas a softfail means that an email has probably not been authorized. For the email recipient, it determines the treatment of the email; a hardfail tells the recipient to reject the email, whereas a softfail suggests it should be diverted to spam.

We will use two examples to demonstrate the visual difference between both.

In the above example, the minus symbol (in front of all at the end of the record) means that any senders not listed in this SPF record should be treated as a hardfail, ie. they are unauthorized, and emails from them should be discarded. In this case, only the IP address 192.168.0.1 is authorized to send emails and nothing else.

v=spf1 include:spf.protection.outlook.com ~all

In the above example, the tilde symbol (in front of all at the end of the record) means that any senders not listed in this SPF record should be treated as a softfail, i.e. mail can be allowed through but should be tagged as spam or suspicious. In this case, the include:spf.protection.outook.com mechanism authorized Microsoft 365 to send emails. Any emails originating from different servers should be marked as spam by the receivers. 

Given that hardfail ("-all") signals to reject any unauthorized senders not found in the SPF record, it might seem like the mode of choice. However, the decision is more nuanced.

In a pre-DMARC era, SPF records commonly used the "-all" mechanism to strictly enforce sender policies, without the additional layer of DKIM and DMARC to help authenticate legitimate emails.

However, modern guidance now favors "~all" to balance security and deliverability, avoiding unnecessary rejection of valid emails that might fail SPF but pass DKIM and DMARC.

The wider industry echoes that care needs to be taken with SPF modes; the DMARC specification (RFC 7489) states that:

“Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this.”

For these reasons, we would suggest the following

Use "-all" for inactive, non-email sending domains: Apply "-all" only if the domain sends no emails at all. This setting strictly blocks unauthorized emails but risks rejecting legitimate ones if the SPF record isn’t up-to-date.

Use "~all" for active, email-sending domains: Opt for "~all" if you’re using SPF in combination with DKIM and DMARC to combat phishing and spoofing. This is because “~all” - when implemented in combination with DMARC (at p=reject) - will still reject unauthenticated mail if SPF and DKIM fail. This mode does not block legitimate mail, thus enhancing overall email deliverability.

In summary, softfail strikes a balance between strict security (which might block legitimate emails) and allowing some flexibility in email delivery, ensuring that emails can still be delivered even if there are occasional mismatches in the SPF record.

How is SPF softfail treated by cybersecurity rating companies? 

It is possible that some rating companies may penalize you should your domains be set up with SPF softfail. However, we believe that downgrading a domain's security score based on the presence of a softfail can misrepresent the actual risk profile of the domain and inadvertently penalize organizations that are following industry-recommended practices for responsible email management and security.

On the other hand, rating services like Security Scorecard acknowledge DMARC (when set up in a policy of quarantine or reject) is a “compensating” control for SPF softfail.

If you are penalized for implementing SPF softfail in a cybersecurity audit, engage with the rating company directly to explain your email authentication strategy and its alignment with industry best practices. Advocate for a more nuanced approach to evaluating security postures, one that considers the full context of your email security measures rather than penalizing specific configurations in isolation.

Why SPF isn't enough and you still need DMARC

Irrespective of which failure mode you specify in your SPF record, receiving servers are unlikely to honor your requested policy. This is because SPF is limited in that:

It does not require alignment between the domain in the From field and the Return-Path address it checks. They don't have to match from an SPF perspective.

SPF does not provide reporting functionality, meaning the receiver does not send back reports to the sender containing email authentication results.

SPF does not survive auto-forwarding and indirect mail-flows, which can lead to authentication issues.

Due to these limitations, DMARC (Domain-based Message Authentication, Reporting, and Conformance) was introduced as an additional email authentication standard. DMARC addresses the shortcomings of SPF and provides the following enhancements:

DMARC focuses on the visible From header, which is seen by end-users.

DMARC requires alignment between the domain used by SPF and the visible From address in the email.

DMARC ignores the nuances of soft fail and hard fail in SPF configuration, treating them as SPF failures.

DMARC provides reporting functionality, allowing email authentication results to be sent back to the owner of the From domain. This helps identify domain misuse and troubleshoot any misconfigurations with legitimate email senders.

DMARC includes a policy that instructs receivers on how to handle emails that fail authentication, and receivers enforce this policy. In contrast, SPF alone does not have enforcement mechanisms.

DMARC has gained widespread adoption as an authentication requirement as it overcomes the shortcomings of SPF and DKIM, blocks exact email impersonation, and improves email deliverability.

There are two types of SPF failures - SPF softfail and SPF hardfail. A hardfail indicates that an email is not authorized, whereas a softfail means that an email has probably not been authorized.

SPF failures: Hard fail vs Soft fail

You can rotate DKIM keys by simply replacing the old pair with a new one to authenticate DKIM emails. If a threat actor steals or deciphers your private key, they won’t be able to use it for long if you practice regular DKIM key rotation.

In addition, regularly updating your DKIM keys increases your domain’s email deliverability rate.

It’s generally suggested to rotate DKIM keys every 6 to 12 months. Frequent rotation stops hackers from intercepting and decoding your cryptographic keys. Less frequent rotation (say, once every couple of years) makes your domain more susceptible to the risk of intercepted or decoded keys.

Some DNS editors can receive errors when DKIM keys or other TXT entries are longer than 255 characters.
To resolve this issue, you can enter your DKIM key by breaking it up into pieces on a single TXT entry.

"v=DKIM1; k=rsa; p=abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabc"

"v=DKIM1; k=rsa; p=abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabc"


You can divide them at arbitrary places. The double quote enclosed parts should be separated by a single space character, not a new line.

Canonicalization is a process whereby the headers and body of an email are converted to a canonical standard form before being DKIM signed. This can be thought of as converting data into a standard canonical form.

Some mail systems, such as forwarders, modify emails in transit that can potentially invalidate the DKIM signature applied. While some DKIM signers may accept minor mail modifications, others may be more strict and require stricter canonicalization.

Two canonicalization algorithms have been created to satisfy mild modification to a message and almost no modification to a message before signing. The two canonicalization algorithms are relaxed and simple respectively. 

From DKIM’s perspective, the headers and body of an email are separate and canonicalization algorithms are specified for both, one for the headers and another for the body.

They are represented in the format of canonicalization/canonicalization for the header and body respectively. If no canonicalization is specified then simple is used for both headers and body, so it would look like this: simple/simple.

The simple/simple canonicalization is the stricter of the two and allows for almost no modification to the message header and body. However, this can affect the DKIM signature being invalidated by some forwarders as the email passes through them. Many of the issues with DKIM being invalidated during forwarding can be solved if the canonicalization is changed to relaxed/relaxed to allow for mild modifications to the emails.

A DKIM selector is a string that points to a specific DKIM public key record in your DNS. It is specified as s= tag in the DKIM-Signature header field and can be found in the technical headers of an email.

Validation on the receiver side uses the selector in combination with the signing domain in order to carry out a DNS query and find the public key in your DNS. 


When the receiver retrieves the public key it uses it to verify the DKIM signature.

No two services should use the same selector. For example, if you are sending emails from a number of services on behalf of your domain such as Google, Mailchimp, Salesforce, and Sendgrid, each one must use a unique key and selector in your DNS. If the selectors were the same the recipient would not be able to tell which key to use to decipher a particular email. 

The l= tag in DKIM specifies the length of the message body that should be included in the DKIM hashing and signing process. This means that only the specified portion of the message body is signed, while the remainder is not included in the cryptographic signature.

This tag is optional. If it is not used, the entire message body is included in the signature by default.

What are the security concerns around using the l= tag in DKIM?

When the l= tag is used in DKIM, only a specified portion of the message body is included in the cryptographic signature, leaving the rest unsigned. This creates a security risk, as attackers can modify the unsigned portion of the message without invalidating the DKIM signature.

This vulnerability means that an attacker could intercept a legitimate email from a reputable sender, append malicious content to the unsigned part of the message, and resend it to a recipient who trusts the sender. Such an attack could damage the reputation of the sending domain and potentially deceive recipients.

To mitigate this risk, it is recommended not to use the l= tag in your DKIM signing process. Additionally, audit your vendors to ensure they are not including this tag when sending emails on your behalf. 

DKIM is used to sign specific headers or parts of the email body, such as the "From," "Subject," and other headers, to verify the identity of the sender and ensure the integrity of the message. If a signed header is modified after being sent, the DKIM verification will fail.

Attackers may attempt to inject additional headers into an email or modify existing ones for malicious purposes. Oversigning common headers, such as "From," "Subject," "Reply-To," etc., can help protect your emails from manipulation and replay attacks. Oversigning means that you include multiple instances of the same header, effectively signing each one to prevent tampering.

By sending a test email to Red Sift’s Investigate tool, you will be able to see what headers are DKIM signed in your email and if you are oversigning. 

A DKIM replay attack is a type of email attack in which an attacker takes a legitimate, DKIM-signed email and resends it to multiple recipients. The attacker exploits the DKIM signature, which verifies the email's authenticity and integrity, to benefit from the original sender's reputation. This increases the likelihood that the replayed email will bypass spam filters and land in the recipients' inboxes, as it appears to come from a trusted source.

DKIM helps with forwarded mail by providing a mechanism to verify the authenticity and integrity of an email, even after it has been forwarded. Forwarding can often alter email headers, which can cause issues with other email authentication methods like SPF (Sender Policy Framework).

Without DKIM, forwarded emails may fail to reach the recipient's inbox, especially if the sender's domain is protected by a strict DMARC (Domain-based Message Authentication, Reporting, and Conformance) policy. This is because SPF authentication often fails during forwarding, and without both SPF and DKIM, a DMARC policy of p=reject will instruct the recipient's server to reject the email.

It is strongly advised not to set a DMARC policy of "reject" without first implementing an aligned DKIM signature for all your email sending systems. This ensures that at least one authentication mechanism remains intact when SPF fails.

However, it's important to note that DKIM can also fail when an email is forwarded, particularly if the forwarder modifies any of the DKIM-signed headers or the body of the email. This can happen due to email security gateways, external disclaimer banners, or other modifications introduced during the forwarding process.

Can an email contain more than one DKIM signature i.e. be DKIM signed multiple times? 

Yes, an email can contain multiple DKIM signatures, and this is quite normal. This typically occurs when an email passes through different systems that each apply their own DKIM signature. For example, an email service provider (ESP) might add a DKIM signature to track reputation feedback, and another DKIM signature might be added when the email is sent from one system to another on its way out to the internet. If both systems are configured to DKIM sign emails, the email will end up with multiple DKIM signatures.

It's important to note that one of the signatures may fail (often the first one, if the email is modified between the initial and subsequent signing), but as long as at least one signature passes verification, the DKIM check will be considered successful.

How does ARC come into play when DKIM or DMARC fail? 

As mentioned earlier, DKIM may fail when an email is forwarded. ARC (Authenticated Received Chain) addresses the limitations of DKIM and DMARC in scenarios involving email forwarding and mailing lists by preserving the original authentication results through a sequence of cryptographic signatures, creating a chain of custody.

ARC helps ensure that legitimate emails can be trusted and delivered, even if modifications by intermediaries cause DKIM or DMARC failures. It does this by allowing the forwarding server to attest to the original authentication results and the integrity of the message when it was first received.

However, the use of ARC relies on the email forwarder to implement it, establishing this chain of custody. Even if an email passes ARC, it does not necessarily guarantee that the email will be trusted or delivered to the recipient's inbox. The final decision lies with the receiving system, which determines whether to trust the established chain of custody.


Using Weak or Deprecated Cryptographic Algorithms: Avoid using DKIM keys that are less than 1024 bits. A 2048-bit key is recommended for stronger security. Additionally, ensure you use up-to-date cryptographic algorithms, such as rsa-sha256.

Not Splitting Longer Keys Correctly in DNS: When publishing a 2048-bit key in DNS, it may be necessary to split the key into multiple DNS records if your DNS host does not automatically handle this. Failure to do so can result in DKIM verification failures. Refer to the specific guidance or examples provided for splitting keys correctly.

Enabling DKIM in a Third-Party System Without Publishing the Corresponding Public Key: DKIM relies on a private/public key pair. The sender (e.g., a third-party vendor) holds the private key, which is used to sign outgoing emails. It is crucial to publish the corresponding public key in your domain's DNS records, provided by the vendor, to enable proper DKIM verification.

Missing Required Tags in a DKIM Record: Ensure that your DKIM record begins with v=DKIM1;. This is a required tag that identifies the record as a DKIM record.

Using the Wrong Record Type: Make sure to publish your DKIM record using the correct DNS record type, such as TXT or CNAME, as specified by the third-party sender. Some providers may require a TXT record for DKIM, while others might use CNAME. Additionally, some vendors, like Microsoft 365 or Amazon SES, may provide multiple DKIM records to facilitate easy key rotation and management.


Use strong keys (at least 1024-bit) and up-to-date algorithms.

Implement DMARC with DKIM for better insight and protection.


Generating 2048 bits DKIM public and private keys using OpenSSL on a Mac

Learn how to generate 2048 bits DKIM public and private keys using the Mac terminal and create a DNS record.

How to generate the private and public keys

To generate a private key type: openssl genrsa -out private.key 2048

To generate a public key from the private key type: openssl rsa -in private.key -pubout -out public.key

Find the folder that contains your public key and open it. It should look something like the image below.

Manually convert the highlighted text above to a single line ie. remove the spaces between new lines.

The generated 2048-bit DKIM public key is too long to fit into a single TXT DNS record. A DNS record can be up to 255 characters. Therefore your public key will need to be split into two separate TXT records using quotes and slash or brackets and quotes as shown below. 

To create the DNS record you will have to specify the Name, Type, and Value of the DNS record.

The DNS record Name will look like this: 


Where the selector is defined by you and can be called anything, for example, the date, device, or service that will sign the emails.

The DNS record Value should look like the examples below. The part in bold is copied from the generated public key file and remember that you will need to split the public key into two records.

“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmC”

“Lrt5j82yBC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB”

(“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmC”

“Lrt5j82yBC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB”)

Learn why you need DKIM as well as SPF and DKIM, what DKIM key rotation is, and get tips on technical configuration.