> ## 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. Access for your organization, a verified sending domain with DKIM and DMARC, API key permissions, and the sending identity Nuntly provisions for your domain.

Before you send your first broadcast, your organization needs access to Broadcast and your sending domain needs to meet the broadcast requirements. This page lists both.

## Prerequisites

* Broadcast enabled for your organization. See [Access](#access).
* A verified sending domain. See [add a sending domain](/docs/guides/sending-domains) if you have not added one yet.
* Sending enabled on that domain.
* DKIM and DMARC records verified on that domain. See [Domain requirements](#domain-requirements).
* An API key with **Full access**. See [API key permissions](#api-key-permissions).

## Access

Broadcast is enabled per organization. When your organization is not enabled, every Broadcast request returns a `403` response with the message `Broadcast is not enabled for this organization.` This applies to contacts, contact properties, segments, topics, templates, and broadcasts.

To ask about access for your organization, contact [support](mailto:support@nuntly.com).

Two things work whether or not your organization is enabled:

* Transactional sending and the rest of the API are unaffected.
* The public [unsubscribe link](/docs/guides/broadcast-unsubscribe) in a message that was already delivered keeps working. It does not depend on your organization's access.

## Domain requirements

Broadcast checks your domain more strictly than transactional sending does. On top of the domain being verified with sending enabled, Nuntly requires that both the DKIM and the DMARC records are verified. For transactional sending, DMARC is optional. See [Add a sending domain](/docs/guides/sending-domains) for the records and how verification works.

Nuntly checks these requirements 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, Nuntly checks that your organization is enabled, the domain is verified with sending enabled, and DKIM and DMARC are verified. If a check fails, the broadcast moves to `failed` with a reason. See [Why a broadcast fails or pauses](/docs/guides/broadcast-sending#why-a-broadcast-fails-or-pauses).
* Before each page of recipients is delivered, Nuntly checks again. A domain that stops meeting the requirements halfway through a broadcast stops that broadcast.

## Broadcast sending identity

The first time you send a broadcast from a domain, Nuntly creates a dedicated broadcast sending identity for that domain. It is separate from the identity used for your transactional emails, so a bounce or complaint problem on a broadcast cannot stop your transactional sending.

You do not need to add DNS records or take any action. The broadcast waits while the identity is created. If the identity is not ready in time, the broadcast moves to `failed` with the reason `broadcast_provisioning_timeout`. Because nothing was sent, you can return it to draft and send it again.

If Nuntly stops broadcast sending on a domain after a reputation problem, the broadcasts from that domain are paused with the reason `broadcast_reputation_stopped`. See [Why a broadcast fails or pauses](/docs/guides/broadcast-sending#why-a-broadcast-fails-or-pauses).

## 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](/docs/guides/api-keys).

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

## Next steps

<CardGroup cols={2}>
  <Card title="Contacts, segments, and topics" icon="users" href="/docs/guides/broadcast-segments">
    Add your contacts and decide who receives a broadcast
  </Card>

  <Card title="Templates" icon="file-text" href="/docs/guides/broadcast-templates">
    Write and publish the content of your broadcast
  </Card>
</CardGroup>


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