# Bounce domain

Your **bounce domain** is the return-path hostname on a [sending domain](/docs/guides/email/sending-domains) — the envelope-from address that bounces and delivery feedback are sent to. Pointing it at Bird with one CNAME does two jobs at once: it lets Bird collect and process bounces for you, and it gives you SPF alignment without publishing anything at your domain apex. It's one of the three records that gate sending, so every domain has one.

This page covers the return-path specifically. For the full record set and the verification lifecycle, see [sending domains](/docs/guides/email/sending-domains); for what each record proves, see [DKIM, SPF & DMARC](/docs/guides/email/dkim-spf-dmarc).

## The record

The return-path is a CNAME under your sending domain that resolves to Bird's bounce infrastructure in your region:

| Type  | Host               | Value                      |
| ----- | ------------------ | -------------------------- |
| CNAME | `send.example.com` | `<region>.bounce.bird.com` |

The value is region-specific — `us1.bounce.bird.com` or `eu1.bounce.bird.com` — so copy it from your domain's detail page (open it from the [**Domains**](https://bird.com/dashboard/w/email/domains) page) or the domain resource rather than constructing it. The host defaults to `send.` under your sending domain.

## Customizing the hostname

You choose the label when you register the domain — pass it as `return_path.name` and Bird composes the full hostname under your sending domain:

```bash
curl -s https://us1.platform.bird.com/v1/email/domains \
  -H "Authorization: Bearer $BIRD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "domain": "mail.acme.com",
    "return_path": { "name": "bounce" }
  }'
```

That registers `bounce.mail.acme.com` as the return-path instead of the default `send.mail.acme.com`. Omit `return_path` and it defaults to `send`. The hostname is a **per-workspace** choice: two workspaces sharing a domain can each pick their own return-path (or share one), and one workspace's choice never affects another's.

## Why it covers SPF

Receivers evaluate SPF against the envelope-from domain, not the visible `From:` address — and your envelope-from is the return-path hostname. Because the verified CNAME resolves to Bird's bounce infrastructure, that infrastructure's SPF authorization applies, and it _aligns_ with your domain because the return-path is a subdomain of it. So SPF passes and aligns with one CNAME, and you don't publish (or maintain) an `include:` at your apex. The full reasoning is in [Where's SPF?](/docs/guides/email/dkim-spf-dmarc#wheres-spf).

## It gates sending — and can't be removed

The return-path CNAME is part of the send gate: `capabilities.sending` only verifies once DKIM, the return-path CNAME, and a DMARC policy are all in place. Until the return-path verifies, the domain can't send.

For the same reason, the return-path can't be removed — every send needs somewhere for bounces to go. You can _change_ the hostname, but you can't unset it: a `PATCH` that tries to null it out is rejected. Changes are staged safely — a hostname that's already verified is never swapped for an unverified one. Bird verifies the new return-path alongside your active one and promotes it only once the new CNAME checks out, so live sending never drops while you migrate the record.

## Next steps

- [Sending domains](/docs/guides/email/sending-domains) — registering a domain and the verification lifecycle
- [DKIM, SPF & DMARC](/docs/guides/email/dkim-spf-dmarc) — every record on the domain and what it proves
- [Tracking domain](/docs/guides/email/tracking-domain) — the optional branded hostname for open/click tracking
- [Per-provider DNS walkthroughs](/docs/knowledge-base/dns-and-domains/generic-registrar) — publishing the CNAME in your registrar