Bounce domain

Your bounce domain is the return-path hostname on a sending domain — 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; for what each record proves, see DKIM, SPF & DMARC.

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

The value is region-specific — us1.bounce.bird.com or eu1.bounce.bird.com — so copy it from the dashboard or the domain resource rather than constructing it. The host defaults to send. under your sending domain.

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:

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.

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?.

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.