Every voice setup I have seen that starts with a self-description drifts. The rules are accurate: they describe the voice the client thinks they have. Not the voice their approved emails actually demonstrate. That gap is where first drafts go wrong and revision rounds pile up.

Why Extracted Voice Beats Described Voice

In my experience, voice setups that start with a self-description drift. Not because the rules are wrong. Because the rules describe the voice you think you have, not the voice your approved emails actually demonstrate.

When you describe your voice in a document ("warm but direct, benefit-led, no corporate jargon"), you are writing in human language about writing behavior. Claude has to interpret that description and translate it into generation behavior. The interpretation step introduces error. "Warm but direct" means something specific in your head and something different when the model generates against it.

When you extract voice rules from approved output, something different happens. The rules come back in terms that describe writing patterns structurally: sentence rhythm, opener structure, recurring phrase patterns. When you paste that file into the next prompt, the model is reading a structural description of the voice, not a human description it has to interpret. From experience, the gap between instruction and output is smaller.

Where Voice Calibration Sits in the Pattern

The extraction prompt is governed by the same four-mechanism wrapper we apply to every prompt we publish: prerequisites (approved samples and brand context), self-validation (every rule cites a sample number), human gate (you approve the VOICE.md before it lands on disk), and improvement proposal (recurring violations from drift detection become operator-committed rule additions).

VOICE.md is then the declared prerequisite of every other prompt in the system. Subject line prompts, segment rewrites, pre-send QA: each one refuses to run unless VOICE.md is provided. The voice file is not optional context. It is a required input enforced at the prerequisites layer.

The Two Layers Email Voice Actually Has

The other failure mode in most voice setups is treating all email types as interchangeable. A welcome email and an abandoned cart email are not the same register. The same brand writes them differently: different warmth level, different urgency, different lead style. If you extract voice from five promotional emails and use that file for welcome copy, you get welcome emails written in a promotional register. Structurally correct, tonally wrong.

Email production voice has two distinct layers:

• Brand identity layer: what stays consistent across every email type. Core vocabulary, sentence rhythm, prohibited phrases, opener DNA. This is extracted once and lives in the VOICE.md.

• Contextual register layer: how far each flow type moves on warmth, urgency, and lead style. Welcome sits at different coordinates than cart recovery for the same brand. This is documented separately in REGISTER.md and referenced per send.

Building both is a one-time setup. Using them is one extra line in every prompt. From experience, the difference shows up in revision rounds: extracted voice files cut the back-and-forth on tone consistency from the first draft.

Extraction Prompt: The Brand Identity Layer, Full Wrapper

Use one representative approved email per primary flow type as input. Welcome, abandoned cart, promotional, and re-engagement if you have all four. The prompt extracts what is consistent across all of them: the brand identity. Patterns that only appear in one flow type are register, not identity, and get flagged as conflicts for the register map.

## Prerequisites: required before running

- 5 to 10 approved email samples from this client, one per flow type
- A one-paragraph brand context (product, audience, primary offer)

If either is missing, do not proceed. Respond:
"Cannot run. Missing: [list approved emails / brand context as applicable].
Provide and re-run."

## Inputs

Brand context: [PASTE ONE PARAGRAPH ABOUT PRODUCT, AUDIENCE, OFFER]

Approved emails: [PASTE 5-10 APPROVED EMAILS, ONE PER FLOW TYPE,
SEPARATED BY --- BELOW]

## Task

Extract the brand identity layer: what stays consistent across ALL email
types. Write a VOICE.md file using exactly this structure:

---
## Tone
[one sentence: the consistent emotional register across all samples,
citing Sample numbers that demonstrate it]

## Sentence rules
1. [length and rhythm rule, with verbatim example in quotes and Sample number]
2. [paragraph structure rule, with Sample number]
3. [one other consistent structural pattern, with Sample number]

## Opener patterns
- [first-sentence style, with verbatim example in quotes and Sample number]
- [second pattern if present, or "one consistent pattern observed"]

## Recurring phrases
- "[exact phrase found across multiple emails]" (Samples N, N)
- "[exact phrase found across multiple emails]" (Samples N, N)
- "[exact phrase found across multiple emails]" (Samples N, N)

## What this voice never does
- [prohibition derived from consistent absence, with reasoning]
- [prohibition with reasoning]
- [prohibition with reasoning]

## Subject line pattern
[describe the pattern, citing Samples, or write
"not visible in samples" if subject lines not provided]
---

Rules:
- Brand identity only. Skip patterns that appear in only one flow type.
- Use verbatim examples where possible.
- If samples contradict each other on a pattern, write:
  CONFLICT: [what varies]. These belong in the register map, not here.

## Self-validation (run before returning output)

Before returning the VOICE.md, check:

1. Every rule cites at least one specific sample number
2. No rule is contradicted by another rule in the file
3. No subjective adjective ("punchy", "engaging", "conversational")
   appears without an operational test attached
4. The structure matches the schema above exactly
5. CONFLICT lines appear for any pattern that varies across samples

If any check fails, fix internally and re-check. If you cannot satisfy a
check after one attempt, return:
"Validation failed: [rule]. Cannot produce compliant VOICE.md."

## Human gate (before writing to disk)

After returning the VOICE.md block, state:
"Review the extracted VOICE.md above. Type APPLY to write it to disk as
VOICE-[YYYY-MM].md, or REJECT with specific corrections."

Do not write the file until APPLY is received.

## Improvement proposal (optional)

If you noticed a voice pattern in the samples that does not fit the four
sections above, append:

"PROPOSED RULE ADDITION (review before adding to the schema): [one line
describing the section or rule type that should be added]"

Do not modify the schema yourself.

Any CONFLICT line the extraction returns is a signal to document that pattern in the register map. It means the brand genuinely calibrates that behavior by email type, and a single rule would either be too rigid or too vague to be useful.

The Register Map, Same Wrapper

Once VOICE.md is committed, run a second prompt against the same samples to derive the register coordinates per flow type. The register map does not need to be regenerated frequently. Only when the program adds a new flow type or when client feedback flags a specific flow as tonally off.

## Prerequisites

- VOICE.md (the brand identity file from the extraction prompt above)
- The same email samples used for the extraction
- A list of flow types in the program

If any is missing, do not proceed. Respond:
"Cannot run. Missing: [list]. Provide and re-run."

## Inputs

VOICE.md: [PASTE VOICE.md CONTENTS HERE]

Email samples: [PASTE THE SAME SAMPLES USED FOR EXTRACTION]

Flow types in program: [LIST EVERY FLOW TYPE, ONE PER LINE]

## Task

For each flow type, identify register coordinates:

- Warmth level: high / medium / low, with one verbatim example sentence
- Urgency level: high / medium / low, with one verbatim example sentence
- Lead style: what the first sentence focuses on
  (benefit / consequence / story / question / direct CTA)
- CTA style: how the call to action is framed
  (soft / direct / urgent / implied)

Format as a table with one row per flow type. Coordinates, not rules.
They describe where this brand sits on each axis for each context.

## Self-validation

Before returning:
1. Every flow type from the input list has a row
2. Every cell cites a verbatim example sentence
3. No coordinate contradicts the VOICE.md identity layer
4. The table format is consistent

If a flow type has no representative sample, mark its row "INSUFFICIENT
SAMPLE" rather than guessing. Return the table even if some rows are
incomplete.

## Human gate

After returning the table, state:
"Review the REGISTER.md above. Type APPLY to write to disk, or REJECT
with corrections."

## Improvement proposal

If a register dimension keeps coming up that is not warmth/urgency/lead/CTA,
append:
"PROPOSED RULE ADDITION: [one line describing the new dimension]"

The output is a table. Welcome might be high warmth, low urgency, benefit-led, soft CTA. Abandoned cart might be medium warmth, high urgency, consequence-led, direct CTA. The table goes into a REGISTER.md file stored in the same client folder as VOICE.md.

Using Both Files in Every Downstream Prompt

Once VOICE.md and REGISTER.md exist on disk, every other prompt in the system declares both as required prerequisites. The downstream prompts refuse to run without them.

Below is the usage prompt that consumes both files. Notice that the prerequisites block lists VOICE.md and REGISTER.md by name and stops if either is missing.

## Prerequisites: required before running

- VOICE.md for this client
- REGISTER.md for this client
- A brief with all six fields below filled in

