If I have the Klaviyo dedicated sending set up, the Klaviyo plugin installed in wooComm and the integration set up in Klaviyo can I use Klaviyo as my SMTP for native WooComm emails or do I still need a separate SMTP?
Hi @Nuetron! Thank you for your comment. The dedicated sending domain you set up on Klaviyo is only meant for your Klaviyo email sends. Your WooCommerce emails would still need to be sent on a separate SMTP.
Got it! Thanks for the prompt reply.
I’m currently adding the SPF/DKIM records to my domain for Google Workspace. Haven’t yet configured a dedicated sending domain through Klaviyo. Is there an spf record I can add for now to allow klaviyomail in addition to Google?
Hi @Drewdle81! Nope, we only make use of CNAME records to allow you to authenticate your Klaviyo account to send on your domain. The CNAME record will pass over the subdomain you plan on using to Klaviyo to take control off and send emails from. In doing so, we will automatically apply the necessary SPF and DKIM records onto that subdomain.
Hi @Drewdle81! Nope, we only make use of CNAME records to allow you to authenticate your Klaviyo account to send on your domain. The CNAME record will pass over the subdomain you plan on using to Klaviyo to take control off and send emails from. In doing so, we will automatically apply the necessary SPF and DKIM records onto that subdomain.
Thank you. Follow up question: Once I have completed the setup for Google Workspace SPF and DKIM for my domain, will my Klaviyo emails be adversely affected since they aren’t specified as a “permitted sender” in the SPF record? Or should that remain the same?
I will authenticate the domain through Klaviyo soon, but need to do it at a good time when I can go through the whole warm-up process.
Hi @Drewdle81! The SPF and DKIM records for your Google Workspace will not affect your sending on Klaviyo in anyway. However, if your domain currently have a DMARC policy in place, it will affect your unauthenticated Klaviyo email sends.
Hi @wei.he - question: what is an unauthenticated Klaviyo email send?
Working on an account that is about to set up SPF / DKIM in their Google workspace, and want to know how it’s going to impact their Klaviyo sends. (They’re on a shared domain.)
Hi @Page V, thank you for your question!
An unauthenticated email send is when your email’s From-Address domain does not align with the sending domain that it is sending on. For example, your From-Address is hello@domainA.com while your sending domain is send.domainB.com. This misalignment is often seen as potential spoofing as the sending domain is not authenticated to send on behalf of the From-Address domain and can result in filtering.
The SPF/DKIM that you set on your Google Workspace would not impact their Klaviyo send.
So if I want to use my TLD as I migrate from another ESP. Klaviyo does not allow that TLD to be authenticated with SPF/DKIM? You HAVE to use a sub domain off the TLD? Please advise as that seems counterintuitive to adhering to best practices.
@American BenchCraft Thank you for your questions!
Yes, you would need to authenticate your Klaviyo account to a subdomain of the root domain (TLD) that you are planning to use for your email sends. When you enter in the CNAME records for the subdomain you are planning to use, you are passing over the subdomain to Klaviyo to allow us to place in the appropriate SPF and DKIM records.
If you authenticated your Klaviyo account with your root domain, your root domain would no longer be pointed at your website, thus, resulting in errors when someone tries to visit your site.
Do note that if you authenticate your account to a subdomain, your From-Address can still make use of the root domain. For example, if your dedicated sending domain is send.website.com, your From-Address can be hello@website.com.
I understand the the dedicated sending domain concept, but my marketing team is currently sending out email (through Klaviyo) from “opportunities@myDomain.com” and want to continue to send email out with legitimate reply-to mailboxes.
Can someone share the SPF records we need in order to support this without setting up a dedicated sending domain?
Thanks.
Hey @carl543,
Excellent question!
Setting up a dedicated sending domain is the only method of authentication method Klaviyo supports. At this time Klaviyo does not support the use of SPF records for authentication purposes.
David
Hello, i’ve added the cname records and the send.rootdomail.com has been verified. However, every test I do which has the sender and reply email as Press@rootdomain.com falls into junk / spam on the recipient side. Surely spam filtering software will need to verify that mail is being relayed from an allowed mail relay server so we would need to add klaviyo mail relay as allowed to relay on rootdomain.com.
Alternatively, as I understand it, klaviyo automatically add the records on the subdomain.rootdomain.com / eg send.rootdomain.com and provided the mail is sent from eg press@send.rootdomain.com, then its seen as legitimate and we can have the reply to set as say press@rootdomain.com. However, in both cases above, mail is being categorised as spam at the moment.
Kindly advise how to solve this.
Hey @tabayersupport,
Can you elaborate further on your point of spam filtering softwares requiring verification and that mail is being relayed from an allowed mail server? As @wei.he pointed out, when setting up a dedicated sending domain and applying the necessary CNAME records within your DNS backend, this creates a subdomain that is delegated over to Klaviyo to make use of under your root domain.
After setting up a dedicated sending domain, are you by chance test sending to recipients who share the same email domain? If so this can often times be caused by your own organization’s internal filters as @wei.he has previously mentioned:
Additionally, I would add that I’ve seen this occur with inappropriate or lack of domain warming since switching to using a dedicated sending domain. Domain warming is an important step after setting up and using a dedicated sending domain or even just switching from different ESPs as it gives inbox providers time to get acclimated again to your sending infrastructure. An added benefit of warming your domain is in strengthening your sending reputation. Sending reputation is crucial as inbox providers will still keep track of this through your root domain even if you switch between ESPs.
David
Hi @wei.he, if i use Klaviyo’s shared domain do i need to set up DKIM and SPF myself or does Klaviyo handle everything? Thanks
Hi @Shiroyasha,
Happy to help!
To reiterate what Wei mentions earlier, the answer is no you don not have to do anything yourself if you are using Klaviyo’s shared domain as:
Klaviyo automatically adds the necessary SPF/DKIM records to set your account up to send emails using your own dedicated domain. On your end, you only need to add the prescribed CNAMEs
However, if you want to set up your account to send on your own dedicated sending domain and ensure that you are passing SPF, DKIM, and DMARC, you'll need to Whitelabel your account as shown in our How to Set up a Dedicated Sending Domain article.
Hope this helps!
-Taylor
We cannot send thourgh Klaviyo shared domain due to DMARC settings.
Its only possible to setup SPF and DKIM records through your dedicated sending domain?
And if the account has no signups - how to warm up a dedicated domain?
Can we have welcome flow running to new signups together with engaged segments or what do you recommend here?
The best solution for at new account without any signups, would be through the main domain and not subdomain due to non reputation. Klaviyos shared domain would have been the best solution the first 30-60 days, but as mentioned its not an possibility due to DMARC.
Hey @Henrik 8k,
If you can’t send emails through Klaviyo under the shared domain due to DMARC, then your best bet would be use a dedicated sending domain.
As @wei.he mentioned, when using a dedicated sending domain, SPF and DKIM are automatically applied.
Not having any signups (yet) or being a net new domain and account wouldn’t actually impact much. In fact, this is oftentimes an idea position to set yourself up for success! We also recommend following the Standard guided warming process as mentioned in our How to ramp and warm your sending infrastructure Help Center article in this position.
I would also suggest checking out the Community post below that relates to a similar topic of starting out new on a dedicated sending domain in Klaviyo:
David
Hey @David To thanks for answering all of these question.
My question regarding SPF:
Since Klaviyo does their SPF records automatically within the CNAME records, but I still want the highest security by using the ‘-all’ instead of ‘~all’ in my SPF records, that won’t cause a problem?
For example, if my actual spf records include ONLY Google and Shopify + the ‘-all’, will my Klaviyo communications still go through without a problem?
Hey @David To thanks for answering all of these question.
My question regarding SPF:
Since Klaviyo does their SPF records automatically within the CNAME records, but I still want the highest security by using the ‘-all’ instead of ‘~all’ in my SPF records, that won’t cause a problem?
For example, if my actual spf records include ONLY Google and Shopify + the ‘-all’, will my Klaviyo communications still go through without a problem?
My question exactly. The google workspace documentation indicates that we need to account for all the sending domains in the SPF record. e.g. Gmail, Klaviyo, Shopify https://support.google.com/a/answer/10685031?sjid=1404055984749706168-NC
Great question @Stacey and @kaine!
~all
vs -all
is the level of strictness the SPF record is set at. When SPF failures occur, ~all
denotes a softfail
whereas -all
denotes a hardfail
. All of this only comes into play with any SPF failures or misalignments - which when using a Klaviyo branded sending domain, should not be an issue since we are the ones that pass it automatically. Because we apply the SPF/DKIM records, we only use the ~all
protocol and not the -all
protocol. This would just impact the emails being sent from Klaviyo to other sources.