DNS records

Every sending domain gets five records. Publish all five. The values are generated for each domain, so copy them from the domain’s DNS Records tab rather than from this page. To find it, go to Channels > Email, open the Domains tab, and select the domain.

​

The record set

For a sending domain mail.example.com: <domain-id> is a unique ID Brudcast generates for your domain. All five records use a TTL of 300 seconds and no priority. The trailing dot on the values and the letter case don’t matter. Brudcast ignores both when it checks your records.

​

How the DNS Records tab is laid out

Each row shows Verified or Unconfigured, the type, the Host (name) and the Value (points to). Use the copy buttons rather than retyping.

​

Why SPF is a CNAME and not a TXT

This trips people up, because every SPF tutorial on the internet shows a TXT record. Brudcast delegates SPF instead of asking you to paste an include into a TXT record. You publish a CNAME at brd.spf.<your domain> pointing at a host Brudcast controls, and Brudcast maintains the SPF content behind it. When the sending infrastructure changes, nothing in your DNS has to change. The bounce address of your mail also sits under this name. The same record proves you control the domain, since only someone with access to the zone could have published it. It’s the record that decides whether the domain is verified.

​

Why there are two DKIM records

Two selectors, brd1 and brd2, let keys be rotated without a gap in signing. One stays live while the other is replaced. Because both are CNAMEs pointing at keys Brudcast hosts, rotation happens on the Brudcast side and your DNS never needs another edit. Publish both. A domain can verify without them, but receiving servers then can’t check the DKIM signature on your mail, and it fails DKIM.

​

What the DMARC record says

The generated policy is p=none: monitoring only. It asks receiving servers to report on messages that fail authentication, without asking them to reject anything. That’s deliberate for a new domain. Start in monitoring, confirm from the reports that your legitimate mail passes, then tighten the policy to p=quarantine and later p=reject yourself.

​

What the tracking record does

Open and click tracking use a hostname on your own domain, track.<your domain> by default. Tracked links then point at your domain rather than at a shared third-party one, which receiving servers treat more kindly. Mail delivers without this record. But when tracking is on, tracked links and the open pixel point at track.<your domain>, so publish the record before you turn tracking on. You can change the track part. See Tracking and unsubscribes.

​

No MX record

The record set has no MX record, because sending doesn’t need one. To receive mail on the domain, use Mailboxes, which has its own record set. See Add a mail domain.

​

If the domain also hosts mailboxes

When the same domain is also a mail domain, the page shows “This domain also hosts mailboxes” with a View mail domain button. A domain can publish only one SPF record and one DMARC record, so records that serve both products appear once, under Shared records, rather than on both pages.

​

Publish them at your provider

The records are the same everywhere. What changes between providers is how the name (or host) field works. Some providers want only the part in front of your zone and add the zone themselves. Others want the full name. Getting this wrong produces names like brd.spf.mail.example.com.example.com, which is the most common reason verification fails. For a sending domain mail.example.com in the zone example.com: If you send from the root domain itself, the host part is shorter: brd.spf, brd1._domainkey, and so on. After you save the first record, check the full name your provider displays. If it’s doubled, edit the record and remove the extra domain. Each provider puts its zone in a different place, names the value field differently, and has one trap of its own: Cloudflare’s proxy, GoDaddy’s appended domain, Route 53’s quoted TXT values.

​

Next