Separate sending domain launch checklist

What belongs on the separate domain

Use a separate sending identity when a stream can create reputation risk for the primary domain: outreach, newsletters, product updates, high-volume notifications, experiments, or any flow with changing recipient expectations. Keep password reset, security alerts, billing, and account-critical mail on a path whose reputation and failure handling are protected.

Do not launch by copying a DNS recipe from another project. First name the exact business stream, visible From: domain, provider, envelope domain, DKIM signing domain, DKIM selector, sending IP ownership, bounce path, complaint path, and rollback owner.

1. Publish the minimum public controls

1. SPF: publish exactly one SPF record for the envelope or Return-Path domain used by the provider. Count include and redirect chains before production traffic.
2. DKIM: enable provider signing for the visible sending domain or an aligned subdomain, then verify the real d= and s= values from a delivered message.
3. DMARC: start with a valid record and aggregate reporting. p=none is acceptable while collecting evidence, but it is not an enforcement endpoint.
4. PTR: verify every actual outbound IP has reverse DNS and forward-confirmed A or AAAA records. Domain-only DNS checks cannot prove this.
5. TLS and message format: send through a path that supports TLS and produces valid RFC 5322 headers, including a stable Message-ID.

The free scanner can check the visible From domain's public MX, SPF, DKIM selector, DMARC, MTA-STS, TLS-RPT, CAA, and optional sending-IP DNS. It does not require mailbox access, recipient addresses, DNS credentials, provider tokens, or a wallet connection.

2. Do not merge provider records by brand name

A domain can receive mail through one provider and send transactional mail through another. That does not mean every DNS record advertised by both brands belongs at the same owner name. Build the zone from the identities used by each real path.

Receiving provider

Its MX records select where inbound mail is accepted. Its SPF include is relevant only when that provider also sends outbound mail using an envelope identity covered by the record.

Shared transactional provider

Publish the ownership and DKIM records shown for the current account, plus one compatible DMARC record. Do not invent an SPF include merely because the provider sends the message.

Dedicated IP

Follow the dedicated-IP setup shown by the provider. This can add SPF, MX, PTR, or Return-Path requirements that do not apply to the shared sending path.

One SPF owner

Keep one SPF policy at each envelope-domain owner name, authorize only actual senders, and count every include or redirect chain before publishing.

If a mailbox provider also sends as the visible domain, its documented SPF include can belong in the single apex policy. That policy still does not prove Brevo alignment: for a shared Brevo path, verify an aligned DKIM pass and DMARC pass in the controlled receiver's Authentication-Results.

Mailbox plus transactional sender sequence

When one domain needs a real human inbox and a separate transactional sender, prove the two jobs in order. A mailbox can receive contact, privacy, abuse, or reply mail while a provider such as Brevo sends verification or notification mail for a different address on the same domain. Those are related records, not the same success state.

1. Create and test the real mailbox or alias target before publishing a DMARC rua=mailto: address that depends on it.
2. Add MX records for the receiving provider and verify one outside message arrives in that mailbox. An MX record alone does not prove a specific address exists.
3. Publish only the sending provider's current ownership and DKIM records for the actual account. Copy generated selector names exactly; do not reuse examples from another domain.
4. Keep exactly one SPF policy at each owner name. Include the mailbox provider only if it sends outbound mail for that envelope domain, and include Brevo only if the current account or dedicated-IP instructions require that SPF owner.
5. After all DNS changes, verify the web apex separately. Adding MX and TXT records should not disturb an ALIAS, CNAME, parking-record cleanup, or hosting verification record, but it is cheap to prove.

A clean acceptance packet has five separate lines: mailbox receive proof, transactional provider message ID or SMTP reply, receiver Authentication-Results with aligned DMARC, single-SPF lookup count, and unchanged web apex response. If one line fails, assign that owner rather than reopening every DNS and application setting.

3. Prove DMARC alignment with receiver evidence

