Benchmark Email SPF, DKIM and DMARC setup, step by step

To authenticate Benchmark Email, use the records generated by the account that sends your campaigns. Benchmark Classic uses two account-specific CNAME records and a final Authenticated status. New Benchmark uses either an unused child-subdomain NS delegation or a five-record DNS configuration, followed by Ready to Send. These are different supported workflows, not steps to combine. Finish by checking a real campaign’s intended From address, aligned passing DKIM signature and trusted receiver DMARC result.

Benchmark’s platform comparison, confirms that Classic remains supported and maintained. You do not need to migrate to New Benchmark to authenticate Classic mail. This guide covers both native campaign platforms, not a separately managed SMTP service or an AWS account you operate yourself.

The instructions below are based on current public documentation and its screenshots, not tests in a customer account.

Identify the platform and prepare the change

Use the navigation in the actual sending account:

• Classic: account name → Account Settings → Domain Authentication.
• New Benchmark: account avatar → Email Settings → Domains.

You need authorized access to those settings, control of the authoritative DNS service, and approval for the campaign’s sender identity. The public procedures do not establish a universal named administrator role or paid-plan requirement. If the settings are unavailable, resolve access with your account owner rather than assuming a plan upgrade is necessary.

Record the account, any sending subaccount, intended From address, reply mailbox, DNS host and person responsible for rollback. Export existing records and save the current provider status. Identify every service already using the proposed DNS owners, including websites, mailboxes, forwarding, other campaign platforms and delegated subdomains. A label that looks unused in Benchmark may still serve another system.

Keep three checks separate: mailbox verification proves access to an address; domain authentication configures DNS and the sending platform; a received message proves what that particular route actually sent. None substitutes for the other two.

Classic: verify the sender and obtain the two CNAMEs

1. Verify the intended email address

In Classic, open account name → Account Settings → Email Verification → Add Email. Enter the intended address and select Send Verification Email. Open the verification message in the authorized mailbox and follow its verification link. If the account still shows a pending address, select Refresh. Verify any separate address you intend to select for replies as well. See Classic email-address verification.

Use your own private-domain address for this branded setup. Access to a public Gmail or Yahoo mailbox does not give you permission to publish authentication records for that provider’s domain.

2. Generate the current account’s records

Open Account Settings → Domain Authentication. Beside the intended domain, select Start, then Start Authentication. Benchmark says generation can take up to 30 minutes. When the DNS Records column changes from Start to View, open it.

Copy the complete output, including each record’s type, host and destination. The current Classic workflow supplies:

• One CNAME labeled SPF, at a dedicated technical owner.
• One CNAME labeled DKIM, at the issued selector’s _domainkey owner.
• A DMARC check or suggested policy, which must be reconciled with the domain’s existing policy before making changes.

These CNAME targets and selector labels are account-specific. Do not copy a number from a screenshot, reuse another account’s selector, replace your root SPF with a CNAME, or add a historical bmsend.com SPF include as a substitute for this workflow. Older instructions describe different records. The current Classic authentication procedure and your own View screen govern this setup.

3. Publish, check and finish activation

Apply the DNS-owner and CNAME checks below, then publish the two issued CNAMEs at the authoritative service. A green check for an already-present record is not an instruction to create another copy. Preserve existing DMARC protection and reporting destinations; a wizard suggestion is not approval to replace them.

Return to the domain’s View → Check Configuration. Correct the particular missing or mismatched owner rather than deleting unrelated records. Green checks or a success message can be followed by In Progress. Wait for the final Authenticated status before starting branded campaigns.

Classic’s status meanings are:

• Not Authenticated: the records have not been created.
• Action Required: the generated records are missing from DNS or do not match.
• In Progress: records have been added and confirmation is pending.
• Authenticated: the platform considers configuration complete. A received-message check is still required.

The documentation allows up to 48 hours for DNS propagation and confirmation. Waiting does not fix an incorrect owner, target or DNS authority. Recheck the actual answers before escalating a persistent delay.

