Email dunning launch guide

Use this guide to take recovery emails from initial setup to production. It covers your sending domain, DNS authentication, engagement tracking, sender identity, branding, Slicker’s initial scenarios and templates, testing, launch, and reporting. For the product concepts first, read the Emails overview.

Before You Start

Gather the following before configuring emails:

Access to the DNS provider for the domain you will use.
A monitored support address for customer replies.
Your logo, brand color, help text, signature, and footer links.
The payment or billing-page URL customers should reach from the CTA.
An owner who will review scheduled sends and recovery performance after launch.

If another system already sends payment-recovery emails, decide which cohorts each system owns. Running both systems for the same customer and failure can create duplicate messages. A controlled comparison is fine, but define the split before enabling Slicker scenarios.

Phase 1: Set Up the Sending Domain

Choose a Dedicated Subdomain

Use a subdomain such as billing.example.com, payments.example.com, or recovery.example.com. This separates recovery-email reputation from your root domain and from other important mail such as login, support, and marketing messages. It also lets Slicker serve tracked images and links from a domain aligned with the sender.

A root domain such as example.com can be used only after acknowledging the deliverability trade-off. Open and click tracking cannot be configured on a root domain, so a dedicated subdomain is strongly recommended.

Add the Domain

Open email settings

Go to Emails → Settings and select Add Your First Domain or Add another domain.

Enter the full sending domain

Enter the subdomain, for example billing.example.com. Do not enter a protocol, path, or email address.

Copy the generated DNS records

Slicker generates the exact type, name, value, priority, and TTL that your DNS administrator should publish.

Publish the DNS Records

Record group	Purpose	Requirement
SPF and DKIM	Authorize sending and cryptographically authenticate each message.	Required before sending.
DMARC	Tells receiving servers how to handle failed authentication and helps prevent spoofing.	Recommended. Start with the policy Slicker provides.
Click & Open Tracking	Routes tracked images and links through your sending subdomain.	Optional, but required for engagement metrics. Available only for a subdomain.

Add every record exactly as displayed in Slicker. Most DNS providers automatically append your DNS zone to the record name, so the Settings page shows names without the zone where appropriate. If verification cannot find a record, check whether your provider expects the full hostname instead.

DNS changes are not immediate. Propagation can take up to 48 hours depending on the provider and existing TTL. A pending record during that window does not necessarily mean the value is wrong.

After publishing the records, return to the domain’s DNS Records panel and select Verify DNS. The UI shows each record as pending or verified. If a record remains pending after propagation:

Compare its type, name, value, priority, and TTL with the Slicker value.
Check that the provider did not append the zone twice, such as record.billing.example.com.example.com.
If you used the short record name, try the full hostname, or vice versa, based on your provider’s convention.
Remove conflicting records only after confirming they are not used by another mail service.
Re-run Verify DNS.

SPF and DKIM must both verify before Slicker can send recovery emails from the domain.

Configure the Sender Identity

Complete the domain’s Email Settings:

From email prefix — use a recognizable purpose such as billing, payments, or subscriptions. Avoid noreply or no-reply; they discourage responses and can hurt trust and deliverability.
Friendly name — use the brand name customers recognize, such as Acme Billing.
Reply-To — use an active, monitored mailbox that can resolve billing questions.
BCC — optionally add comma-separated internal recipients when your compliance or audit process requires a copy of every message.

If you configure multiple domains, set the normal fallback domain as Default. A non-default domain can be assigned to a specific email configuration. The default domain cannot be deleted until another domain becomes the default.

How Open and Click Tracking Works

When tracking DNS is configured, links and images in a recovery email use your sending subdomain rather than an unrelated third-party hostname. Behind the scenes, Slicker proxies those requests through its tracking infrastructure:

An open is recorded when the email’s tracking image is requested.
A click is recorded when a recipient follows a tracked CTA, content, or footer link.
Analytics excludes activity identified as automated bot traffic from engagement charts.

Tracking does not change whether the email can be sent. Without the tracking records, recovery emails continue to send, but opens and clicks are not collected.

Open and click data is approximate. Some email clients block remote images, and security scanners may prefetch images or links. Use engagement rates to compare trends and copy variants, not as proof that an individual person read a message.

Phase 2: Create the Email Configuration

Go to Emails → Styling & configuration. An email configuration combines a sending domain with the shared visual and CTA settings applied to templates.

Name the configuration and choose a domain

Use a name that identifies the brand or business unit. Select a verified sending domain and make the configuration the default if scenarios should use it unless another is assigned.

Add your branding

Upload a logo or provide a hosted logo URL, then choose its height and alignment. Select an email-safe font and your CTA button color.

Configure the CTA

Add clear button text and a valid HTTPS billing or payment-update URL. Leave button text empty only when the email should have no CTA.

Complete the support content

Add help text, a recognizable signature, and valid footer links. Remove placeholder # links before launch.

Preview and test

Review the live preview and send a test email to real inboxes used by your team. Save the configuration when the sender, links, images, and replies behave correctly.

Create separate configurations when brands, business units, domains, or CTA destinations need different presentation. Each scenario can use a named configuration or the default.

