# Turn incoming email into work your app can do.

Receive email through a forwarding address or a subdomain you control. Bird parses incoming messages so your application can read their content and attachments, then react through email.received webhooks. Build support intake, reply handling and document workflows on the Email API.

[Set up inbound email](/dashboard/signup?returnTo=%2Fdashboard%2Fw%2Femail%2Finbound)

[Read the receiving guide](/docs/guides/email/receiving-email)

Create your account, then add a receiving address and connect your application.

[Part of the Bird Email API](/products/email)

From email to an event

Receiving workflow

To: support@inbound.example.com

Here is the signed document.

Thanks for your help. I have attached the completed copy.

Webhook

Sender

Message body

Attachments

Illustrative message and event. Your webhook handler retrieves and processes the received email.

## How does receiving email work?

Choose where the mail should arrive, then decide how your application will process it. A forwarding address lets you try receiving without DNS changes. Receiving on your own subdomain lets customers email an address you control. Parsed messages are available in the dashboard and through the inbound-messages API.

## Start with the inbox you already use.

Create a forwarding address in Bird and add it as the forwarding target for your existing inbox or helpdesk. Bird receives the forwarded message and stores its parsed content. This gives you a practical first integration before changing domain routing.

## Receive on a subdomain you control.

Register and verify a dedicated receiving subdomain, enable receiving, and publish the provided MX records. Use a subdomain such as inbound.example.com so the receiving setup stays separate from your corporate mailbox routing. The receiving guide walks through the domain checks.

## Give your application the message it needs.

Read the sender, recipients, subject, body and attachments, and use webhooks to trigger your application workflow. Validate webhook signatures and handle retries through the documented event contract. If your agent needs an address with ongoing threads and replies, explore Agent Mailboxes.

## Questions before you start

### Do I need to change my domain to try inbound email?

No. Create a Bird forwarding address and forward mail from an existing inbox. Use domain receiving when you want mail addressed directly to a subdomain you control.

### Can I receive email on my own domain?

Yes. Register and verify a dedicated subdomain, enable receiving and publish its provided MX records. Keep corporate email routing separate by using a receiving subdomain.

### How does my application learn about a received message?

Subscribe to email.received webhooks or read messages through the inbound-messages API. Follow the webhook verification and retry guidance when processing events.

### How is inbound email different from Agent Mailboxes?

Inbound email parses messages arriving at forwarding addresses or receiving domains for your application to process. Agent Mailboxes provides an agent-owned inbox with message threads and a reply workflow.

## Build the rest of your email workflow

- [Sending API](/products/email/sending): Send transactional messages and batches with templates, idempotency and delivery events.
- [Email API](/products/email): Send transactional email and follow its delivery events.
- [SMTP relay](/products/email/smtp): Connect applications that already send through SMTP.
- [Agent Mailboxes](/products/email/mailboxes): Give an agent an inbox with threads and replies.
- [Email pricing](/products/email/pricing): Review published rates and discuss your sending requirements.

## Turn the next reply into a useful action.

Set up a receiving address, inspect an incoming message and connect it to your application.

[Discuss your integration](/demo?product=inbound)