4. Select the address in the actual campaign

Open Emails → Emails, select the campaign, and edit its From section. Choose the verified address from From Email Address. Classic also documents an account default under Account Settings → Email Message Settings → From Email. Inspect the particular campaign rather than assuming an account default updated every existing draft. A different Reply-To address does not authenticate the From domain.

Authenticate separately in the subaccount that sends: Classic master accounts and subaccounts do not share domain authentication. Removal of an authenticated Classic domain is a Support process, not an undocumented delete button. These boundaries are documented in the Classic setup guide.

New Benchmark: approve the child sender before choosing a DNS branch

Open avatar → Email Settings → Domains → + Add Domain. Enter the domain, such as example.com, select Continue, and choose a new, unique subdomain. Benchmark detects the domain host and presents the supported NS or multiple-record configuration. Follow the branch actually issued to your account, not both.

Inspect the sender preview carefully. Current setup screenshots show a sending address at the chosen child domain, such as sender@news.example.com, not a promise to retain sender@example.com. Approve that child From identity before proceeding and verify it again in the received message. The overview uses a simplified parent-domain example; the actual preview and message determine your configuration. See New Benchmark domain verification and the setup procedure.

Use a genuinely unused child, not merely an attractive name such as mail or news. Check the child and all descendants for existing records, delegations, mail routes and services. If the child is already in use, stop and choose an approved unused one or arrange a deliberate migration. Do not delete working DNS to make the name available.

Branch A: delegate the unused child with the issued NS record

The NS procedure supplies the child owner and a Benchmark-assigned nameserver target. Publish the exact issued NS record in the authoritative parent zone. Benchmark suggests a TTL of 30 minutes or one hour.

For example, if the approved child is news.example.com and you are editing the example.com zone, the relative owner is news. The target is the complete nameserver hostname from your account, not a sample token from this article or a screenshot.

This delegates authority for the entire child subtree to Benchmark, where it manages SPF, DKIM and DMARC. It does not require changing the registrar’s nameservers for example.com. Nevertheless, it can change answers for everything beneath news.example.com. Check existing NS and DS records and DNSSEC arrangements before proceeding. Do not remove a delegation or DS record blindly. A parent policy previously inherited by the child can also be superseded by a child policy published by the new authority; reconcile the intended protection with the domain owner before delegating.

Once the exact approved delegation is published, return to Benchmark and select Finish Setup. The domain should move from Verification Pending to Ready to Send. Verify both the parent delegation and the provider’s authoritative child answers, not just that your DNS editor saved an NS row.

Branch B: publish the five issued records

The multiple-record procedure shows four groups containing five records:

1. SPF TXT: the complete policy at the issued technical subdomain owner.
2. MX: the issued mail-routing owner, numeric priority and complete destination hostname.
3. DKIM CNAME: the account’s complete selector owner and destination.
4. DMARC TXT: the child policy owner and the approved policy.
5. Link Wrapping CNAME: the issued tracking owner and target.

Save the full packet before editing DNS. Use each record’s actual owner rather than assuming all five belong at the same name. Keep the MX’s numeric priority separate from its hostname when the DNS editor has separate fields. Copy the entire priority, not an assumed number of digits, and the complete regional target, not a visually truncated screenshot.

The MX is a routing change, not just a verification token. Compare its owner, complete destination and priority with the authorized plan. It belongs at the issued technical child, not automatically at the domain root or the visible From domain. Do not replace employee-mail MX records or mix the new route into an existing child mailbox service. If the owner is not unused as expected, stop for reconciliation.

The public SPF prose and screenshot disagree on the include hostname and final qualifier. Neither is a safe universal template. Copy the current account’s complete policy, preserve approved existing authorizations, and have Benchmark resolve any malformed or conflicting account output before publication. Do not silently choose a qualifier or AWS region from an example.

