Klaviyo: dedicated sending domain and DMARC alignment

send.example.com.           CNAME  sviluppo.klaviyomail.com.
klei1._domainkey.send.example.com.  CNAME  dkim1.klaviyomail.com.
klei2._domainkey.send.example.com.  CNAME  dkim2.klaviyomail.com.

DMARC alignment: both mechanisms align

Once the dedicated sending domain is in place, alignment flips entirely. DMARC only validates a message if SPF or DKIM passes and aligns with the From domain. Here, the DKIM signature carries d=send.example.com, a subdomain of example.com: in relaxed mode — DMARC's default — it aligns. The envelope, on the subdomain too, aligns SPF the same way. Both mechanisms pass aligned.

This is the scenario DMARC expects, and it brings redundancy: if a forward breaks SPF, DKIM survives, and vice versa. Under DMARCbis, the subdomain's attachment to example.com is determined by the DNS tree walk rather than the old Public Suffix List, but the outcome is identical: send.example.com belongs to the same organisation. The annotated templates show where these elements fit in the domain's policy.

One reassurance about Klaviyo's breadth: every flow — one-off campaigns, welcome series, abandoned-cart reminders, post-purchase sequences — leaves through the same dedicated sending domain and inherits the same authentication. Configuring it once covers them all; there is no per-automation setup to repeat. That matters all the more because commerce domains are prime spoofing targets: an order confirmation or a shipping notice carries enough legitimacy for a forged copy to deceive the customer — the very reason reaching an enforced policy is worth the setup effort.

The blocker before p=reject

This is the point to remember for any merchant building their protection. Klaviyo is very often the source that prevents a commerce domain from reaching p=reject without breakage. The reasoning is direct: moving to a strict policy protects the domain from spoofing, but rejects at the same time any legitimate traffic that is not aligned — and Klaviyo traffic, as long as it leaves from the shared domain, is part of it.

The sound sequence is therefore clear: configure the dedicated sending domain before tightening the policy, verify in the reports that Klaviyo campaigns align, then only move to p=quarantine then p=reject. Doing the reverse — tighten first, fix later — means cutting off one's own campaigns until it is noticed. For a shop, that window is measured in lost revenue. The move up in policy is prepared, not improvised; the path to p=reject and the stakes specific to DMARC for e-commerce detail this progression.

The branded link-tracking domain

Alongside the sending domain, Klaviyo offers to customise the link-tracking domain — the one that rewrites campaign URLs to measure clicks. By default, these links point to a Klaviyo domain; customisation routes them through a subdomain of the brand (for instance links.example.com), also placed as a CNAME. This setting has no effect on DMARC alignment — DMARC judges only the sender, not the body's links — but it matters for two neighbouring reasons: recipient trust, which sees URLs in the brand's name rather than an unknown third party's, and deliverability, some filters being wary of shared redirect domains.

Distinguishing it from the sending domain avoids a frequent confusion: two subdomains, two roles. send.example.com carries authentication (SPF, DKIM, alignment); links.example.com dresses the tracking URLs. Configuring one does not exempt the other, and only the first weighs on DMARC.

Dedicated IP and e-commerce volume

Online commerce generates sending peaks — sales, launches, seasonal events — that weigh on reputation. Klaviyo offers, on high volumes, dedicated IPs reserved to an account. As everywhere, a fresh dedicated IP is warmed: ramped up in volume over several days, or receiving providers treat it as suspect. This choice has no effect on DMARC alignment — DKIM and SPF align the same way whatever the IP — but it weighs on deliverability, and so on the reports' delivery rates.

Telling a reputation problem from an alignment problem is precisely what aggregate reports allow: the former reads in delivery rates and complaints, the latter in the SPF and DKIM columns. For a shop, this distinction is directly financial — a deliverability dip mid-campaign is not fixed the same way as an authentication defect, and confusing the two costs time at the worst moment.

Common configuration mistakes

Several traps recur in the body of reports the free DMARC analyzer processes daily.

Staying on the shared domain and tightening anyway. The costliest: p=reject set while Klaviyo still leaves from klaviyomail.com — campaigns are rejected until the dedicated domain is in place.

Publishing the CNAMEs without validating in Klaviyo. Until the console confirms detection, the branded signature is not applied: sends revert to the shared domain.

Choosing an already-used subdomain. The sending subdomain must be dedicated to Klaviyo; reusing a subdomain already serving another purpose creates CNAME conflicts.

Forgetting From consistency. The domain of the displayed address must stay the brand's (example.com) for the subdomain's relaxed alignment to work; changing the From to an address on another domain breaks the reasoning and leaves campaigns unaligned.

The final proof: RUA reports

The only proof that a configuration holds is not the Klaviyo console, but what recipients report. Once a _dmarc record is published with a rua= address, aggregate reports arrive within a few days and detail, source by source, what aligns and what fails. Reading the aggregation reports, read in detail shows the switch clearly: before the dedicated domain, the Klaviyo source appears unaligned on both SPF and DKIM; after, it aligns on both.

A simple cadence is enough: a first read a few days after configuring the dedicated domain, once several recipients have reported, then a weekly glance while the policy stays at p=none. A calendar point specific to commerce: it is better to confirm alignment over a real sending period — a campaign, not just a test — since it is campaign traffic that matters on sale day. Once that switch is observed over several days and on real sends, the move to p=reject carries no risk for campaigns. The online analyzer reconstructs this state from the published records and the reports received, and places the domain on the path that leads to p=reject.