Our double opt-in confirmation emails land in spam, so half our signups never confirm
The welcome email arrives fine but the double opt-in confirmation lands in spam, so many signups never confirm and the store loses them. It happens because the account-level Default From is still a free-provider address (a @gmail.com or @yahoo.com), which fails authentication under the 2024 Google/Yahoo rules, and the confirmation hits brand-new, cold recipients.
The fix
In Klaviyo, open the account menu (bottom left) and go to Settings > Account > Contact Information > Organization, then set the Default From / Reply-To to an address on a domain you own. Never use a @gmail.com, @yahoo.com, or other free-provider address, because since the Feb 2024 Google/Yahoo rules a free-provider From fails authentication. Pair it with a verified branded sending domain (Settings > Domains) so the confirmation is DMARC-aligned, and note that changing the Default From only affects emails created afterward, so update the existing confirmation template too. Make sure that template is not text-thin: a bare "click to confirm" with no real content reads as phishing to filters.
Our branded sending domain showed active, then quietly reverted to klaviyomail.com and mail started hitting spam again
A branded sending domain verifies and shows Active, then disconnects on its own, and Klaviyo silently falls back to the shared klaviyomail.com domain, so deliverability craters weeks later with no obvious cause. The usual trigger is Cloudflare proxying (orange cloud) on the Klaviyo records, or DNS drift like a missing trailing dot on a CNAME value, causing periodic re-verification failures.
The fix
In Cloudflare, set every Klaviyo DNS record (the km CNAME selectors, the tracking CNAME, and the TXT verification record) to DNS only (gray cloud), never Proxied, and leave them that way permanently, since Klaviyo requires proxying stay off even after verification succeeds. Re-check the exact host and value against Settings > Domains, watching for a missing trailing dot at the end of a CNAME value that makes some providers auto-append your root domain. If dynamic (NS) routing keeps failing to propagate, switch to the static (CNAME) setup as a fallback, noting that Klaviyo officially recommends dynamic routing for best performance. Confirm propagation with dnschecker.org or MXToolbox, then verify the DKIM d= domain on a real send is your branded subdomain, not klaviyomail.com.
We switched this list to single opt-in to protect signup metrics, and bots list-bombed the form, wrecking our bounce and complaint rates
Store owners who set a list to single opt-in report waves of fake and mistyped addresses flooding their signup forms and abandoned-checkout flow, driving hard bounces, spam-trap hits, and complaints that tank domain reputation. Klaviyo lists are double opt-in by default, so list-bombing bites hardest on lists deliberately set to single opt-in and on embedded or custom-coded forms where Klaviyo's built-in bot protection does not fully apply.
The fix
Re-enable double opt-in on the affected list (Lists & segments > the list > Settings > Consent > Opt-in Process) so unconfirmed bot addresses are never mailed; this is the single most effective defense because only confirmed subscribers are added. Know that Klaviyo's native protection is only a reactive CAPTCHA shown to already-suspicious IPs, so it kicks in after an attack starts and does not fully cover embedded or custom-coded forms; for proactive protection you must add Google reCAPTCHA plus a honeypot field to your own form's HTML. To clean up the damage, build a segment of profiles that can receive email marketing, have received email 3 or more times in the last 180 days, and have zero opens, zero clicks, and zero placed orders all-time, then suppress them.
Apple's fake opens keep dead subscribers on our list, and our sunset flow never fires
With roughly half of opens now from Apple Mail Privacy Protection, Apple's servers pre-load Klaviyo's tracking pixel on delivery and log an open whether or not anyone read the email. This breaks any logic built on opens: engaged segments fill with ghosts, sunset flows that suppress "no opens in 90 to 180 days" never trip for Apple users, and win-back flows fire on phantom re-engagement, so unengaged addresses keep getting mailed.
The fix
Stop defining engagement on opens. Klaviyo flags every open with a boolean property called Apple Privacy Open, set to True for MPP-generated opens, so add the filter "where Apple Privacy Open equals False" to any Opened Email condition and rebuild engaged segments, sunset triggers, and win-back flows around clicks and real purchase behavior. Clicks are far harder for Apple MPP to fake, since MPP pre-fetches images, not links. For definitive suppression decisions, base them on server-side behavioral events (viewed-product, added-to-cart, placed-order) that fire through Klaviyo's Track API rather than from an inbox pixel, since those are genuinely immune to MPP pre-fetching.
A deliverability tester flags your shared Klaviyo IPs as blocklisted, and you assume your sending is broken
Senders run GlockApps or a similar tester, see a high spam rate, and trace it to blocklist hits on Klaviyo's shared sending IPs, even though SPF, DKIM, and DMARC all pass and their own domain is clean. Because Klaviyo routes across a shared pool, some of those IPs almost always carry a hit from a noisy neighbor, and the same test on other ESPs shows the same thing.
The fix
Check which blocklist before reacting. Minor ones like Hostkarma or all.s5h.net do not affect inbox placement, and you can confirm by checking your bounce messages for any mention of them. Shared-IP hits are noise that averages out, since real campaigns distribute across many IPs, so do not switch to a dedicated IP unless you consistently send well above 50k to 100k per month, because thin volume on a dedicated IP earns worse reputation than a healthy shared pool. Domain reputation, not IP, drives Gmail placement, so if your auth is aligned and your domain is clean you are in good shape. Get an honest read by seeding real inboxes during an actual campaign rather than from an isolated tester snapshot.