The DMARC example also requests strict DKIM alignment. That matters for the final test: if the effective policy has adkim=s, the passing signing domain must exactly match the chosen visible From domain. Do not overwrite an existing or inherited policy simply to satisfy the wizard. Resolve a conflict with the DNS owner and Benchmark before completing setup.

Publish each record through the authoritative DNS service, using the owner checks below. Link wrapping is not itself proof of DKIM, but it is part of this five-record verification packet; do not omit it or repoint another platform’s active tracking hostname. Step through the record groups, select Continue, then Close & Verify. The text documentation also calls this Close and Verify. Confirm Verification Pending becomes Ready to Send.

Benchmark documents 24–48 hours for configuration. If the DNS host cannot publish the required child MX, this private-sending branch is blocked. The guide specifically lists Wix as a known limitation. Arrange a supported alternative with Benchmark and the DNS owner; do not replace MX with an A record, move it to the apex or add an unissued NS delegation.

Map DNS owners and preserve existing authority

Write down the fully qualified owner for every issued record before translating it into your DNS editor’s Host field. A DNS editor may append the zone name automatically.

For illustration only, an issued DKIM owner of issued-selector._domainkey.news.example.com becomes:

• issued-selector._domainkey.news inside the example.com zone.
• issued-selector._domainkey inside a separately authoritative news.example.com zone.
• The full hostname only if that DNS editor expects a fully qualified name.

issued-selector is a placeholder, not a Benchmark selector. Preserve the account’s complete label and underscores. Do not append the domain twice. Some public Classic illustrations contain inconsistent selector formatting; if your actual account output is malformed, ask Benchmark to correct it rather than inventing a replacement owner.

An existing _domainkey or child NS delegation changes where records must be managed. Find the service actually authoritative for the owner. Do not publish ineffective copies in the parent or delete the delegation to gain control. In New Benchmark’s NS branch, provider-managed child records belong under the delegated authority, not as a parallel five-record setup in the parent.

A CNAME owner cannot also hold an SPF TXT, A, AAAA, MX or a different CNAME. Resolve conflicts before publishing. Do not regenerate a working selector or remove another sender’s records merely because a tutorial uses the same friendly label. See DNS CNAME constraints.

Keep the required CNAME answers visible

Publish authentication and link-wrapping aliases as DNS-only, not HTTP-proxied records, unless Benchmark documents a different supported configuration for your account. Where verification requires a literal CNAME answer, flattening that returns only addresses can hide it.

For Cloudflare, inspect both the applicable Flatten control for the individual record and CNAME flattening for all CNAME records at zone level. Turn the affected record’s Flatten control off when available, and ensure applicable zone settings do not suppress the issued aliases. A whole-zone change can affect unrelated services, so coordinate it rather than disabling flattening globally without review. Cloudflare also flattens apex CNAMEs by default and same-zone targets regardless of that setting. If mandatory behavior prevents the required CNAME answer, stop and arrange a supported configuration; do not invent an override or remove a shared delegation. See Cloudflare’s flattening documentation.

SPF: check the envelope identity, not just the visible From

SPF evaluates the actual SMTP MAIL FROM domain, or HELO in the relevant empty-envelope case. It does not automatically evaluate the address the recipient sees in From. Classic’s SPF CNAME and New Benchmark’s child TXT/MX configuration therefore must be checked against the actual message’s envelope identity. There is no universal Return-Path to invent for every Benchmark account.

Keep one v=spf1 TXT policy at each evaluated owner. Other unrelated TXT records can coexist there, but two SPF policies cause an SPF error. A Classic CNAME is an alias to provider-managed data, not an invitation to add an SPF TXT alongside it. A new child’s SPF also does not replace a parent’s staff-mail policy.

When an owner already has SPF, inventory all legitimate senders before any merge. Preserve needed mechanisms and the approved qualifier. If it uses redirect=, adding an all mechanism makes that redirect ineffective, so do not append a provider template mechanically. Existing a and mx mechanisms authorize the addresses they resolve to; they are not harmless boilerplate. Adding or changing A/MX records can alter those authorizations.