Phase 3: Review Scenarios and Templates

Slicker prepares an initial set of scenarios and templates for your business during onboarding. Open Emails → Scenarios to review them before launch.

Review Every Scenario

The scenario list shows its name, payment-failure trigger, priority, template count, and enabled status. Detailed View adds performance metrics when data is available. Open a scenario to review or change:

Setting	What it controls
Name and description	How the scenario is identified by your team.
Trigger	The payment-failure category the scenario handles.
Priority	Which scenario wins when the same candidate matches more than one enabled scenario. Higher values are evaluated first.
Email configuration	The sending domain, branding, and CTA configuration used for its templates.
Enabled	Whether the scenario can schedule recovery emails.

Keep a scenario disabled while its audience or copy is still under review. When priorities overlap, confirm that the most specific or important scenario has the higher value.

Review and Edit Templates

Each scenario contains its email templates. Open a template to review the rendered preview and edit its name, description, subject, and body. The editor lists the variables available for customer, payment, invoice, and company data. Templates use a sequence position:

First — the first-touch message.
Middle — a follow-up while recovery remains open.
Final — the last message in the sequence.

You can add another template from the scenario page and choose its sequence position, priority, and initial enabled status. When several enabled templates are available for the same step, Slicker can select between those copy variants using their configured traffic weights. For each template:

Use a subject that clearly identifies the account or payment action without exposing sensitive data.
Explain what failed and what the customer should do next.
Keep the CTA consistent with the action in the copy.
Check that every variable renders correctly in the preview.
Send a test email and open it on both desktop and mobile.

A successful test verifies rendering and delivery of the test message. It does not prove that every production customer has complete source data or that every customer-specific URL can be resolved.

Phase 4: Validate and Launch

Before enabling production scenarios, confirm:

The dedicated subdomain is in use.
SPF and DKIM show as verified; DMARC is published.
Tracking DNS is verified if you need open and click metrics.
The friendly name, from address, reply-to address, and optional BCC list are correct.
Every active scenario points to the intended email configuration.
Every active scenario has suitable enabled templates for its sequence.
Subjects, variables, logo, CTA, signature, and footer links render correctly in test inboxes.
Static and customer-specific CTA destinations use HTTPS and lead to the intended account.
Another recovery-email system will not message the same customers unintentionally.
Your support and billing teams know what customers will receive and where replies will arrive.

Enable the agreed scenarios after the checklist passes. For a cautious rollout, begin with a limited audience coordinated with Slicker, review the first scheduled and sent emails, and expand after the content and recovery results look correct.

Phase 5: Monitor Email Operations

Overview

The Emails overview shows:

Scheduled emails and the number of unique customers represented.
Invoices recovered and the recovered amount.
Total emails sent, including the last 30 days.
Email open rate and email click rate when engagement reporting is available.

The tables below the cards provide quick access to recent scheduled and sent messages.

Scheduled and Sent Emails

Use Scheduled Emails to inspect pending messages before they run. Filter or sort by recipient, scheduled time, amount, invoice, or scenario, then open a preview to verify the rendered message. Use Sent Emails to inspect completed sends, the executed time, scenario and invoice context, and whether the associated invoice was recovered. Provider acceptance means the provider accepted Slicker’s send request; it does not guarantee inbox placement or prove that the recipient read the email.

Analytics

Use the date picker on Emails → Analytics to review:

Sent emails by scenario and over time.
Recovery rate by scenario.
Scheduled volume for the next seven days.
Sends by hour and day of week in UTC.
Monthly recovered-invoice count and recovered amount.
Open and click rates over time, clicks by link type, open rate by scenario, and click-to-open rate by template when tracking data is available.

Review scenario results over a meaningful sample rather than reacting to a few sends. Compare recovery rate alongside volume: a narrowly targeted scenario may have a high rate but affect fewer invoices.

Dynamic Billing-Page URLs

A static button URL works when every recipient can start from the same login or billing-portal page. Use a dynamic billing-page destination when each customer needs a different CTA, such as a signed payment-update URL stored on their Customer.io profile. Slicker supports customer-specific URLs stored in a Customer.io attribute. At send time, Slicker looks up the recipient by email, reads the configured attribute, adds any configured query parameters, and validates the result against your destination-host allowlist. The email contains an expiring, opaque Slicker redirect instead of exposing the resolved URL in email-processing history or tracking data. To configure a destination:

In Customer.io, enable email identifiers and populate an attribute containing an absolute HTTPS billing-page URL for each customer. Create a dedicated Customer.io App API key for Slicker.
Open Emails → Styling & configuration, edit an email configuration, and expand Call to Action Button.
Keep a valid static Button URL for disabled and shadow operation. Under Dynamic billing-page destination, select Manage and create a Customer.io attribute destination.
Choose the Customer.io region, enter the attribute name and App API key, and add any query parameters as one key=value pair per line.
Add every permitted billing-page hostname. A hostname must match this allowlist before Slicker uses the resolved URL; prefix an entry with . to allow its subdomains.
Choose whether a failed resolution should fail the email or use an explicitly configured static fallback. Set an appropriate link lifetime, then save the destination in Shadow mode.
Run the end-to-end connection test, then allow representative recovery emails to run in Shadow mode. Shadow mode validates live lookups while recipients continue to receive the static URL. A manual test does not count as live shadow evidence.
After the saved configuration has passed both the connection test and a live shadow resolution, change it to Active and save the email configuration with the destination selected.

