Why a Sunset Policy Matters

A clear sunset policy is one of the simplest ways to protect both the performance and cost of your email program.

• Improves deliverability: Prevents messages from drifting into spam folders by avoiding disengaged inboxes. Remember, ISPs are judging your emails and your domain by whether they are getting opened and clicked.
  
• Protects sender reputation: Keeps your domain and IP associated with real engagement, not ignored sends. High click and open rates signal that you provide value.
  
• Boosts engagement metrics: Sending primarily to active users lifts open rates, clicks, and conversions.
  
• Saves money: Reduces contact-based costs from ESPs and CRMs that charge by audience size.

How to Build Your Sunset Policy

Think of your email list as a set of concentric circles, each with a clear purpose. Every contact should belong to exactly one of these groups at any given time.

1. Define Your Emailable Range

Suggested name: Emailable or MaxEmailable

This is the largest audience you are willing to email under any circumstances.

When you really need to stretch your list, for example, for a major annual sale or required operational messages, this is as far as you go.

If you’re not sure where to start, anchor yourself in legal guidelines. While the U.S. remains relatively permissive, I typically default to CASL standards as a conservative baseline:

• 24 months for purchasers, volunteers, or anyone with a deliberate, documented relationship (including email engagement)
  
• 6 months for prospects or “looky-loos” who haven’t engaged with an email
  

Yes, there are nuances. You’ll refine this over time. But this gives you a defensible starting point.

This group must be large enough to cover operational obligations, such as:

• Terms and conditions updates
• Pricing or policy changes
• Required legal notifications
  

You may also tap into this group cautiously for rare, high-impact sends.

2. Define Your Sunsetting Group

Suggested name: Sunsetting

This group lives outside your emailable range.

You do not send to them. However, they are close enough to re-entry that you’re willing to give them time to come back on their own.

This group primarily exists for visibility and alignment:

• To show leadership that you’re giving disengaged users a reasonable chance to return
• To avoid premature deletion that might raise concerns internally
  

How long contacts stay here depends on two factors:

1. Pressure from leadership to retain records
   
2. Per-contact cost from your ESP or CRM
   

Once someone ages out of this group, they can be safely removed from your database.

3. Define Your Engaged Group

Suggested name: Engaged or timeperiod_engaged

This is your core audience and should represent the majority of your sends.

To define it, look at your conversion data:

• How engaged were users before they converted?
• At what point does conversion drop to near zero?
  

That drop-off point defines your engagement window.

This is your bread-and-butter audience that drives:

• Revenue
• Retention
• Most of your testing and optimization
  

4. Define Your Highly Engaged Group

Suggested name: Highly_Engaged

These users:

• Open and click consistently
• Have frequent site or app sessions
• Actively recognize your brand
  

Use this group strategically:

• Mini-warming: Send to them first to generate early opens before holiday campaigns, major launches, and high-volume sale days
  
• Perks: Early access, reminders, or after-hours nudges
  

This group is one of your strongest levers for deliverability control.

5. Optional: Define a Very Highly Engaged Group

This is your smallest but most powerful audience.

These are:

• Brand advocates
• Power users
• People who will “go to the mattresses” for you
  

Use them when you want to:

• Generate buzz before a launch
• Test messaging
• Seed momentum organically
  

Not every program needs this group, but when it exists, it’s incredibly valuable.

Re-Engagement Campaigns: Run Them in Stages

A sunset policy only works if you give people clear chances to re-engage before they age out.

1. Brand Re-Engagement

Use this when users still open emails but haven’t interacted with your product or site.

Focus on:

• What’s new
• What’s changed
• New features or offerings
• Fresh value they may have missed
  

This is about reminding them why they signed up.

2. Email Re-Engagement

Trigger this when email engagement itself starts to decline.

Run this before they leave your engaged group.

Tactics include:

• Your most compelling or highest-performing content
• A reminder of the preference center
• Frequency options
  

For example, if they are on a daily email, offer them a weekly digest that hits the week’s highlights.

3. Final “We Miss You” Message

This is your last stop before they leave the emailable range.

Be direct and transparent:

• Let them know they’ll stop receiving emails in X days
• Explain what they’ll miss if they don’t re-engage
• Clarify that they’ll also fall outside the operational notification window
• Give them one clear path back
  

This message should feel respectful, not desperate. It’s about consent and clarity, not guilt.

---

A strong sunset policy isn’t about sending fewer emails.
It’s about sending smarter emails to people who actually want it.

---

---

I usually like to give you something you can test and measure right away. This post is a little different. It is more “foundational principle” than “run this A/B test,” but it will save you headaches for years if you get it right early.

---

---

I am knee-deep in updating our data dictionary at work right now, so this is very front of mind:

When you are creating or revisiting your CRM / lifecycle database, pass raw data. Do your calculations in your CRM platform.