SPF permits at most ten evaluated DNS-dependent terms, including nested lookups through include and redirect; it is not simply ten top-level includes. ip4, ip6 and all do not consume that term budget. Qualifiers describe authentication outcomes, not guaranteed receiver delivery decisions. See RFC 7208 lookup limits.

If you also operate a separate transactional AWS account, use the EmailAuth Amazon SES guide for that distinct route. An SES-shaped target in Benchmark’s packet does not mean you should create or alter an AWS identity instead of finishing Benchmark’s account verification.

Preserve DMARC, including inherited protection

DMARC passes when SPF or DKIM passes and aligns with the visible From domain under the applicable policy. Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match. A passing SPF result on a technical child does not by itself prove strict SPF alignment. See DMARC alignment.

Check the direct _dmarc owner for the actual visible From domain and any applicable inherited policy before adding a record. Preserve existing enforcement, alignment tags and authorized reporting destinations. Do not duplicate DMARC or replace a working policy with Classic’s monitoring example or New Benchmark’s stricter sample just to copy a screen. A new direct child record can override inherited protection even when the parent record remains untouched.

Only if no direct or applicable inherited policy exists, the owner approves it and a monitoring plan is appropriate, a first monitoring record can be:

Type: TXT
Full owner: _dmarc.example.com
Relative owner in the example.com zone: _dmarc
Value: v=DMARC1; p=none;

For a child From domain news.example.com, the full owner is _dmarc.news.example.com: enter _dmarc.news in the parent zone, or _dmarc in an authoritative news.example.com zone. This is a conditional baseline, not a substitute for New Benchmark’s required account packet. If the platform requires a different policy, agree the compatible policy before activation. With the NS branch, coordinate provider-managed policy changes rather than publishing a competing parent-zone copy.

The example has no report recipient. If the owner wants aggregate reports, add only an approved rua destination with a handling and retention plan. A report destination in a different Organizational Domain from the policy domain requires the report-generating receiver to check external-report DNS authorization; a destination within the same Organizational Domain is excepted. This is not a rule that every different hostname needs authorization. See RFC 9990 section 4. DNS authorization and the owner’s permission to share report data are separate requirements.

Verify DNS, platform status and a real campaign

DNS acceptance

Compare the current account packet with answers from both the responsible authoritative nameservers and a recursive resolver. The commands below are read-only patterns with placeholders, not observed results:

dig @"<authoritative-nameserver>" "<issued-cname-owner>" CNAME +noall +answer
dig @"<recursive-resolver>" "<issued-cname-owner>" CNAME +noall +answer
dig @"<authoritative-nameserver>" "<issued-spf-owner>" TXT +noall +answer
dig @"<authoritative-nameserver>" "<issued-mx-owner>" MX +noall +answer
dig @"<recursive-resolver>" "<issued-mx-owner>" MX +noall +answer
dig @"<parent-authoritative-nameserver>" "<approved-child-domain>" NS +norecurse +noall +answer +authority
dig @"<child-authoritative-nameserver>" "<actual-dkim-selector>._domainkey.<actual-signing-domain>" TXT +noall +answer

Run only the queries relevant to your branch, then check every issued owner, not just one successful example. For CNAMEs, verify the literal target and follow the chain to the required data. For a five-record MX, compare the complete owner, numeric priority and destination set at authoritative and recursive DNS with the issued and approved routing plan. A target without its priority is incomplete evidence. For NS, verify the intended parent delegation and the child’s SPF, DKIM and effective DMARC through its actual authority. Record differences caused by caches and recheck after the applicable TTL; a saved editor row alone is not acceptance.

Received-message acceptance

When status is Authenticated in Classic or Ready to Send in New Benchmark, send a harmless native campaign through the intended account and subaccount to a controlled, valid external mailbox. Use the same From selection and campaign path intended for production, not an unrelated staff-mail message. Check each materially different sending route. Do not send to a commercial list simply to test authentication.

