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

# Set up Broadcast

> Prerequisites for sending broadcasts. A sending domain for your broadcasts, the domain requirements, and API key permissions.

## Prerequisites

* A verified sending domain with sending enabled, ideally separate from the domain of your transactional email. See [Use one domain per kind of email](#use-one-domain-per-kind-of-email).
* An API key with **Full access**. See [API key permissions](#api-key-permissions).

## Use one domain per kind of email

We recommend sending your broadcasts from a different domain than your transactional email. Two subdomains of your main domain work well, such as `mail.example.com` for sign-in links, receipts, and password resets, and `news.example.com` for product updates and newsletters.

Mailbox providers track a reputation per domain, so two domains give each kind of sending its own reputation. The complaints and engagement of your broadcasts then stay apart from the reputation of the emails your users are waiting for.

One domain for both also works. Broadcast has no extra requirement for it, and both kinds of sending then share the domain's reputation.

Add and verify the second domain like the first one. See [Add a sending domain](https://nuntly.com/docs/guides/sending-domains.md). Each domain counts toward the domain limit of your plan. See [pricing](https://nuntly.com/pricing).

## Domain requirements

Broadcast has the same domain requirements as transactional sending: the domain must be verified, which means its DKIM, SPF and MX records are verified, and sending must be enabled on it. DMARC is optional, but Gmail and Yahoo expect a DMARC record from bulk senders, so add one before sending large broadcasts. See [Add a sending domain](https://nuntly.com/docs/guides/sending-domains.md) for the records and how verification works.

These requirements are checked at three points:

* When you create a broadcast or change its sender address, the domain of the `from` address must be one of your verified sending domains with sending enabled. Otherwise the request fails with a `422` response.
* When the broadcast is processed after you send it, the domain must still be verified with sending enabled, and its DKIM, SPF and MX records must be verified. Otherwise the broadcast moves to `failed` with a reason. See [Why a broadcast fails or pauses](https://nuntly.com/docs/guides/broadcast-sending.md#why-a-broadcast-fails-or-pauses).
* The same checks run again while the broadcast is sending. A domain that stops meeting the requirements halfway through a broadcast stops that broadcast.

If broadcast sending is stopped on a domain after a reputation problem, the broadcasts from that domain are paused with the reason `broadcast_reputation_stopped`.

## API key permissions

Broadcast requests need two permission resources, `contact` and `broadcast`. A key with the **Full access** permission has both, with read and write. A key with the **Sending only** permission has neither, so it cannot use Broadcast. See [API keys](https://nuntly.com/docs/guides/api-keys.md).

| Permission resource | Covers |
| - | - |
| `contact` | Contacts, contact properties, segments, topics, and their memberships. |
| `broadcast` | Templates, template versions, and broadcasts. |

## Next steps

> [card] [Create and send a broadcast](https://nuntly.com/docs/guides/broadcast-sending.md)
>
> Send your first broadcast now or later

> [card] [Contacts, segments, and topics](https://nuntly.com/docs/guides/broadcast-segments.md)
>
> Add your contacts and decide who receives a broadcast

> [card] [Templates](https://nuntly.com/docs/guides/broadcast-templates.md)
>
> Write and publish the content of your broadcast


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.