> ## Documentation Index
> Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Configuration

> How the platform becomes yours — brand tokens, your domains, your sender domain, and your copy. Subscribers see your product, not Recurr.

Recurr's subscriber-facing surfaces are configured to your brand at four layers: visual identity, the domains your subscribers land on, the sender domain your migration and lifecycle emails come from, and the copy that ships across every touchpoint.

## Brand tokens

Color, type, accent, logo — set once, rendered across every surface (landing pages, migration emails, branded checkout, billing portal, help center).

<CardGroup cols={2}>
  <Card title="Color" icon="palette">
    Primary, accent, surface, text, border. Light and dark mode tokens supported.
  </Card>

  <Card title="Type" icon="font">
    Display, body, mono. Web-font upload or Google Fonts reference. Type ramp follows your spec.
  </Card>

  <Card title="Logo" icon="image">
    Wordmark + mark (square avatar). Light and dark variants. SVG preferred.
  </Card>

  <Card title="Accent + states" icon="droplet">
    Hover, focus, success, danger. Inherited from your design system or set explicitly.
  </Card>
</CardGroup>

Tokens are handed off as JSON, a Figma variables export, or via your existing design-system tool. We mirror them into our render pipeline once; subsequent updates ship via the same token format.

## Your domains

Subscribers land on sub-domains your DNS controls. The address bar carries your brand, never Recurr's.

<Steps>
  <Step title="Choose your sub-domains">
    Common patterns: `subscribe.yourapp.com` (checkout), `billing.yourapp.com` (portal), `help.yourapp.com` (knowledge base). You can also share one sub-domain across surfaces.
  </Step>

  <Step title="Point DNS at Recurr">
    CNAME records for each sub-domain. Provisioning takes minutes; SSL certificates are issued and renewed automatically.
  </Step>

  <Step title="We render under your domain">
    Every surface served at your sub-domain. No Recurr URLs in the address bar, no Recurr branding in the headers, no fingerprints in the markup.
  </Step>
</Steps>

## Your sender domain

Migration emails and lifecycle messages come from your sender domain — `hello@yourapp.com` or similar — not from us.

DNS records (SPF, DKIM, DMARC) are set up at onboarding so deliverability is locked from the first send. Sender reputation accrues to your domain, not to a shared Recurr sender. The subscriber's inbox shows your brand, your address, your reply path.

## Copy you control

Recurr's platform is self-serve for ongoing copy — email subject lines, checkout headlines, billing-portal microcopy, help-center articles. Your team edits directly in the operator dashboard and ships at your cadence.

The exception is **migration copy** — the email sequence and checkout messaging that runs during the controlled migration. Migration is a managed service, so we workshop the migration copy with your team during onboarding: we draft based on your voice guide and cohort plan, you shape and approve, we ship.

Once the migration completes, copy is fully self-serve on the platform.

<Note>
  Templates are starting points, not gates. Nothing ships without your sign-off — for migration copy (during the managed onboarding) or for ongoing platform copy (which you control directly).
</Note>

## What this means for stakeholders

* **Founders**: Subscribers never see Recurr. The platform stays out of view; your brand carries through every touchpoint.
* **Designers**: Hand off your design system once. Pixel-tight rendering across all five surfaces. Iterate via tokens, not Recurr support tickets.
* **Marketing**: Your sender domain, your voice, your copy. Migration is workshopped together; ongoing campaigns are yours to ship.

## Related

* [Subscriber continuity →](/product/subscribers)
* [Bring your brand to subscribers — apply for a pilot →](https://recurr.dev/apply)