That is it. That’s the whole tip. But let’s explore it a little more, because it matters a lot.

What “Raw Data” Actually Means

When I say “raw data,” I mean the facts, not someone’s interpretation of the facts.

• Raw: reward_expiration_date = 2025-12-31
• Not raw: rewards_expiring_soon = true
• Raw: current_storage_used_gb = 87.4
• Not raw: over_80_percent_storage_used = true

If you give your CRM the raw number or date, you can do whatever you want with it later. If you give it a sliver of logic someone hard-coded upstream, you are stuck with that decision until you convince someone in your product or engineering team to change it.

In marketing, nothing is constant.

Lifecycle is all about timing, thresholds, and conditions. And those things change a lot.

Your timing will change.

Today, you might want to warn people 14 days before their reward points expire. Six months from now, you might learn that 7 days before performs better. Later, you might decide on a 3-touch sequence at 21, 7, and 1 day.

If you asked your product team to send an event when a member is 14 days from their expiration date or an attribute such as:

Rewards_expiring_14_days = true

you are now blocked every time you want to adjust timing. You need new events, new logic, new QA, and a slot in someone’s sprint. But, if you’re sent :

Rewards_end_date = MM-DD-YYYYTHH:MM:SSZ

Set up your own rules in Braze, Iterable, SFMC, whatever you use:

• Send email 1 when today = subscription_end_date – 14 days
• Send email 2 when today = subscription_end_date – 7 days
• Send SMS when today = subscription_end_date – 1 day
  

You don’t need to submit a Jira ticket. You have all the information you already need.

Your thresholds will change.

Same story with usage-based products. If your membership levels are based on storage usage, and you send:

• current_storage_used_gb
• storage_limit_gb
  

You can run a dozen different experiments over time:

• “Nudge at 70 percent, push upgrade at 90 percent.”
• “Test a usage digest email every Monday.”
• “Offer a temporary boost when someone hits 100 percent.”
  

But, if you send a binary flag like:

approaching_storage_limit = true

You now have no idea what “approaching” means without digging into legacy documentation. And if you want to change that threshold, you are back in someone else’s backlog.

Your business model will change.

This is the big one people forget. And, when it does, your engineering team will be heads down, creating new, revenue-driving code to match the new model. Your emails are not their top priority. 

If your events and attributes are tightly coupled to the current marketing approach, your database becomes a graveyard of half-understood events when the business changes.

It is much easier to explain “this is the date something happened” than “this was a special flag from three pricing models ago and no one is sure what it means now.” Future you will be grateful that you decided to keep things generic and flexible.

What This Looks Like

Here are a few common patterns and how I would handle them.

Usage-based nudges

Ask for:

• current_storage_used_gb
• storage_limit_gb
• last_updated_at (optional)
  

In your CRM:

• Create segments by percent of storage used.
• Trigger alerts when someone crosses a threshold.
• Test different upgrade prompts without touching the data feed.
  

Rewards and points

Ask for:

• reward_balance
• reward_expiration_date (per bucket if you have rolling expiry)
  

In your CRM:

• “Your points are expiring soon” journeys based on date math
• “You have enough for X reward” messages based on balance logic

“But engineering says this is easier their way.”

You will probably hear one of these:

• “It is easier if we just send you a 14-day reminder event.”
• “We already calculate ‘approaching limit’ for the UI.”
• “We do not want business logic duplicated in multiple places.”

Totally valid concerns, but here is the counterpoint:

1. CRM rules change faster than product logic. Marketing needs to run tests, adjust timing, and pivot messaging much more frequently than teams want to ship code.
   
2. Raw data is reusable across teams. Product, analytics, finance, and marketing can all use “end date” or “usage” data differently. A one-off flag is usually useful to one team and confusing to everyone else.
   
3. You can still mirror their logic if needed. If the application already calculates “approaching limit,” great. Keep that for the UI. Still pass the underlying usage number so CRM and analytics stay flexible.

Try This Week

If you want a concrete action item, here is your mini-audit:

1. Pick one key lifecycle journey. Renewal, trial conversion, usage upgrade, or expiring rewards.
   
2. List every event and attribute you use for it today. Look for anything that sounds like a pre-baked decision:
   • *_in_14_days
   • *_expiring_soon
   • *_approaching_limit
   • Booleans that describe timing instead of facts
     
3. Identify the raw data behind those flags. What actual date, count, or amount is that flag based on?
   
4. Plan a data request to shift to raw fields. You might not get it all done this week, but at least you will know what to ask for the next time you touch the integration.
   
5. Update your data dictionary. Document the raw fields, how they are used, and deprecate the legacy “magic” flags as you phase them out.
   

Remember: Dates and numbers in; opinions and timing rules out.

Your future campaigns, future teammates, and future self will have a lot more freedom to experiment, iterate, and clean things up without opening a single engineering ticket.