If any prerequisite is missing, do not proceed. Respond:
"Cannot run. Missing: [list]. Provide and re-run."

## Inputs

VOICE.md: [PASTE VOICE.md CONTENTS HERE]

Register for this send: [PASTE THE RELEVANT ROW FROM REGISTER.md]

## Brief
Type: [welcome / abandoned cart / promotional / re-engagement]
Position: [e.g. first in a 4-part sequence / third of five]
Audience: [who receives this and what they know about the brand]
Offer: [if applicable]
Goal: [what this email needs to accomplish]
Length: [word count target]

## Task

Write the email in the voice described in VOICE.md, calibrated to the
register coordinates above.

## Output format

Subject: [subject line]
Preview: [preview text, max 90 characters]
Body: [email body only, no greeting, no sign-off]

## Self-validation

Before returning, check the draft against:
1. Every VOICE.md "What this voice never does" rule
2. Register warmth, urgency, lead style, and CTA style match the row
3. Body word count is at or below the Length value specified in Brief

If any check fails, fix internally and re-check. If you cannot satisfy a
check after one attempt, return:
"Validation failed: [rule]. Cannot produce compliant copy."

## Human gate

After returning the draft, state:
"Review the draft above. Type APPLY to queue for send, or REJECT with the
specific revision needed."

Do not move the draft to the send queue until APPLY is received.

## Improvement proposal (optional)

If during writing you noticed a recurring pattern not covered by the
self-validation rules above (e.g. a register coordinate pairing that
consistently produces a structural conflict with VOICE.md), append:

"PROPOSED RULE ADDITION (review before adding): [one line describing the
pattern]"

Do not modify the self-validation rules in this prompt. Only propose.

The register row anchors warmth and urgency before generation starts. Without it, the model calibrates from VOICE.md alone, which describes the brand's tonal center of gravity, not where a specific flow type should sit on the scale. The result is a promotional email written at welcome-register warmth, or a re-engagement email with the urgency level of a cart recovery send.

When to Update Each Layer

The two layers update on different triggers.

From experience, AI-assisted programs drift faster than human-authored ones because generation volume is higher. Set a review cadence before you start generating at volume, not after you notice output degrading. For AI-assisted production, monthly is the cadence we use. For human-authored programs, quarterly is the cadence we use as a baseline.

Brand identity layer: update when brand guidelines change, when a major campaign cycle introduces a deliberately different positioning, or when a drift detection run flags consistent violations across multiple flow types. Not every brand refresh requires a full extraction. If only the prohibited phrases changed, edit VOICE.md directly and commit the change.

Register map: update when a specific flow type consistently gets revision notes about tone. If every abandoned cart draft comes back too aggressive, the urgency coordinate for that flow type is wrong. Pull three recent approved sends from that flow, re-run the register prompt for that row only, and commit the updated table.

Keep both files versioned: VOICE-2026-05.md, REGISTER-2026-05.md. When an output starts feeling off and you cannot identify why, the file version is in git history and you can trace it back to the specific file the drafts were generated against. Improvement is governed, reviewable, reversible.

After three months in a live email production workflow, a CLAUDE.md file typically reaches 400 lines. Claude does not ignore the rules — it deprioritizes the ones buried deep enough that they lose the competition for attention. Here is the architecture that fixes it.

It made sense when you wrote it. Six months later it is 400 lines long and Claude is quietly ignoring the bottom half. Not because the rules are wrong. Because a model working through a live production session cannot consistently apply guidance buried that deep in a long file.

How it happens

A client is running Claude as part of their email production pipeline. Newsletter sends, product launch announcements, promotional campaigns, welcome series variations. The workflow is working, so they keep extending it. Every time Claude produces something that misses (wrong tone on a product email, a claim that should not be in a newsletter, a subject line that does not match the brand register), they add a rule to CLAUDE.md. The file grows one sensible addition at a time.

By month three, a typical client workflow managing 500 or more email topics has a CLAUDE.md past 200 lines. Brand voice rules. Forbidden claims from previous bad outputs. Product naming conventions. Template contracts for different send types. Tone variations per audience segment. Cadence rules. All of it written down. None of it reliably followed.

Anthropic flags this in their Claude Code documentation: CLAUDE.md files over 200 lines degrade adherence. The model deprioritizes rules it encounters deep in a long file. The context window is finite, and in a session working through a product launch campaign alongside newsletter copy and automated send logic, CLAUDE.md is competing with everything else in that session for attention.

The workaround that does not work

The instinctive fix is splitting the file using @import: breaking content into separate files and pulling them in. It does not reduce the problem. Imported files still load in full at the start of every session. The context cost is identical. You have reorganized the problem, not solved it.

The fix that actually works is the one Anthropic documents: .claude/rules/ with paths: frontmatter. Files in that directory load only when Claude touches a matching file path during the session. Not at session start. Not always. Only when relevant.

The decision tree we use to audit a CLAUDE.md

We built a Claude Code skill called /trim-claude-md that walks every section of a CLAUDE.md through this logic. The full skill is free to copy at the bottom of this article. Here is how it categorizes each section:

1. Does every session need this? Brand voice rules, forbidden vocab, hard invariants. Yes: stays in CLAUDE.md.

2. Does it only apply when working in a specific area? Template rules, copy rules for a specific campaign type, segment-specific guidelines. No: moves to a .claude/rules/ file scoped to that path.

3. Is it a multi-step procedure? Setup runbooks, credential flows, one-time config. Moves to docs/setup-*.md or a standalone skill.

4. Is it state or history? "As of March 2026 the welcome series has 4 emails", shipped features, row counts. Cut entirely. Belongs in commit messages. It is not a rule, it is history, and history rots inside CLAUDE.md.

5. Is it hard enforcement? "Must validate before commit", "must run linter before push". Moves to a pre-commit hook in .claude/settings.json. Hooks are enforced. CLAUDE.md instructions are not.

What the split looks like for an email production workflow

What belongs in CLAUDE.md and loads every session: brand voice rules, forbidden claims the client has validated, US versus British English, the hard no-most-customers rule. These apply everywhere. They stay.

What moves to a scoped rule file:

• Email template rules: subject line length limits, preheader conventions, CTA copy guidelines, template token contracts. Scoped to templates/**. Loads only when a session touches a template file.

• Product announcement rules: product naming conventions, launch tone, pricing language, permitted claims in promotional sends. Scoped to campaigns/** or launches/**. A session writing a welcome series never loads this.

• Segment-specific copy rules: rules for a specific audience segment or list. Scoped to those output directories. Irrelevant to most sessions and invisible to them once scoped correctly.

• ESP and rendering notes: client-specific rendering rules, deliverability constraints, dark mode handling. Scoped to the relevant build or export directories.

What gets cut entirely: dated state notes, shipped features lists, and any paragraph describing the current state of the workflow rather than a rule Claude should follow. These belong in commit messages or a plans folder.

What the frontmatter looks like

A rule file for product announcement copy:

---
paths:
  - "campaigns/**/*"
  - "launches/**/*"
---

# Product announcement copy rules

[Campaign-specific guidance here]

Claude Code reads the paths: block and loads the file automatically when a session touches a matching path. If the session is writing newsletter copy and never touches a campaign file, this file is invisible to it.

The pattern extends beyond email

We have seen this in every production workflow where clients run Claude over time: CLAUDE.md becomes the catch-all for every correction ever made. Legal adds a clause. Brand adds a voice note. A developer adds a rendering constraint. A marketer adds a segment rule. The file grows.

Email workflows are particularly prone to this because of the volume of writing, the number of variations, and the long-running nature of the pipeline. A client running 500 email topics across multiple send types, with audience segments and product lines and seasonal tone shifts, generates more rules than almost any other Claude use case. The context file needs architecture, not just growth.

If a client workflow has been live for more than three months and output quality has quietly declined from where it started, check the CLAUDE.md line count first. If it is past 200, run the audit.

The skill: free to copy and use

The /trim-claude-md skill automates the full audit. It reads your CLAUDE.md, walks every section through the decision tree above, and produces a proposal file showing exactly what stays, what moves, and where. Nothing is written until you approve. One session to run it.

To install it in your Claude Code project:

1. Create the directory: mkdir -p .claude/skills/trim-claude-md

2. Copy the skill file from the gist below into .claude/skills/trim-claude-md/SKILL.md

