Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Identify the account workflow first
Benchmark documentation includes different generations of domain-authentication instructions. Do not combine an older two-CNAME recipe with a newer screen offering NS delegation or multiple records. Start from the domain-verification workflow in the account you will actually use. Record the sending domain, intended subdomain, campaign owner and DNS administrator before publication.
The current domain-verification overview describes private-domain sending and a shared-domain fallback. It says the system determines whether the host uses a single NS record or multiple DNS records. This is the controlling branch decision for this guide; account-generated values take precedence over examples copied from another tenant.
Select an unused sending subdomain
References: RFC 1034 §4.2.
Check existing DNS and service ownership before accepting a suggested label such as news or mail. These names may already carry production mail or web traffic. Reserving a new name is safer than assuming a friendly label is free. Record how the selected From address, technical subdomain and reply mailbox relate; they serve different purposes.
In the NS workflow, Benchmark provides a record whose owner is the chosen subdomain and whose value is its assigned nameserver. Publish that subdomain delegation and return to Finish Setup. Do not replace the parent domain's registrar nameservers. Delegating one child name and transferring the whole domain's DNS are materially different changes. NS workflow
Before delegating, identify any records underneath that child. They may cease to be answered by the former authority once the new delegation is effective. A child that appears unused in a campaign dashboard can still contain infrastructure records owned by another team.
Handle the multiple-record branch carefully
References: RFC 7208 §3.2.
Benchmark's multiple-record guide describes a subdomain SPF TXT record and MX record, a DKIM CNAME, DMARC TXT and link-wrapping CNAME. Use the exact owner, value and priority from the current account. The prose SPF sample in that guide appears to contain a spelling inconsistency, so this article deliberately does not reproduce that include as a working value. If the account itself presents an unexpected hostname, have Benchmark confirm it before publishing.
Keep an existing SPF policy at an owner as one policy rather than adding a second candidate. Do not overwrite the organization's inbound MX just because the sending workflow includes an MX at a technical subdomain. If the DNS host cannot support the required subdomain records, resolve the supported configuration with Benchmark instead of substituting unrelated record types.
Verify both configuration and identity
References: RFC 9989 §5.3.5.
Original acceptance procedure: retain authoritative DNS answers for every supplied owner, complete the account verification step, then send a harmless campaign to a controlled external mailbox. Compare the visible From, envelope sender and DKIM d= and s= with the intended private-domain configuration. DMARC needs at least one passing aligned authentication method. A shared-domain fallback can deliver successfully while failing the business requirement to send with the approved customer identity.
Illustrative scenario: a campaign is delivered, but the recipient sees the platform's shared domain because private-domain verification never completed. Treat that as an identity exception, not evidence that the custom setup worked. Check the current account status and actual message rather than continuing a full campaign solely because one message arrived.
Roll back the narrow change
References: RFC 2308 §5.
Preserve the previous DNS and account selections. If verification fails, pause the campaign and investigate the selected branch. Restore only the affected records or delegation under an approved change plan; allow for cached answers. Benchmark warns that a previously verified domain with unresolved verification failure is removed after 30 days and affected sending uses its shared domain during that period. Investigate promptly rather than treating the grace period as acceptance. Recheck after a host migration or a change of sending subdomain. Documentation was reviewed on 8 November 2026; no tenant configuration, DNS update or delivered message was tested here.