Understanding email authentication
You will learn
Learn about email authentication protocols that are used to build your sender reputation, validate emails are coming from a legitimate sender, and protect against email abuse.
Most inbox providers enforce sender requirements for bulk senders. Setting up DMARC authentication is a key part of meeting those requirements, especially for high-volume senders. As a reference point, Google considers anyone sending 5,000 or more daily emails to Gmail recipients a "bulk sender."
About email authentication
“Email authentication” refers to the technical standards that allow for the verification of an email sender's identity. The most commonly used email authentication standards are SPF, DKIM, and DMARC. Mail servers use these authentication protocols to verify that incoming emails are from legitimate senders, protecting your brand and your customers from malicious actors. In addition to preventing phishing and spoofing attempts, implementing these protocols can help improve deliverability, as mailbox providers will be able to confirm the identity of the sender.
SPF
Sender Policy Framework (SPF) is an email authentication method designed to detect forged sender addresses during the delivery of the email. SPF allows the receiving mail server to verify that emails coming from a specific domain were sent through an IP address authorized by that domain's administrators.
When an email is sent from an IP address that has not been allowed through SPF, the receiving mail server may reject the email, or divert it away from the primary inbox. Without SPF records you could not authenticate IPs using your sending domain, allowing malicious actors to easily impersonate your brand.
On Klaviyo's shared sending domain, emails are automatically authenticated through SPF. If you are using your own branded sending domain in Klaviyo, the necessary SPF record is automatically added through the CNAME or NS records added during setup.
DKIM
DomainKeys Identified Mail (DKIM) acts as a digital signature that is added to the header of an email to further verify the identity of the sender. Receiving email servers verify the signature using a public key published for the signing domain. DKIM can remain valid when an email is forwarded, as long as the signed content is not changed in a way that invalidates the signature.
On Klaviyo's shared sending domain, emails are automatically authenticated through DKIM. If you are using your own branded sending domain in Klaviyo, the necessary DKIM record is automatically added through the CNAME or NS records added during setup.
DMARC
DMARC stands for domain-based message authentication, reporting, and conformance. It is a protocol that uses SPF and DKIM to determine the authenticity of an email, giving domain owners the ability to protect their domain from unauthorized use.
DMARC provides instructions to receiving servers about how to handle incoming mail. To pass DMARC, a message must pass SPF or DKIM authentication, and the domain authenticated by that method must align with the domain in the from-address. Passing both methods is not required for DMARC, although inbox providers can require you to set up both SPF and DKIM. Messages that fail DMARC checks can be allowed, rejected, or placed in the spam folder, depending on the domain’s policy and the receiving server’s rules.
Implementing a DMARC policy on your domain can help protect you from spoofing, limiting your brand’s and recipients' exposure to potentially fraudulent and harmful messages.
Example DMARC policy
DMARC is an email authentication, policy, and reporting protocol that impacts any email sending from your brand, beyond just Klaviyo. Please note that it is important to work with your IT team or a 3rd party professional to implement a DMARC policy that best suits your brand’s needs.
Below is an example of what a simple DMARC record may look like, and how different records impact email delivery.
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbrand.com
It is common for the sp tag to be omitted in a DMARC record, in which case the sp tag defaults to the value of the p tag.
While DMARC policies can have a number of tags with different functions, the p and sp policy tags are the most important when it comes to Klaviyo and your email marketing.
The values of these 2 tags tell the inbox providers how they should react when the alignment checks fail. When used in from-email addresses, the p tag applies to the root domain (e.g., @yourbrand.com) while the sp tag applies to the subdomains (e.g.,@shop.yourbrand.com). If a subdomain has its own DMARC record, that record’s policy takes precedence for mail sent from that subdomain.
Meanwhile, the rua tag in the example determines the inbox DMARC reports will be mailed to. This tag is recommended, but not required.
Make sure to swap out the placeholder email address above (i.e., dmarc-reports@yourbrand.com) with an inbox that is prepared to receive DMARC reports if you plan to use the rua tag.
Value for p/sp tag | Requested handling of email that fails DMARC |
p=none | Request no action based on DMARC failure. Other spam filtering still applies. |
p=quarantine | Request that the email be treated as suspicious, such as placing it in spam. |
p=reject | Request that the email be rejected. |
A DMARC policy is placed as a TXT record on a domain's DNS control panel, but needs to follow specific syntax rules.
How p and sp tags impact sending on Klaviyo
When sending on a shared sending domain, the domain in your from-address (e.g., marketing@yourbrand.com) does not align with Klaviyo’s sending domain (e.g., ksdn.klaviyomail.com). DMARC uses the policy for your from-address domain. A policy on Klaviyo’s shared domain does not override your brand’s policy or make your emails pass DMARC.
A branded sending domain lets you align the domain used for DKIM authentication with your from-address domain. DMARC passes when DKIM authentication succeeds and that domain aligns with your from-address. Under the default relaxed alignment setting, the domains can share a root domain. Strict alignment requires an exact domain match.
rua tags and DMARC reporting
The rua tag in a DMARC record allows for the associated email address to receive DMARC reports in .xml format. These reports are difficult and tedious to interpret, so Klaviyo recommends working with a DMARC service provider if you plan to use the rua tag for DMARC reporting. These providers help to process the .xml DMARC reports, and present them so your brand can more easily gather insights.
To receive DMARC reports at an address on a different root domain, the owner of the domain receiving the reports must authorize them with a TXT record in that domain’s DNS. Follow your DMARC service provider’s instructions for this authorization, and set the reporting address in your own DMARC record’s rua tag.
Example DMARC report
Some examples of DMARC providers Klaviyo recommends are:
Configuring email authentication
When sending emails with Klaviyo, you do not need to add your own SPF and DKIM records. If you are sending on Klaviyo’s shared sending domain, the necessary records have already been set to pass authentication. With a branded sending domain (also known as a dedicated sending domain), the Klaviyo NS or CNAME records added during setup automatically enable DKIM and SPF authentication.
DMARC requires a separate TXT record in your domain’s DNS. During branded sending domain setup, Klaviyo offers Add DMARC record if your domain does not already have a DMARC record. This generates v=DMARC1; p=none. You can publish the records automatically with Connect with Entri for supported DNS providers, or choose Set up manually and add them at your DNS provider.
If your brand currently does not have a DMARC policy, configuring p=none is a first step toward meeting inbox provider requirements. It meets the DMARC policy requirement, but you still need to meet the provider’s other sender requirements. You can receive DMARC reports with p=none by adding a rua tag. Klaviyo recommends working with your IT team or a 3rd party professional before moving to a stricter policy to protect against spoofing.
You or someone on your team must have access to your domain’s DNS settings to publish the record, including when authorizing automatic setup through Entri. Choose your policy with your IT team or a DMARC service provider, because it affects mail sent from your domain outside Klaviyo as well.
Setting up DMARC in your DNS
To add a DMARC record manually, use your DNS provider’s settings. The steps below describe the general process; field names and instructions vary by provider.
- Log in to your domain’s DNS settings and check for an existing TXT record at
_dmarc.yourbrand.com(replaceyourbrand.comwith your domain). If a DMARC record already exists, review it with your IT team or DMARC service provider instead of adding a second record or replacing its policy withp=none. - If no DMARC record exists, create a new record with the following information:
- Type: TXT
- Host: _dmarc
- Value: v=DMARC1; p=none
The rua tag is optional and is used for DMARC reporting. To receive reports, use v=DMARC1; p=none; rua=mailto:email@yourbrand.com. Replace email@yourbrand.com with an inbox prepared to receive the reports.
- Save the record in your DNS provider. Once the DNS change has propagated, verify the record and check a sent email’s authentication results as described in Verifying your email authentication configuration.
The names of fields, interfaces, and processes to create a new record can vary across DNS providers. Some examples of DNS providers include GoDaddy and Namecheap, but there are many others.
For further instructions on how to set up DMARC for your domain, we recommend the following resources and services, or reaching out to your DNS provider.
- Understand how DMARC protects your domain reputation
- MXToolBox: How to setup DMARC
- DMARCian: Getting started with DMARC
- Valimail
Making your Klaviyo emails DMARC compliant
To make your Klaviyo emails DMARC compliant, set up and activate a branded sending domain that shares the root domain in your friendly-from email address (i.e., your from-address), and publish a DMARC record for your domain. For example, if you send an email using sales@yourbrand.com as the from-address and yourbrand.com is protected by DMARC, your account will need to use a branded sending domain like send.yourbrand.com to meet DMARC requirements.
Learn how to update your sender email address to align it with your branded sending domain.
Internal recipients
When using a shared domain to send emails to internal recipients, inbox providers may display a warning message and place emails in spam when the recipient's email address uses the same domain as the from-address.
For example, on Gmail:
This internal-recipient warning applies to recipients whose email addresses use your own from-address domain. An aligned branded sending domain can help resolve authentication-related warnings, but it does not guarantee inbox placement.
If you see a warning in a personal inbox, check the email headers to see whether DMARC is failing. If it is, make sure your branded sending domain is active and aligns with the domain in your sender email address (i.e., your from-address).
Verifying your email authentication configuration
To verify that the record has been published successfully, enter your from-address domain into the DMARC checker offered by EasyDMARC. Check that it finds a valid DMARC record with the policy you intended. A valid p=none record meets the DMARC policy requirement, but a DNS lookup alone does not verify that your emails pass DMARC or meet all inbox provider sender requirements. EasyDMARC shows a Warning status for p=none because it is not an enforcement policy. That is expected and still meets the DMARC policy requirement.
After checking your DNS record, verify authentication using the header of an email sent by your brand.
An email header contains metadata about an email and the network path it has taken. This includes information like from-address, subject line, recipient, and key authentication details such as whether SPF, DKIM, and DMARC are passing.
Moving to a more secure DMARC policy
While a DMARC policy of p=none meets the DMARC policy requirement, moving to a more secure policy can better protect your business from malicious actors.
Benefits of more secure policies
The main benefit of using p=quarantine or p=reject is that they ask inbox providers to keep messages that fail DMARC out of recipients’ main inboxes. p=none requests no action based on DMARC failure, so recipients may still receive emails from a malicious actor trying to impersonate your brand. If a user views a spoofed email that appears to have been sent from your brand, this can damage their trust in your brand’s email.
A policy of p=quarantine asks providers to treat failing emails as suspicious, such as placing them in spam. A policy of p=reject asks providers to reject them. The receiving provider makes the final delivery decision.
Other considerations
It is important to note that DMARC applies to any email sent from your brand, including those sent outside of Klaviyo. With a policy of p=none, no action is requested solely because an email fails DMARC, but other spam filtering still applies. However, the stricter DMARC policies can cause emails to not get delivered if your domains aren’t aligned across your business’s entire email sending infrastructure and use cases.
For this reason, Klaviyo recommends working with your IT team or a DMARC service provider to implement a policy that best fits the needs of your brand.
Additional resources
- How to set up a branded sending domain
Learn how to set up a branded sending domain (also known as a dedicated sending domain) so that when emails reach inbox providers, they will appear to come from your brand instead of Klaviyo.
- Understanding email deliverability
Learn about email deliverability, including the steps you can take to establish a strong sender reputation so that your emails are delivered to the inbox.
- Understand the domains that play a role in email deliverability
Learn about the different domains that play a role in the delivery of your emails, as well as the importance of domain alignment.