Set up Broadcast

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.
• A verified sending domain. See add a sending domain if you have not added one yet.
• Sending enabled on that domain.
• DKIM and DMARC records verified on that domain. See Domain requirements.
• An API key with Full access. See 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. Two things work whether or not your organization is enabled:

• Transactional sending and the rest of the API are unaffected.
• The public unsubscribe link 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 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.
• 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.

​

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.

​

Next steps