Inspect the original message source and results produced inside the receiving service’s known processing boundary. Confirm that service’s documented handling of externally supplied Authentication-Results fields, such as removing, renaming or disregarding untrusted fields at ingress, and identify which results it generated itself. A familiar authserv-id, matching text or position near the top of a message does not prove trust. Ignore attacker-supplied result fields; if provenance is unclear, ask the receiving administrator for the trusted trace. See RFC 8601 security considerations.

Accept the branded configuration only when all of these are true:

1. The visible From is the approved identity: the selected Classic domain or the intended New Benchmark child, not a rewritten shared-domain sender.
2. The intended Benchmark DKIM signature has dkim=pass; its actual d= signing domain aligns with that From under the effective adkim setting. Check its s= selector against the configured owner. If adkim=s, require an exact domain match.
3. The trusted receiver reports dmarc=pass for that intended visible From. A DMARC pass through SPF alone does not prove that the intended DKIM setup works, nor does an unrelated provider signature.
4. The actual envelope identity and SPF result have been inspected independently. Investigate fail, temperror and permerror even if aligned DKIM produces a DMARC pass. A forwarding path can affect SPF differently from a direct delivery; do not broaden SPF or add a forwarder merely to make a test green.

Save the account status, DNS answers, received identities and trusted results. Authentication does not guarantee inbox placement, engagement or acceptance by every recipient system.

Troubleshooting, fallback and rollback

Classic is still In Progress. Reopen View and compare both CNAME owners and targets, including suffixes, proxy and flattening behavior. Green checks are not the final Authenticated state. If Action Required persists after correct authoritative and recursive answers, provide Benchmark with the specific failed owner and current account status rather than deleting all authentication records.

New Benchmark shows Verification Pending or Verification Delayed. Open View Record Details, compare the current packet and use Retry Verification after correcting the actual fault. For the multiple-record branch, check all five records, including MX priority and link wrapping. Do not follow an NS-only troubleshooting paragraph by converting the five records into NS records. If correct records remain unresolved beyond the documented 48 hours, contact Support with the branch, owners and answers.

Mail arrives from a Benchmark-owned domain. Classic may rewrite unauthenticated mail through clients.bmsend.com; New Benchmark uses a shared domain under benchmarksend.com while private verification is incomplete or failed. Delivery through those identities is not proof of branded authentication. Pause a brand-dependent campaign and resolve the private-domain status. New Benchmark says future messages switch to the private domain after successful verification, so inspect the next campaign’s sender and repeat the received-message check.

A previously verified New Benchmark domain fails. Investigate promptly. Benchmark documents automatic account removal after 30 days of unresolved verification failure, requiring setup again. During that period mail can use the shared domain. The period is not permission to treat fallback as the approved sender.

Rollback is necessary. Pause affected campaigns first. Restore only the changed owners or account settings under an approved plan, accounting for caches and other senders. Do not remove active Classic aliases or New Benchmark link-wrapping records still needed by other traffic. Classic domain removal requires Support. For an NS rollback, inventory everything now served beneath the child and restore approved authority and routing coherently before removing delegation; simply deleting the NS record can strand dependencies. Keep parent mail MX, unrelated selectors, report destinations and DNSSEC out of a narrow rollback unless an explicitly approved migration requires them.

Sources and maintenance

Their own update dates differ:

• Classic versus New Benchmark: November 4, 2026.
• Classic domain authentication: November 11, 2024; email-address verification: November 23, 2022.
• New Benchmark domain-verification overview: April 8, 2026.
• New Benchmark NS setup: May 12, 2026.
• New Benchmark multiple-record setup: May 7, 2026.

Recheck account-generated values after a DNS-host move, sender-domain change, subaccount change, platform change or unexpected fallback. Keep the distinction between a documented procedure, a verified DNS configuration and an accepted real message: this guide does not claim a customer deployment was performed.