Changing provider settings starts a new validation cycle. Move the destination back through Shadow mode before reactivating it. To stop using customer-specific links, select the static button URL or set the destination to Disabled.

Email-Outcome Webhooks

Use an email-outcome webhook when your system should react after Slicker attempts a recovery email—for example, to send an SMS through your existing provider. Slicker sends the event; your system remains responsible for phone-number storage, consent, quiet hours, message delivery, and recipient deduplication. Configure the webhook in Emails → Webhooks:

Enter one public HTTPS endpoint and a Bearer token. Local, private-network, and redirecting destinations are rejected. The token is write-only and is sent in the Authorization: Bearer … header.
Choose whether to emit after every email-provider attempt or only after the provider accepts the email. Provider acceptance is not inbox delivery, and a later bounce does not emit another event.
Choose the payload copy source. Slicker can include a custom message for another channel, include the rendered subject and body of the selected recovery email, or send only structured event fields so your endpoint can compose its own message.
Set the default for all scenarios, then add per-scenario enablement or message overrides where needed. New scenarios inherit the default.
Save the configuration, select a scenario, and send a test event. Test deliveries are marked with test: true, appear in delivery history, and are not retried.
Enable the endpoint after your receiver validates the sample payload and returns a 2xx response.

Production events use the dunning_email_attempted type and include a stable event ID plus structured scenario, customer, invoice, and email-attempt data. Depending on the copy source, data.message or data.emailCopy is also present:

{
  "id": "whdr_01...",
  "type": "dunning_email_attempted",
  "created": "2026-09-24T10:30:00Z",
  "data": {
    "schemaVersion": 1,
    "test": false,
    "dunningActionId": "dact_01...",
    "scenario": { "id": "dsc_01...", "name": "Card expired" },
    "customer": { "id": "cus_123", "email": "customer@example.com" },
    "invoice": { "id": "inv_123", "amountMinorUnits": 1299, "currency": "USD" },
    "email": {
      "templateId": "etpl_01...",
      "result": "accepted",
      "attemptedAt": "2026-09-24T10:29:58Z"
    },
    "message": "Please update your payment method."
  }
}

Webhook delivery is at least once. Slicker sends the same stable event ID in the body and the Idempotency-Key header. Persist that value before triggering SMS or another customer-facing action. Failed production deliveries are retried with exponential backoff, up to five total attempts, without delaying or changing the original email result. Delivery history shows the payload, attempt count, response status, and any truncated error. It contains customer data and should be available only to authorized users.

Ongoing Review

After launch, establish a regular review cadence:

Check pending volume for unexpected spikes or gaps.
Investigate failed sends and invalid customer data.
Compare recovery rate and recovered amount by scenario.
Compare copy variants only after they have meaningful volume.
Treat open and click rates as directional and prioritize paid-invoice outcomes.
Re-test sender identity, CTA destinations, and webhooks after configuration changes.
Update scenarios and templates as products, billing flows, or support policies change.

For platform-wide recovery reporting, continue with Analytics & Reporting.

Getting Started

Essentials

Guides

Email dunning launch guide

Before You Start

Phase 1: Set Up the Sending Domain

Choose a Dedicated Subdomain

Add the Domain

Publish the DNS Records

Configure the Sender Identity

How Open and Click Tracking Works

Phase 2: Create the Email Configuration

Phase 3: Review Scenarios and Templates

Review Every Scenario

Review and Edit Templates

Phase 4: Validate and Launch

Phase 5: Monitor Email Operations

Overview

Scheduled and Sent Emails

Analytics

Dynamic Billing-Page URLs

Email-Outcome Webhooks

Ongoing Review

​Before You Start

​Phase 1: Set Up the Sending Domain

​Choose a Dedicated Subdomain

​Add the Domain

​Publish the DNS Records

​Configure the Sender Identity

​How Open and Click Tracking Works

​Phase 2: Create the Email Configuration

​Phase 3: Review Scenarios and Templates

​Review Every Scenario

​Review and Edit Templates

​Phase 4: Validate and Launch

​Phase 5: Monitor Email Operations

​Overview

​Scheduled and Sent Emails

​Analytics

​Dynamic Billing-Page URLs

​Email-Outcome Webhooks

​Ongoing Review

Before You Start

Phase 1: Set Up the Sending Domain

Choose a Dedicated Subdomain

Add the Domain

Publish the DNS Records

Configure the Sender Identity

How Open and Click Tracking Works

Phase 2: Create the Email Configuration

Phase 3: Review Scenarios and Templates

Review Every Scenario

Review and Edit Templates

Phase 4: Validate and Launch

Phase 5: Monitor Email Operations

Overview

Scheduled and Sent Emails

Analytics

Dynamic Billing-Page URLs

Email-Outcome Webhooks

Ongoing Review