Provider setup screens often say that SPF and DKIM are configured before the first real message proves alignment. Send a controlled message to test inboxes, download the original message source, and read the receiver's Authentication-Results. Record which passing identity aligns with the visible From domain.

SPF pass

Useful only for DMARC when the authenticated envelope identity aligns with the visible From domain.

DKIM pass

Useful only for DMARC when the signing d= domain aligns with the visible From domain.

DMARC pass

Requires at least one aligned SPF or DKIM pass. A provider-side "delivered" event does not prove inbox placement.

Forwarding path

May break SPF; preserve ARC and DKIM evidence separately instead of assuming the original direct-delivery result still applies.

Use the browser-local header analyzer for test headers that you are allowed to inspect. Do not paste real customer addresses, codes, links, credentials, tokens, or private message bodies into public systems.

4. Warm up from evidence, not a fixed magic number

Start with low volume to recipients who expect the mail and are likely to engage. Increase gradually only while SMTP responses, bounces, complaint feedback, authentication, and domain or IP reputation stay healthy. If deferrals or bounces rise, pause the ramp, reduce volume, and fix the first failed boundary before adding more recipients.

• Keep one schedule per domain and per IP or provider pool. Shared IP reputation and dedicated IP reputation behave differently.
• Do not mix message categories during warmup. A receipt, a security alert, and a promotional message should not train receivers as one stream.
• Keep cadence consistent. Sudden bursts and day-to-day swings are stronger warning signs than a slower launch.
• Track retries separately from new mail. Replaying a failed queue can create a hidden volume spike.
• Document the decision rule for pausing: for example, authentication failure, SMTP 4xx rate, hard bounce rate, complaint signal, block-list event, or reputation drop.

5. Separate acceptance from inbox placement

SMTP acceptance, provider delivered events, and a green DNS setup screen are not inbox placement. For each target receiver family, preserve at least one controlled test that distinguishes submission, provider processing, recipient-server acceptance, spam-folder placement, inbox placement, link safety scanning, and user-visible completion.

For Gmail-bound traffic, monitor Postmaster Tools once volume and verification are sufficient. For Yahoo-bound traffic, follow Sender Hub requirements, including authentication, complaints, forward and reverse DNS, list-unsubscribe for bulk senders, and timely unsubscribe handling. For Microsoft consumer mail, preserve exact SMTP or NDR responses and the sending IP that received the rejection.

6. Wire bounces and complaints before ramping

1. Use a stable envelope sender or provider message ID so every deferred, bounced, suppressed, or complained message maps back to one original send.
2. Classify synchronous SMTP failures separately from asynchronous DSNs and provider webhooks. A 250 response can still be followed by a later bounce.
3. Process hard bounces, inactive recipients, and complaints before the next ramp step. Warmup volume built on invalid recipients trains the wrong signal.
4. Keep unsubscribe headers and body links working for marketing or subscribed mail. Handle opt-outs quickly and do not require login just to unsubscribe.
5. Keep support, engineering, and provider owners able to read the same bounded evidence packet without exposing message secrets.

7. Move DMARC enforcement only after a full cycle

Keep aggregate reports enabled and reconcile every recurring source with the sender inventory. Move from p=none to quarantine or reject only after normal, low-frequency, failover, and incident paths have aligned receiver evidence and a tested rollback path.

Do not rely on the historic DMARC pct tag for staged rollout; RFC 9989 removed it because receiver behavior was inconsistent. If a partial rollout is needed, isolate streams by controlled subdomain or provider path and verify receiver behavior directly.

Preflight checklist

• Dedicated domain, Return-Path, DKIM identity, provider, and owner are named.
• SPF, DKIM, DMARC, PTR, TLS, unsubscribe, bounce, and complaint handling are verified before the first campaign or production notification batch.
• At least one real receiver header proves aligned DMARC for each message stream.
• Warmup pause criteria and rollback owners are written down.
• DNS checks, provider events, receiver acceptance, inbox placement, and user-visible completion are not treated as the same metric.