3. Run it from the project root: /trim-claude-md

The full skill is here, free to use on any project: gist.github.com/ChristianLundgren/d4be5560eec2c36385d6fe3e5fd3dccd

DMARC has three policy levels. Many brands that have a DMARC record in place are sitting at the first one, and they have been sitting there for months or years. p=none technically satisfies the Google and Yahoo 2025 bulk sender requirements. You published a record, you pass the compliance check, and your emails continue to deliver. What you have not done is protect your domain from being spoofed by senders you did not authorise.

That gap between "technically compliant" and "actually protected" is where deliverability programs stall. The path from p=none to p=reject requires work, but it is structured work with a clear sequence. This article walks through exactly what each policy level does, why many brands get stuck at the first, and the step-by-step process to move through all three without breaking legitimate mail in transit.

Why This Matters

Domain spoofing is the attack that DMARC exists to block. Without a policy that enforces action on failing mail, anyone can send email that appears to come from your domain. Your customers receive what looks like an email from your brand, except it is a phishing attempt, a scam, or a spam blast from an infrastructure you have no visibility into.

Your domain reputation takes damage from mail you did not send. Your customers lose trust in emails that look like yours. And you have no mechanism to stop it because your DMARC policy instructs receiving servers to do nothing about it except file a report.

The Google Sender Guidelines 2025 and the Yahoo Sender Requirements 2025 both mandate a DMARC record for bulk senders at any policy level. This pushed many brands to publish their first DMARC record in 2024 and early 2025. What the requirements did not mandate is moving past p=none, which is the minimum that satisfies the check. In my audits, brands that implemented DMARC in response to the Google and Yahoo announcement often stopped at p=none and have not reviewed their aggregate reports since.

The Full Breakdown

DMARC builds on top of SPF and DKIM. To understand what each policy level does, you need to understand what a DMARC failure actually means. An email fails DMARC when it fails both SPF alignment and DKIM alignment for the domain in the From: header. SPF alignment means the authenticated sending domain matches the domain in the From: header. DKIM alignment means the domain in the DKIM signature matches the domain in the From: header. A single pass on either SPF or DKIM is sufficient for DMARC to pass. DMARC only fails when both fail.

With p=none, a DMARC-failing email delivers to the inbox without obstruction. The receiving mail server checks DMARC, finds a failure, and then does nothing about it except send an aggregate report to the address specified in your rua tag. Those reports are XML files that tell you which IP addresses are sending mail that claims to be from your domain, how much of that mail is passing or failing authentication, and from which sending sources. p=none is a monitoring tool. It is not a protection mechanism.

p=quarantine changes the outcome for failing mail. Instead of delivering to the inbox, mail that fails DMARC is routed to the spam or junk folder. It still reaches the recipient. It still has the potential to damage your brand and mislead your customers. But the delivery path is degraded, and the probability of someone acting on it drops substantially.

Quarantine is the right intermediate step because it reduces the blast radius of spoofed mail while you continue to verify that all your legitimate sending sources are properly authenticated.

p=reject is the destination. Failing mail is rejected at the server level. It never reaches any folder, inbox or spam. This is complete protection against domain spoofing for properly authenticated rejection. The risk in jumping to p=reject without preparation is that if any legitimate sending source — a transactional email provider, a CRM, a third-party tool sending on behalf of your domain — is not properly authenticated, its mail will be blocked entirely. That is why the path from p=none to p=reject goes through a structured authentication audit rather than a direct flip of the policy tag.

Step-by-Step Implementation

