Verify every address you send from, not just the first one

A channel in Broadcast can send from several addresses. Transactional receipts from hello@, the newsletter from news@news., maybe a founder address for the occasional personal note. That has worked for a while, and it is the right shape: one subscriber list, several From addresses, each picked per broadcast.

What did not work was the checking. The ESP setup wizard verified the channel’s primary sender address with your provider and stopped there. Every other identity you had added was simply assumed to be fine. Which is a bad assumption, because providers do not authorize addresses in bulk. Postmark, Amazon SES, Mailgun: each one authorizes a domain, or it authorizes an individual address, and a second identity on a second subdomain is a separate question every time.

So you could finish the wizard, see a page full of green, and have a newsletter that bounced at the provider on its first send. This came to us from a customer who hit exactly that.

In 2.27 the wizard checks all of them.

Each identity gets its own row and its own verdict, and the verdict says how the address earned it: authorized via a verified domain, which covers every address on that domain, or authorized via its own sender signature, which covers only that one. Where an address is not authorized, the row offers the action that would fix it, adding the domain to your provider, or sending a confirmation email to that specific address.

The freemail case gets its own explanation rather than a bare failure. If an identity sits on gmail.com, no amount of DNS will verify it, because you do not control the domain. The row says so and points you at individual address verification instead of leaving you to work out why the domain button is missing.

The same per-identity detail flows back into the Sender Settings page, where each identity now carries a badge per email server.

The warning banner at the top of that page used to tell you that something on the channel was unverified and drop you at the top of a list to find it yourself. It now names the address and links straight to its row.

Two more things in this release came out of the same customer report.

Promoting an identity to default silently rewires which address every un-pinned broadcast, sequence, and transactional email sends from. The buttons sit in a list, one row apart, and our customer nearly promoted the wrong one. Making an identity the default now asks first, and the question names the exact address and states what changes.

And Domain DNS Health stopped arguing with your email provider. Two long-standing false alarms are gone. A subdomain like news.northwind.com almost never has its own DMARC record, because DMARC is designed to inherit from the organizational domain; Broadcast was reporting that as Missing. It now follows the RFC 7489 fallback, finds the parent record, and shows you the policy your subdomain actually inherits. Likewise, when your provider has confirmed SPF and DKIM for a domain but Broadcast’s own probe cannot see them, because SPF authenticates the bounce domain and DKIM selectors are randomized and unguessable, the card now says so instead of showing red next to a domain your provider considers healthy.

A few shapes this takes in practice. You add a news. subdomain for your newsletter and run the wizard: the verify step tells you hello@northwind.com is already covered by the verified parent domain and news@news.northwind.com is not, with the add-domain button right there, so you fix the one thing that is actually broken. You add a founder’s Gmail address as an identity and the wizard immediately routes you to address verification rather than letting you wonder why it never goes green. And months later, when a DNS change breaks DKIM on one subdomain, the Sender Identities page shows a yellow badge against the addresses on that subdomain only, not a blanket warning about the channel.

One more fix in 2.27 worth naming plainly, because it is a security one. Broadcast’s SMTP.com webhook was not authenticating its callbacks, which meant anyone who guessed the URL could forge bounce, complaint, and unsubscribe events and rewrite your subscriber state. It now carries a per-channel secret in the callback URL and fails closed, and upgrading re-registers your callbacks automatically. Fixing it turned up a second problem: the callback registration itself had never worked against the real SMTP.com API, so if you are on SMTP.com, this is the release where your delivery tracking starts recording events. If you run SMTP.com, upgrade to 2.27.

Read the Sender identities guide to set up multiple From addresses, or see how DNS health monitoring watches your SPF, DKIM and DMARC records.