1. Publish your DMARC record at p=none with aggregate report delivery configured.
   
   What: Add a TXT record to your DNS at _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. The rua tag is where aggregate reports are sent. Use a real inbox that someone monitors. If you do not want to manage raw XML, route reports through a DMARC analysis tool (Postmark's free analyser, Dmarcian, Valimail) that parses them into readable summaries.
   Why: Before you can enforce any policy, you need a complete picture of every source sending mail with your domain in the From: header. p=none gives you that data without risk to legitimate mail delivery.
   Common mistake: Omitting the rua tag. A DMARC record without a report destination is monitoring with no output. You will never know what the reports would have shown because you have nowhere to receive them.

2. Run on p=none for 30 days and read your aggregate reports.
   
   What: Let a full month of sending data accumulate in your aggregate reports. Review the reports to identify every IP address or sending source that is sending mail from your domain. You are looking for three categories: sources you recognise and have authenticated, sources you recognise but have not fully authenticated, and sources you do not recognise at all.
   Why: A 30-day window captures the full range of your sending infrastructure, including tools that may send infrequently — password resets, transactional notifications, quarterly digests. A shorter observation window risks missing a legitimate source and blocking it when you move to enforcement.
   Common mistake: Looking at reports once and declaring the source list complete. Aggregate reports are delivered daily or weekly depending on the receiving mail server. Review them at the end of the 30-day window, not the beginning, and consolidate across the full period.

3. Authenticate every legitimate sending source.
   
   What: For each source identified in your aggregate reports that you authorise to send mail from your domain, verify that SPF and DKIM are correctly configured. For your ESP (Klaviyo, Mailchimp, Braze, or equivalent), this typically means verifying domain authentication inside the platform settings. For transactional mail (SendGrid, Postmark, Amazon SES), check that your sending domain is authenticated with a valid DKIM key and that your SPF record includes the provider's sending IPs or mechanism.
   Why: Moving to p=quarantine or p=reject before authenticating every legitimate source will block or quarantine mail from those sources. The only way to enforce DMARC safely is to ensure that every source you want to pass authentication actually does pass it.
   Common mistake: Assuming that because your ESP sends email successfully, it is DMARC-aligned. Successful delivery and DMARC alignment are not the same thing. Check your aggregate reports specifically for DMARC pass/fail status per source, not just delivery status.

4. Move to p=quarantine, initially with pct=10 or pct=25.
   
   What: Update your DMARC record to v=DMARC1; p=quarantine; pct=10; rua=mailto:reports@yourdomain.com. The pct tag tells receiving mail servers to apply the quarantine policy to only 10 percent of failing mail. The other 90 percent still delivers as if p=none is in effect. Increase pct gradually: 10 to 25 to 50 to 100 over two to four weeks.
   Why: Gradual rollout via the pct tag is a safety mechanism. If there is a legitimate source you missed during the authentication phase, the partial rollout limits the damage from blocking its mail to a fraction of sending volume, giving you time to identify and fix the issue before it affects all delivery.
   Common mistake: Jumping directly to pct=100 on the first quarantine update. The pct tag exists precisely to allow staged enforcement. Use it. The time cost of a staged rollout is two to four weeks. The cost of blocking a critical transactional mail source is customer-facing delivery failures.

5. Verify quarantine-phase reports, then move to p=reject.
   
   What: Monitor aggregate reports through the quarantine phase at each pct increment. Look for any legitimate sources appearing in the failing mail category. Once you reach pct=100 quarantine with no legitimate sources failing, update the record to v=DMARC1; p=reject; pct=100; rua=mailto:reports@yourdomain.com. Use the same gradual pct ramp if you want the additional safety net.
   Why: p=reject at pct=100 is full enforcement. Failing mail is blocked at the server. There is no recovery path for a sender that is blocked by reject policy except fixing their authentication. Confirming a clean quarantine phase before stepping to reject gives you confidence that the only mail being blocked is mail you do not authorise.
   Common mistake: Treating p=reject as a set-and-forget final state. New sending tools get added to the stack. Subdomains get spun up. Acquisitions add new infrastructure. Review DMARC aggregate reports quarterly to catch new unauthenticated sources before they become a problem.

6. Set up forensic reports (optional but useful for investigating specific failures).
   
   What: Add an ruf tag to your DMARC record: ruf=mailto:forensic@yourdomain.com. Forensic reports contain redacted message-level data about individual DMARC failures, including headers that can help identify where failing mail is originating. Not all mail servers send forensic reports (Gmail does not by default), but those that do provide more granular detail than aggregate reports.
   Why: When investigating a specific spoofing campaign or a stubborn unidentified source in your aggregate data, forensic reports give you message-level context. Aggregate reports show patterns. Forensic reports show instances.
   Common mistake: Routing forensic reports to the same inbox as aggregate reports without a filtering rule. Forensic report volume can be high during active spoofing attempts. Keep them in a separate inbox or folder so they do not bury your aggregate report summaries.

The Framework

Use this decision tree when assessing or building a DMARC implementation. Each branch represents the correct next action given your current state.

DMARC POLICY DECISION TREE
============================

START: Does a DMARC record exist at _dmarc.yourdomain.com?
|
+-- NO  --> Publish p=none with rua= configured. Start 30-day observation.
|
+-- YES --> What is the current policy?
            |
            +-- p=none
            |     |
            |     +-- Is rua= configured and are reports arriving?
            |           |
            |           +-- NO  --> Add rua= tag immediately. Restart observation.
            |           |
            |           +-- YES --> Have you reviewed 30+ days of aggregate reports?
            |                       |
            |                       +-- NO  --> Wait. Review at 30 days.
            |                       |
            |                       +-- YES --> Are all sending sources authenticated?
            |                                   |
            |                                   +-- NO  --> Authenticate each source.
            |                                   |          Then step to quarantine pct=10.
            |                                   |
            |                                   +-- YES --> Step to p=quarantine pct=10.
            |
            +-- p=quarantine
            |     |
            |     +-- What is pct?
            |           |
            |           +-- Less than 100 --> Ramp pct by 25 every 1-2 weeks.
            |           |                    Monitor reports at each step.
            |           |
            |           +-- 100 --> Are any legitimate sources appearing as failures?
            |                       |
            |                       +-- YES --> Fix authentication. Hold at quarantine.
            |                       |
            |                       +-- NO  --> Step to p=reject pct=100.
            |
            +-- p=reject
                  |
                  +-- Is rua= still configured and monitored quarterly?
                        |
                        +-- NO  --> Add rua= or resume review schedule.
                        |
                        +-- YES --> You are at full enforcement. Maintain.

NOTES:
- Never remove rua= at any policy level. Reports are your visibility.
- New sending tools require re-authentication before first use.
- Subdomains inherit nothing. Each subdomain used for sending needs its own
  SPF, DKIM, and DMARC configuration or an explicit subdomain DMARC record.
- sp= tag controls subdomain policy if not set separately at the subdomain level.

Real Example

A B2B SaaS company I worked with in early 2026 had published a DMARC record eighteen months earlier in response to the initial Google and Yahoo announcement. The record was v=DMARC1; p=none; — no rua tag, no report destination. They had received zero aggregate reports in eighteen months because there was no inbox configured to receive them.

From the outside, their DMARC implementation looked complete: the record existed, the DNS lookup returned a valid value, and every compliance checker they ran returned green. Their domain had been spoofed for at least three months, which they discovered only when a customer forwarded a phishing email that appeared to come from their support address. A green compliance check is not the same as a working implementation.

The remediation work took six weeks. First, we added the rua tag and spent two weeks reading the aggregate reports that immediately began arriving. Three legitimate sending sources were not fully DMARC-aligned: their transactional email provider had DKIM configured but SPF alignment was broken because the From: domain was their root domain while the SPF record only covered the subdomain they used for transactional mail. Their marketing automation platform was passing DKIM but their SPF record had not been updated to include the platform's sending infrastructure after they migrated from a previous tool the previous year. And a third-party survey tool was sending from a subdomain with no DMARC record and no authentication at all.

We fixed authentication for all three sources, confirmed clean aggregate reports across two weeks of observation at p=none, then moved to p=quarantine at pct=10 and stepped up to pct=100 over three weeks. After another two-week clean observation period, we moved to p=reject. The spoofed phishing mail stopped appearing in their customers' inboxes within days of the p=quarantine step, before they had even reached full enforcement.

Audit Checklist

• A DMARC record exists at _dmarc.yourdomain.com — verify with a DNS lookup tool or dig TXT _dmarc.yourdomain.com

• The record includes an rua= tag pointing to a monitored inbox or DMARC report aggregation service

• Aggregate reports are actually arriving and being reviewed at least monthly (not just configured and forgotten)

• Your current policy is not p=none if you have been running aggregate reports for 30 or more days and your sending sources are authenticated

• Every active sending source (ESP, transactional provider, CRM, third-party tools) has SPF and DKIM configured for DMARC alignment, not just for delivery

• Any subdomain used for sending has its own DMARC record or inherits a policy via the sp= tag on the root domain record

• Your SPF record includes all current sending infrastructure and does not include infrastructure from a previous ESP you migrated away from

• Your DKIM keys are at least 1024-bit (2048-bit recommended) and have been rotated in the last 12 months if your provider supports rotation

• You have a process to re-authenticate new sending tools before they send their first email, not after the DMARC reports flag them

Every day, emails are rejected by Gmail and Yahoo because the sending domain has no SPF record, or has one that does not include the ESP they are actually sending through. This is not a technical edge case. It is one of the most common, most fixable deliverability problems I encounter in audits, and it is entirely preventable once you understand what SPF actually does.

What Is Actually Happening

SPF stands for Sender Policy Framework. It is a DNS record that tells receiving mail servers which IP addresses are authorised to send email on behalf of your domain.

When your ESP, Klaviyo, Mailchimp, or any other platform sends an email with your domain in the From address, the receiving server looks up your domain's DNS records and checks whether the IP address that just sent the email is on your authorised list. If the IP is there, SPF passes. If it is not, SPF fails.

Without an SPF record, there is no authorised list at all. The receiving server has no way to verify that the email claiming to be from your domain was actually sent by you or anyone you authorised. That is not a minor gap. It is a verification failure at the most fundamental level of email authentication.

SPF was designed to address a specific problem: anyone can send an email claiming to be from any domain. Nothing in the basic email protocol prevents that. SPF exists so receiving servers can check whether the server that delivered the message was actually authorised to claim that domain.

Google and Yahoo's 2025 bulk sender requirements made SPF mandatory for high-volume senders. Missing it is a non-compliance issue that can result in email being rejected outright, not just filtered to spam.

The most common SPF failure I see in audits is not a missing record entirely. It is a record that exists but does not include the ESP being used. A brand set up SPF three years ago when they were sending through one platform, then migrated to a different platform, and never updated the DNS record. The new ESP's IP addresses are not in the authorised list. SPF fails. Email lands in spam, or gets blocked, and no one understands why because the record technically exists.

SPF has one technical limitation worth knowing. It verifies the sending server's IP address, not the message itself. When a subscriber forwards your email, the forwarder's server re-sends from a different IP, which is not in your SPF record. The forwarded message fails SPF.

DKIM exists alongside SPF precisely because of this: DKIM signs the message and survives forwarding. Both are required for DMARC alignment. SPF is the foundation, and without it, the rest of the authentication stack is weaker.

The One Fix

Verify your SPF record and confirm it includes every sending source you are currently using.

Open your DNS management tool, find the TXT record for your domain that starts with v=spf1, and read through the authorised includes. Cross-reference that list against every platform that sends email on your behalf: your primary ESP, any transactional email service you use for order confirmations, any third-party tools that send notifications or automated emails from your domain.

If any sending source is missing from the SPF record, add its include. Every major ESP publishes its authentication setup instructions in its documentation. For Klaviyo, SPF is handled through the branded sending domain CNAME configuration; check your Klaviyo account's domain authentication settings for the exact DNS records required. For Mailchimp, the include is include:servers.mcsv.net. Add the appropriate include, save the record, and allow up to 48 hours for DNS propagation.

If you do not have an SPF record at all, create one. The format is a DNS TXT record at your root domain. A basic SPF record for a single ESP looks like v=spf1 include:klaviyo.com ~all. The ~all at the end is a soft fail for IPs not in your list. The direction in current email security practice is toward -all (hard fail) once you are confident the record is complete and you have moved your DMARC policy off p=none.

Use an SPF validation tool — MXToolbox is the most common option — to confirm the record syntax is correct after making changes. Invalid SPF syntax does not fail gracefully. A malformed record can break SPF entirely, which is worse than having no record at all. Get this right before moving on.

When SPF Is Configured Correctly

When SPF is correctly configured, receiving servers can verify that your emails are coming from authorised sources before they decide where to deliver them. You have one component of the authentication foundation in place. Combined with DKIM and a DMARC policy, SPF forms the technical proof that an email claiming to come from your domain was actually sent by you or a service you authorised.

The practical outcome is that your emails are not rejected at the server level for a fixable authentication failure. That baseline matters more than any subject line test.

You cannot A/B test subject lines to fix a problem that exists before the email is delivered. Authentication issues surface upstream of everything else. In my audits, SPF is the most common gap, and it is usually the right first place to start.

I have seen brands switch to plain text emails because they read that HTML hurts deliverability. Their inbox rates did not improve. Their brand experience dropped. The myth cost them something real, and it was built on a misreading of what mailbox providers actually measure.

What Is Actually Happening

The claim that HTML hurts deliverability has been circulating since the early days of spam filtering and it has not become more accurate with age. In 2026, it is still repeated as deliverability advice in forums, blog posts, and cold outreach playbooks. It is a partial truth, distorted so far from its origin that it functions as misinformation.

Here is where the idea came from. In the early 2000s, when spam was primarily a volume problem and content-based filtering was the dominant approach, tools like SpamAssassin assigned scores to email content. Certain HTML patterns, particularly image-only emails with no text content, were correlated with spam. Spammers at the time frequently used single-image HTML emails to bypass keyword-based text filters. Image-only format became a spam signal.

The correlation was real. The causation was wrong. The format did not cause the spam problem. The format happened to be used by people who were running spam campaigns. An authenticated sender with a healthy list sending a well-coded HTML email to subscribers who wanted it was not, and is not, penalised for the format.

Modern mailbox providers at Google and Yahoo evaluate sender reputation and engagement as the primary inbox placement signals, per Google's Sender Guidelines 2025 and Yahoo's Sender Requirements 2025. Authentication matters: SPF, DKIM, and DMARC are non-negotiable in 2026. Engagement matters: if a significant portion of your list is not opening, clicking, or is actively marking your mail as spam, your reputation suffers. List hygiene matters. Domain and IP reputation matter.

HTML as a format is not in that list. The markup is not what Gmail's algorithms are measuring when they decide where your email lands. In every deliverability analysis I have run, format type has not been the variable that explains inbox placement differences. The variables that matter are on the sender side, not the template side.

Where HTML can cause a deliverability problem is through broken implementation. Excessively large HTML files can trigger issues in some environments. Poor code that produces enormous message sizes, or certain deprecated HTML patterns, can occasionally flag. But that is a code quality problem, not an HTML problem. A well-built HTML email from an authenticated sender with good engagement lands in the inbox.

I have tested this directly: the same sender, the same list, the same authentication setup, with a plain text send and an HTML send within the same week. Inbox placement rates are comparable. The format does not move the needle when the sender is healthy.

When the sender is unhealthy, switching to plain text does not fix the underlying problem. It just gives you a worse-looking email with the same deliverability issues.

The One Fix

If you are worried about deliverability, audit the actual deliverability variables. Do not audit your template format.

Start with authentication. Is your SPF record set? Is DKIM configured and aligned? Do you have a DMARC record published? These three are the foundation. Google and Yahoo's 2025 bulk sender requirements made them non-optional. If any of them are missing or misconfigured, that is your deliverability problem. A plain text email from an unauthenticated domain will land in spam faster than an HTML email from an authenticated one.

Then look at list health. What percentage of your list has not engaged in the last 60 to 90 days? What is your spam complaint rate? These are the engagement signals that mailbox providers use to build your sender reputation. A disengaged list sending to unengaged subscribers is a reputation problem. It does not matter whether the emails are HTML or plain text.

If both authentication and list health are clean, check your HTML code quality as a secondary step. Use render testing tools like Litmus, Email on Acid, or Testi@ to validate your email renders correctly across clients. A well-coded HTML email should have no deliverability issues originating from its format.

What Good Looks Like

When deliverability is working, it is not because of format choices. It is because the sender has clean authentication, a healthy engaged list, and a consistent sending pattern that builds domain reputation over time. HTML emails from that sender land in the inbox alongside plain text emails from the same sender, at comparable rates.

Treating format as the deliverability variable is a distraction from the variables that actually matter. Every week spent worrying about HTML is a week not spent on list hygiene, engagement re-activation, or authentication auditing. Those are the levers that move inbox placement.

The HTML fear also has a real cost. Plain text email loses the branded experience, the product imagery, the design language you have built. It trades a capability you actually have for an advantage that the evidence does not support.

That is a bad trade, and it is made repeatedly by brands that absorbed a myth without tracing it back to its source.

Tuesday at 10am has been the most confidently repeated email advice for fifteen years. It was wrong when it started, and it is provably wrong now. The fact that it persists says more about how email advice circulates than it does about when your subscribers open their email.

What Is Actually Happening

The Tuesday morning rule originated in benchmark reports published by early email platforms in the late 2000s and early 2010s. MailChimp and HubSpot both published aggregate send-time data showing that Tuesday morning had higher open rates across their customer bases. That finding got picked up, repeated, and eventually ossified into conventional wisdom.

There are two major problems with it, and both have gotten worse over time.

The first is the data source. Those recommendations were derived from aggregate open rate data. Open rates in 2026 are not a reliable signal of actual engagement. Apple Mail Privacy Protection, introduced in 2021, fires an open pixel for every subscriber using Apple Mail regardless of whether they actually read the email. By the time Litmus State of Email 2025 data was published, Apple Mail held a substantial share of the email client market.

Any open-rate-based recommendation built on data from 2025 or earlier carries some portion of this inflation. Any recommendation built on data from before 2021 predates the problem entirely and carries no adjustment for it.

The second problem is the aggregation itself. An average across all verticals and all list compositions is not advice for your specific programme. Klaviyo's 2025 benchmark data shows meaningful variation in engagement patterns across different industry verticals. A DTC brand selling premium skincare to a primarily working-parent female audience has a fundamentally different subscriber behaviour pattern than a B2B software newsletter targeting technical decision-makers. Both have subscribers. Neither behaves like an aggregate benchmark.

From my work with DTC brands, I find that send-time performance varies not just by industry but by list segment, by device type, and by where in the customer lifecycle the subscriber sits. A lapsed buyer segment responds at different times than an active engaged segment. A mobile-heavy audience has a different schedule than a desktop-heavy one. These are your variables. A 2009 industry average is not.

And the competitive factor makes the Tuesday rule particularly counterproductive. If everyone follows the same advice, Tuesday 10am becomes the most congested inbox moment of the week. You are competing for attention in the same window as every other brand that read the same article. That is not a strategy advantage. It is a traffic jam.

The One Fix

Stop guessing and start testing against your own list data, using a reliable metric.

The reliable metric is click rate, not open rate. Open rates are MPP-inflated and unreliable as a testing signal. Click rate reflects an action a subscriber actually took. It is not immune to noise, but it is substantially closer to actual engagement than a pixel that fires automatically for Apple Mail users.

Run a send-time test with a meaningful sample size. Split your next three or four campaigns across two different send times in the same week. Send half your list on Tuesday morning, half on Thursday afternoon. Measure clicks and conversions over 48 hours. Do it again the following week with different times. After four to six rounds you have real data on your list's behaviour, not an industry average from fifteen years ago.

Many ESPs have send-time optimisation tools that do this automatically at the individual subscriber level. Klaviyo's Smart Send Time feature, for example, analyses each subscriber's historical engagement pattern and suggests a send window based on when that specific person has previously engaged. That is a meaningfully better basis for send scheduling than any aggregate benchmark, including the ones published in 2025.

Use the tool if it is available to you. If it is not, run the manual test.

What Good Looks Like

When send time is based on actual list behaviour, campaigns stop competing in the same inbox window as every other brand that follows the same generic advice. Your subscribers get your email when they are more likely to be in a reading context. Click rates improve because the timing is calibrated to their behaviour, not to an industry norm.

The more important outcome is that you stop treating a single piece of 2009 wisdom as a permanent fixture. Send time is a variable. Like any variable, it should be tested, measured, and updated when your list composition changes.

A brand that acquired a significant segment of subscribers from a new channel has probably changed its audience behaviour pattern enough to warrant retesting. That is the right posture: periodic testing as the list evolves, not one inherited rule applied indefinitely.

Tuesday at 10am is not wrong for everyone. It may happen to be the right time for your specific list. But you should know that because you tested it, not because someone wrote it in a benchmark report before most of your current subscribers were on your list.

A subscriber who added something to a cart and left is not the same person as a subscriber who reached the payment page, entered their email address, and left. Running one recovery email to both groups is treating two very different buying signals as if they are the same problem. They are not.

What Is Actually Happening

In almost every ESP, you can trigger flows from two separate events: a cart add that does not progress to checkout, and a checkout initiation that does not result in a completed purchase. These are technically distinct events, and they represent distinct buyer psychology. The ESP knows the difference. Your copy should too.

Abandoned cart, the first event, fires when someone adds a product to their cart but never moves further. They may be browsing, comparing options, saving items for later, or simply not ready. You may or may not have their email address depending on whether they are already a subscriber. The intent signal is real but shallow.

Abandoned checkout, the second event, is a different category entirely. The subscriber navigated to the checkout page and provided their contact details. They were close enough to purchase that they started the process. Their intent is demonstrably higher.

The email can reflect that. It does not need to re-introduce the product or rebuild the case for buying. The subscriber was already at the payment screen.

In my audits, many brands have one flow handling both. The trigger is either set to cart abandonment only, missing the checkout event entirely, or it is built on checkout abandonment but described internally as the "cart recovery" flow. In both cases, the higher-intent group receives messaging calibrated to the wrong point in the purchase process.

Klaviyo's 2025 benchmark data shows that abandoned checkout emails consistently outperform abandoned cart emails on revenue-per-recipient. The reason is the intent gap. Someone who made it to checkout was materially closer to buying. A direct email that acknowledges they were at checkout, makes completing the purchase simple, and does not waste their time re-persuading them on the product performs better than a generic "you left something behind" message built for a lower-intent audience.

The missed opportunity is not just in open or click rates. It is in the messaging architecture.

When one flow handles both groups, the copy is written at the lowest common denominator. It is cautious, product-focused, and soft on the CTA because it needs to work for someone who barely engaged as much as someone who was at the payment screen. That calibration hurts the higher-intent group more than it helps the lower-intent one.

The One Fix

Separate the two flows at the trigger level and write distinct copy for each. This is a one-time structural fix.

The abandoned cart flow can afford to be educational and trust-building. It is working with a lower-intent audience. Show the product, address common concerns, offer social proof. Give the subscriber what they need to decide.

The abandoned checkout flow should be direct. The subscriber knows the product. They were at the payment screen. Your first email can acknowledge that plainly: they left before completing their order, here is a link back to their checkout, here is what happens after they buy. No need to re-pitch the product.

The objective is friction removal, not persuasion.

If you are currently running a single flow for both groups, start by splitting the trigger. In Klaviyo, this means having an "Active on Site" flow with a checkout started metric and a separate flow on "Added to Cart" that excludes people who have already triggered checkout. The copy can evolve over time. Getting the separation in place is the structural fix that makes the right messaging possible.

The timing also differs. In my experience, abandoned checkout emails perform better with a shorter first-send window. Someone who was at payment and left is still mentally in purchase mode for a shorter period than someone who added an item to a cart.

Waiting 24 hours to send the first email in a checkout abandonment flow misses the peak recovery window. Many brands I work with have sent it within an hour and seen materially better conversion than the same message sent the next day.

What Good Looks Like

When the two flows are separated and the messaging is calibrated to intent level, the abandoned checkout flow typically becomes one of the highest revenue-per-recipient automations in the programme. Not because the audience is larger, but because the intent is higher and the copy is finally doing the right job.

The abandoned cart flow, now freed from needing to work for a high-intent audience, can be more patient and educational. It can take three emails over three days rather than trying to close urgently in the first send. Conversion rates on both flows improve when neither is written for the wrong audience.

From experience, the single most consistent finding in DTC email audits is that brands are conflating these two flows. The fix is a one-time structural change in the ESP. In the accounts I have rebuilt, the revenue impact shows up in the first 30 days of the abandoned checkout flow running properly.

Brands spend weeks refining their abandoned cart sequence and leave their welcome series as a single email with a discount code. That is the most expensive sequencing mistake in email. The flow that performs best is the one getting the least attention.

What Is Actually Happening

The welcome series is the highest revenue-per-recipient flow across many DTC brands. Omnisend's 2025 email marketing data confirms this pattern consistently. The reason is not complicated: a subscriber is at peak intent the moment they join your list. Open rates in the welcome window are among the highest of any automated sequence. Engagement is higher. Purchase likelihood is higher. The relationship is brand new and the subscriber actively chose to hear from you.

That window closes. It does not stay open indefinitely while you decide what to do with it. By the time a subscriber has been on your list for three weeks and received nothing but a discount code on day one, the relationship has already settled into something much lower-engagement. You cannot restart that first week. The opportunity exists once per subscriber.

In my audits, I consistently find that brands have invested significant time in their abandoned checkout flow. Two or three emails, timed carefully, with personalised product content. They have a post-purchase sequence. They may even have a win-back flow for lapsed buyers.

And then their welcome series is one email that delivers a promo code and says something like "welcome to the family."

The logic that creates this pattern is understandable. Abandoned cart has clear, attributable revenue. You can see it in your ESP's flow analytics: this sequence recovered X in the last 30 days. Welcome series revenue is harder to isolate because it runs through the same first-purchase attribution as organic discovery. The money is there. It just does not always appear where people expect it to be.

The other factor is effort. A good welcome series takes real work. You need to think about what a new subscriber actually needs to know, in what order, over what timeframe. That is a more complex build than a two-email cart recovery sequence. So it stays in the backlog.

The One Fix

Before you touch your abandoned checkout timing, your post-purchase upsell sequence, or your win-back threshold, audit your welcome series against one question: does it do more than deliver a discount?

A welcome series that performs well at minimum covers four things across four to six emails sent over ten to fourteen days:

• Email 1, immediate: deliver the promised incentive without making the subscriber hunt for it. Introduce the brand in one short paragraph.

• Email 2, day one to two: brand story. What makes the product, the process, or the people different. This is where trust starts to form.

• Email 3, day three to four: social proof. Bestsellers, reviews, anxiety reducers for new buyers.

• Emails 4 through 6, every two to three days: product education, FAQ handling, and an offer close with clear expiry.

If your current welcome series is one email, the fix is not a complete rebuild. It is adding email two this week. That alone closes more of the welcome window than any other single action you can take in your flow architecture.

Then add email three. The welcome series compounds as you extend it, because each email you add catches the subscribers who were ready to buy on day three or day seven but had nothing from you at that moment. Every gap in your sequence is a subscriber who made a decision without you.

The Klaviyo 2025 benchmark data shows that welcome series with four or more emails consistently outperform single-email welcomes across revenue-per-recipient. In my experience, the difference is not small. A single email is leaving a compounding revenue opportunity on the table for every new subscriber who joins.

What Good Looks Like

When the welcome series is working properly, the programme stops relying on campaigns to convert new subscribers. First purchases happen inside the welcome window, before the subscriber has had time to disengage.

The abandoned cart flow, the post-purchase sequence, and every subsequent flow all perform better because the subscriber was properly introduced to the brand before they encountered them.

A well-built welcome series also reduces the pressure on promotional campaigns. When new subscribers are already converting in the first two weeks, you are not dependent on a sale email to recover them three months later. The relationship starts at a higher trust level and stays there.

From my experience, when a brand invests properly in the welcome series for the first time, it is often the highest single-flow revenue contributor in the first quarter after launch. Not abandoned checkout. Not post-purchase. Welcome. Because it is the one moment every subscriber passes through, and it is the moment where intent is at its peak.

Here is the tension at the heart of welcome series strategy: the moment a subscriber signs up is the single highest-intent moment they will ever have with your brand, and that is exactly when many brands send one email and go quiet. A discount code delivery. A receipt. Then silence until the next campaign blast.

The welcome window closes fast. Omnisend and Klaviyo benchmark data consistently show welcome series open rates running 2 to 3 times higher than standard campaigns. Engagement levels drop sharply after the first week. Purchase likelihood peaks early and then fades.

You get one shot at this window and the question is not just how many emails to send. It is how to structure them across the full window so that intent converts rather than evaporates.

This article gives you the complete framework. Six emails, fourteen days, with the specific job each email does, the timing rationale behind each gap, and the common mistakes that collapse the sequence before it earns its keep.

Why This Matters

According to the Omnisend Email Marketing Statistics Report 2025, welcome series emails generate substantially higher open and conversion rates than standard broadcast campaigns. The data consistently shows that welcome emails sent immediately upon signup outperform those sent even a few hours later. The window is not metaphorical. There is a real and measurable degradation in engagement as time passes from the signup moment. Most brands are late.

The Klaviyo Benchmark Report 2025 reinforces this from the revenue side. Welcome flows rank among the highest revenue-per-recipient automations across the DTC brands tracked in the data.

In my audits of brand email programs, I find that welcome series performance is often the single biggest lever a brand can pull before touching any other flow. Abandoned cart gets rebuilt first at many brands. The welcome series stays as a one-email stub. That is the wrong order. Fix the highest-intent window first, then optimise the recovery flows.

The Full Breakdown

The core mistake I see in welcome series builds is conflating email count with coverage. A brand sends six emails in four days and believes they have built a thorough welcome sequence. They have not. They have hammered a subscriber who just raised their hand and created pressure where there should be relationship. The variable that matters most is not count. It is spacing.

The fourteen-day window is not arbitrary. The first 48 hours capture the peak-intent subscriber who signed up because something triggered them: a recommendation, a social post, a paid ad they clicked, a piece of content that landed. Emails in this window should be operational and brand-establishing.

After that window, the subscriber has returned to their normal behaviour and is reading emails in a different state of mind. The middle of the sequence, days three through seven, is where you build the case at a lower intensity. Education, proof, differentiation.

The final phase, days eight through fourteen, is where you make and close the offer with a subscriber who has already been through the relationship-building phase.

A four-email series is the minimum that does this work properly. One email is a receipt. Two emails can deliver the incentive and introduce the brand but have no room for the trust-building that drives second purchase. Four emails get you through incentive delivery, brand story, social proof, and one offer close.

Six emails let you add product education and an FAQ-handling email, which is where a lot of the conversion lift comes from in higher-complexity or higher-pricepoint products.

The spacing between emails matters as much as the emails themselves. When I rebuild welcome series for brands, the most common problem is not missing content. It is emails stacked too tightly in the first 72 hours and then a gap from day four to day twelve while the subscriber forgets who the brand is. The framework below is structured to avoid both failure modes: the pressure that comes from overcrowding, and the drop-off that comes from underpacing.

Step-by-Step Implementation

1. Email 1: Immediate send. Deliver the incentive, introduce the brand.What: This email fires the moment the subscriber confirms their opt-in. It delivers exactly what was promised: the discount code, the freebie download, the exclusive access, or the content piece. Beyond the incentive delivery, it introduces the brand clearly. One to two sentences on what the brand is and what the subscriber can expect from the series. No hard sell here.Why: The immediate trigger is the most important timing decision in the entire sequence. According to Omnisend 2025 data, immediate welcome emails see significantly higher open rates than those delayed even a short time after signup. The subscriber is in the browser tab. Their inbox is open. Send now.Common mistake: Burying the incentive code halfway down a long welcome email full of brand narrative. Deliver the code in the first viewport. Everything else is secondary to the promise you made when they signed up.

2. Email 2: Day 1 to 2. The brand story.What: This email focuses entirely on differentiation. Not what you sell. Why you exist and what makes the brand different from everything else in the category. Founder story if it is relevant and compelling. Sourcing story if it is a differentiator. Mission if it is authentic and specific rather than generic.Why: The subscriber knows what you sell. They signed up. What they do not know yet is why they should buy from you rather than a competitor. This email answers that question while their interest is still high and the brand memory from Email 1 is fresh.Common mistake: Writing a brand story email that is really a product catalogue with a paragraph of copy at the top. The story email should not have more than one product mention, and that mention should serve the narrative rather than lead it.

3. Email 3: Day 3 to 4. Social proof and bestsellers.What: Curated reviews, ratings, user-generated content, and the two or three products that convert best for new customers. This email should reduce the anxiety a first-time buyer has about whether the product will actually deliver. Real quotes, real numbers, specific outcomes rather than adjectives.Why: By day three, the subscriber has seen the brand and heard the story. Social proof is the evidence that backs the claims. It converts the interested subscriber into someone with enough confidence to consider buying. Bestsellers narrow the decision: instead of browsing a full catalogue, the subscriber is looking at the three things that work best for people like them.Common mistake: Using generic review excerpts. "Great product, love it" does not reduce purchase anxiety. Find reviews that mention the specific problem the product solves or the specific outcome it delivers. Those are the ones that do the work.

4. Emails 4 and 5: Days 6 to 8. Education and FAQ handling.What: Two emails spaced two to three days apart that teach the subscriber something genuinely useful about the category, the product, or the problem the brand exists to solve. One of these emails should address the most common objections and questions you hear before a first purchase. Answer them directly and without defensiveness.Why: By this point the subscriber has the incentive, the brand story, and the proof. What is still stopping many of them from converting is residual uncertainty. They do not know how the product works in practice, or they have a question they have not found answered, or they are not sure the product applies to their situation. Education emails answer these without requiring the subscriber to go looking.Common mistake: Making the education email a thinly veiled sales email. If the educational content is genuine and useful, the conversion happens as a byproduct. If it reads like a sales pitch formatted as a how-to guide, it reads like a sales pitch.

5. Email 6: Day 11 to 14. Offer close.What: This is the dedicated conversion email. If the subscriber has not purchased by now, this email creates urgency around the original incentive or introduces a new, time-limited reason to act. Direct copy, clear CTA, specific expiry on the offer. One job only.Why: After five emails of value delivery, the direct ask has earned its place. The subscriber knows the brand, has seen the proof, understands the product. The offer close is not a cold pitch. It is a reminder and a final nudge from a brand they have now had a relationship with for two weeks.Common mistake: Making the offer close email apologetic. Phrases like "just a quick reminder" or "in case you missed our discount" undercut the urgency. State the offer clearly, state the expiry clearly, and let it stand on its own.

The Framework

Use this structure as a decision template when building or auditing any DTC welcome series. Each email maps to a specific subscriber state and a specific job.

WELCOME SERIES FRAMEWORK
========================

Email 1 | Immediate | Incentive delivery + brand intro
------------------------------------------------------------
Subscriber state: peak intent, just opted in
Job: deliver the promise, introduce the brand clearly
Content: incentive (code / download / access), 1-2 sentences on what the brand is
Length: short. Under 200 words of body copy.
CTA: one. Use the incentive.

Email 2 | Day 1-2 | Brand story
------------------------------------------------------------
Subscriber state: interested, memory of Email 1 fresh
Job: answer "why this brand over others"
Content: founder story, sourcing story, or mission (pick the most authentic one)
Length: medium. 250-350 words.
CTA: one. Secondary product or about page.

Email 3 | Day 3-4 | Social proof + bestsellers
------------------------------------------------------------
Subscriber state: considering, not yet decided
Job: reduce purchase anxiety, narrow product choice
Content: 3-5 specific reviews + top 2-3 products for new customers
Length: medium. Let the reviews lead.
CTA: one per featured product or one to bestsellers page.

Email 4 | Day 6-7 | Education
------------------------------------------------------------
Subscriber state: familiar, still non-converting
Job: teach something genuinely useful, build category authority
Content: how-to, use-case guide, or comparison relevant to the product
Length: medium-long. 300-400 words.
CTA: relevant product or resource.

Email 5 | Day 8-9 | FAQ and objection handling
------------------------------------------------------------
Subscriber state: uncertain, specific friction point blocking conversion
Job: surface and answer the 3 most common pre-purchase questions
Content: Q+A format. Direct answers. No hedging.
Length: short-medium. Questions lead, answers are brief and confident.
CTA: one to the product or a quiz / recommendation tool.

Email 6 | Day 11-14 | Offer close
------------------------------------------------------------
Subscriber state: brand-aware but unconverted
Job: create urgency, drive the first purchase
Content: offer reminder or time-limited incentive, specific expiry, clear CTA
Length: short. Under 150 words of body copy.
CTA: one. The offer.

SPACING RULE: Never stack two emails less than 24 hours apart after Email 1.
SEQUENCE EXIT: Tag and suppress anyone who purchases at any point. The series
is for non-converters. Buyers enter the post-purchase flow immediately.

Real Example

A DTC skincare brand I worked with in early 2026 had a three-email welcome series running on a five-day cadence. Email 1 delivered the discount code. Email 2 was a product catalogue sent two days later. Email 3 was a "your code expires soon" reminder on day five. Their conversion rate from the welcome series was below what the Klaviyo Benchmark Report 2025 shows as average for the skincare category.

The audit identified two problems. First, the brand story email was missing entirely. The subscriber went from incentive delivery to product catalogue with no context about what made this brand different. In a category with dozens of direct competitors, that absence was costly.

Second, the five-day total window left a twelve-day gap with no contact before the next campaign send landed. Subscribers who did not convert in the welcome window were receiving brand communications again after nearly two weeks of silence, and by then the connection had faded.

We rebuilt the series to six emails over fourteen days following the framework above. Email 2 was rewritten as a pure brand story with no product push. Email 3 introduced the top three products for first-time buyers with real review excerpts that named specific outcomes. Emails 4 and 5 covered the two most common questions the support team received from pre-purchase customers. Email 6 was a clean offer close with a five-day expiry. One job. One CTA.

Within sixty days, the conversion rate from the welcome series increased by roughly a third compared to the previous three months. The biggest single driver was closing the gap between day five and day fourteen. Subscribers who would previously have fallen into silence were still receiving relevant contact from the brand and converting at a meaningful rate across the Email 4 to Email 6 window.

Audit Checklist

• Email 1 fires within five minutes of signup confirmation, not on a batched schedule

• The incentive or promised content is in the first viewport of Email 1, not buried below the fold

• There is a dedicated brand story email (not a product catalogue with an intro paragraph)

• At least one email in the series features specific, outcome-oriented reviews rather than generic positive sentiment

• No two emails are sent less than 24 hours apart (except Email 1, which is immediate)

• The series runs at least ten days, with coverage extending to day twelve or fourteen for the offer close

• Subscribers who purchase at any point in the series are tagged and moved out of the welcome flow into post-purchase

• The final email has a single CTA and a specific offer expiry rather than an open-ended "shop now" prompt

• The series has been reviewed against current Klaviyo Benchmark data for your product category to sanity-check open and conversion rates

• Every email in the series has one primary job. If you can name two equal jobs, split the email or cut the weaker one

Many brands think they have an email program. What they actually have is a newsletter they send on Tuesdays and a discount code they fire when someone abandons a cart.

That is not an email program. That is one tool, used occasionally, in a system designed to have four.

What Is Actually Happening

Email marketing in 2026 is four distinct types of communication, each with a different trigger, a different audience relationship, and a different revenue role. Run all four and you have a system. Run one and you have a broadcast channel dressed up as a strategy.

The four types:

• Campaigns: manually sent broadcasts to a segment. Promotions, newsletters, product launches, time-sensitive announcements. You decide when they go, you decide who gets them.

• Flows: triggered automatically by subscriber behaviour. Welcome series, abandoned checkout, post-purchase, win-back. Set up once, run indefinitely. Revenue-per-recipient is highest here.

• Transactional emails: order confirmations, shipping notifications, password resets. The most-opened email a brand typically sends. Also, from my audits, frequently the ugliest and least on-brand.

• Lifecycle emails: sent based on where someone is in the customer relationship. First purchase milestones, anniversary emails, re-engagement sequences before a subscriber goes cold. These are the most often missing entirely.

In practice, many brands run campaigns reasonably well. They build one or two flows, usually abandoned cart and maybe a post-purchase sequence. They have transactional emails because the ESP ships them by default.

Lifecycle is almost entirely absent.

The problem is not awareness. I find in my audits that many brand owners know flows exist and know they could do more with them. The gap is prioritisation.

Campaigns feel urgent and visible. You can see the revenue attributed to a promotion in 24 hours. Flows are quiet, persistent, and compound over time. That makes them easier to deprioritise and harder to justify building when the quarter is tight.

From what I see across client work and consistent with the patterns in the Litmus State of Email 2025, brands investing across all four email types generate meaningfully more revenue per subscriber than those focused on campaigns alone. That gap does not close. It widens as the subscriber base grows, because flows scale at zero marginal cost per additional subscriber.

The One Fix

Run an email type audit before you build anything new.

Open your ESP. List every active send you have, including automated flows and transactional. Group each one into campaign, flow, transactional, or lifecycle. Then look at which category is empty or close to it.

For the brands I audit, flows typically have two to three active sequences at most. Lifecycle will be empty. Transactional will be functional but unbranded.

Pick the single highest-leverage gap and address it before adding to what already exists. For a brand with no welcome series, that is the answer. For a brand with a welcome series but nothing after the first purchase, a post-purchase sequence is it.

For a brand sending generic transactional emails to a list that gets eight campaigns a month, bringing transactional email up to brand standard will have a disproportionate return, because open rates on that type are exceptionally high.

Do not try to fix all four at once. Identify the category where you are leaving the most on the table, build one thing in it, let it run for 30 days, then evaluate. That is the compounding nature of automation working for you rather than against you.

What Good Looks Like

When all four types are working, the program stops feeling like a series of individual decisions and starts functioning like a system. Campaigns drive short-term revenue and keep the relationship active. Flows capture intent at the moment it exists, automatically. Transactional emails reinforce the brand at the highest-trust touchpoints. Lifecycle emails surface at the right relationship milestone without anyone manually triggering them.

The result is a subscriber who never goes very long without a relevant touchpoint, regardless of whether you ran a campaign that week. That consistency is what separates programs that plateau from programs that compound.

Revenue-per-subscriber grows because more of the subscriber's journey is covered, not because you are sending more campaigns.

From my experience working with DTC brands, the shift usually happens when someone stops asking "what should we send this week" and starts asking "which parts of our subscriber journey do we not have coverage on." Those are fundamentally different questions. The second one is the right frame.

15 years in. Here is what this publication delivers.

I have been designing and developing emails since before responsive layout was standard practice. Before dark mode was a production concern. Before AI entered the workflow.

In that time I have worked with brands across industries, built automation architectures from scratch, and watched a lot of confident advice age badly.

This publication shares what I have actually learned.

What we cover

Ten pillars guide the content here. Each maps to a real, active area of email practice.

Email Fundamentals. The mechanics everything else depends on: list health, permission frameworks, send cadence, and the baseline decisions that compound over time.

Flow Architecture. How to structure automated sequences that actually perform: welcome flows, post-purchase journeys, re-engagement campaigns, and the architecture connecting them.

Email Design Principles. Layout, visual hierarchy, and the patterns that make emails readable across devices and clients.

Copywriting for Email. Subject lines, preview text, body copy structure, and the specific techniques that move people from open to click.

Email Development. Most emails are built for best-case rendering. The technical reality is messier: Outlook’s Word-based engine, inconsistent dark mode implementations, and client quirks that no design tool warns you about. This pillar covers what you actually need to know to build emails that hold up.

Dark Mode. A dedicated pillar. Getting things right in email clients with dark mode is very tricky. This covers what actually works in production.

ESP Behaviour. How the major platforms operate behind the scenes: Klaviyo, HubSpot, ActiveCampaign, Mailchimp. What they do and how it shapes your results.

Deliverability. IP reputation, domain authentication, list hygiene, and the signals that determine inbox placement.

Analytics and Testing. What to measure, how to run tests that produce real signal, and how to build a testing practice that compounds over time.

Myths and Contrarian Takes. Email advice repeated until it becomes received wisdom. Most of it does not survive scrutiny.

And a new pillar that reflects where email production sits in 2026: AI in email production.

This is not about AI-generated campaigns or personalisation at scale. It is about the production workflow: image generation, code assistance, content scaffolding, and where AI tools remove genuine friction.

In my work with clients, the same pattern repeats. Simple fixes that would lift performance sit undone. Better content stays unwritten because the production cost feels too high. Money left on the table, consistently.

AI tools are changing that equation. This pillar covers where they help, where they fall short, and how to build a workflow that gets more out of every send.

Who this is for

Email designers and developers who want to sharpen their craft.

Marketing managers running email in-house who want to understand what is actually happening under the hood.

Agency operators building scalable email systems.

If you are looking for generic marketing content, this is not the place. Every post makes a specific, defensible point.

What to expect

Articles on each pillar, with real examples and sourced data.

Alongside the articles, I post Notes: shorter observations from active client work, quick findings from testing, and things that do not warrant a full piece. Think of them as working notes from a live practice.

New posts go out regularly. No filler, no padding.

Christian Lundgren Co-founder, Remint