Authenticate Supportbench email: SPF, bounce domains, DKIM and delivery checks

Updated Wednesday, October 28, 2026 · Marcel Gravelle

A customer must be able to recognize and receive your support replies. Email authentication helps the receiving mail service assess whether messages using your domain are authorized. For a B2B support team, this is part of protecting the customer conversation: a correctly recorded case reply is of little help if it is rejected or hidden in the customer’s junk folder. Setup involves your Supportbench reply identity, your organization’s DNS and the actual mail-sending configuration. Verify all three with a real controlled message.

At a glance

For: support operations administrators and the IT or DNS administrator responsible for the sending domain. Applies to: Supportbench Core.

Start here: Settings → Email configuration → Address / signature; DNS changes are made with your domain administrator

Understand the terms without becoming a mail specialist · Collect the exact information before editing DNS · Give the DNS administrator a precise change request · Configure custom DKIM for the intended reply address · Test the customer conversation after configuration · Separate authentication, delivery and inbound failures · Example: keep a high-priority account update reachable

Understand the terms without becoming a mail specialist

Term	Plain-language meaning	Operational use
Reply address / From identity	The address and display name selected for the outbound customer message.	Confirm the customer recognizes it and can reply into the intended support channel.
DNS	Your domain’s published configuration, managed at its DNS provider.	An authorized DNS administrator publishes the supplied mail records. Editing a Supportbench signature does not change DNS.
SPF	A DNS policy used to evaluate permitted sending systems for the applicable mail domain.	Obtain the current required sender authorization; preserve other legitimate senders.
DKIM	A cryptographic signature attached by the sending service, verified through a published key.	Confirm the actual message was signed with the intended domain, not merely that a switch is on.
Bounce domain / Return-Path	The envelope return address/domain associated with delivery failures.	Configure the supported environment-specific return path when instructed; it is separate from the customer-facing reply route.
DMARC alignment	The relationship between the visible From domain and a successful SPF or DKIM authentication domain.	Have IT inspect the actual headers and policy; a successful check for an unrelated domain is not enough.

Authentication helps delivery, but it is not a guarantee of inbox placement or proof that the customer read the message. Recipient filtering, content, reputation and other delivery conditions still matter. Google explains authentication and alignment in its email sender guidance; use the recipient provider’s requirements when diagnosing its result.

Collect the exact information before editing DNS

List the reply addresses your agents actually use, including distinct brands or sending domains. Confirm the domain for each address; configuring one domain does not establish that another is ready.
Identify the person who can change DNS and the person responsible for the sending service. Supportbench configuration access alone does not grant access to your domain’s DNS.
Ask Supportbench Support for the current approved SPF mechanism and bounce/Return-Path record for your environment, and whether custom DKIM is appropriate. Request the exact record type, host/name, value/target and any activation or verification step.
If custom DKIM is required, obtain its actual TXT value from Supportbench Support. The Core page may display Provided by Supportbench Support; that is an instruction to obtain the value, not DNS content to publish.
Have IT record the existing relevant DNS values and other legitimate mail services before changing anything. Agree a controlled test and a recovery plan for an incorrect entry.
Choose an approved external test recipient and a harmless case. Keep the message ID, send time and actual sender identity for the verification record.

Use current supplied records, not copied historical targets

There is no universal SPF include or bounce CNAME target established by this Core settings page. Earlier articles contained specific values and conflicting DKIM examples. Do not reuse those examples without confirmation for your current environment. Obtain the exact supported records instead of guessing a hostname from another customer’s setup.

Give the DNS administrator a precise change request

Use this checklist when requesting SPF and bounce-domain work. It keeps a support operations person involved in the result without asking them to invent DNS syntax.

Information to provide	What the DNS administrator should confirm
Sending addresses and domains	The records apply to the identities Supportbench will actually send.
Current Supportbench-approved SPF instruction	Whether the existing SPF policy needs modification and how to preserve all authorized senders.
Current approved bounce host, type and target	The exact owner name and destination are correct for this environment.
DNS-provider naming convention	Whether its host field expects a relative name or the full domain, so the domain is not accidentally appended twice.
Verification owner and test window	Who confirms public DNS and who sends the controlled Supportbench message afterward.

An SPF policy belongs in one applicable TXT record at a given DNS owner name. If one already exists, have the administrator update that policy rather than adding another SPF record beside it. Multiple SPF records can produce an error; simply collecting more includes is not a complete validation. The normative details are in RFC 7208.

After saving DNS, have IT verify the published result and account for the record’s cache/TTL behavior. Do not promise a fixed waiting period as proof that a wrong record will become correct. Record what was published and when, and complete the sending-service verification required by Supportbench.

Configure custom DKIM for the intended reply address

Open Settings → Email configuration → Address / signature with permission to edit reply addresses. Select the intended existing address and confirm its email domain.
Open Custom DKIM DNS setup. Review TXT host and TXT value. Core constructs the host using the sbmail selector and the sender domain; for a demonstration domain it would resemble sbmail._domainkey.example.com. Use your actual address’s value.
Use the copy control for the exact host. If the TXT value says Provided by Supportbench Support, obtain the real key value through Supportbench Support. Do not publish the placeholder, generate an unrelated signing key or replace this procedure with an old two-CNAME example.
Give the exact host and supplied value to the DNS administrator. Have them publish the requested TXT record using the provider’s naming convention and verify that the correct public value is visible.
Have Supportbench Support verify the setup and required sending-side readiness. Only then use Enable custom DKIM as appropriate and save the reply-address configuration.
Reopen the address to confirm the saved switch state. Then send and inspect an actual message from that reply identity using the procedure below. The switch state is not a DNS or delivery test.
Repeat the necessary verification for each distinct sending domain and intended address. Keep the address/domain and validation evidence together for future changes.

The Core page recommends bounce domains for most setups. Choose the appropriate approach with Supportbench rather than enabling custom DKIM solely because the toggle exists. This page does not offer a one-click customer-side verification that proves all DNS and signing requirements have passed.

Test the customer conversation after configuration

Open the approved test case and prepare a short harmless outbound email. Select the intended Reply Address, review recipients and send through the normal case action.
Confirm the activity’s send outcome and whether the external test mailbox receives the message. Check junk/quarantine when it does not appear in the inbox; a saved activity alone is not a delivery receipt.
Have the recipient or mail administrator inspect the original message headers. Record the message ID, visible From, Return-Path, DKIM signing domain and authentication results, including DMARC alignment.
Compare the tested identity with the configured domain. If a different reply address or domain was used, correct the test before diagnosing the DNS.
Reply from the external mailbox and confirm the response joins the intended Supportbench conversation. Outbound authentication and inbound routing are separate checks, both necessary for a usable support channel.
Repeat for additional important sending domains and representative recipient systems. Record the observed result rather than promising universal inbox placement from one successful test.

Separate authentication, delivery and inbound failures

Symptom	Where to investigate
TXT value shows Provided by Supportbench Support	Obtain the actual DKIM value; the placeholder is not a key and should never be copied into DNS as one.
Custom DKIM is enabled but a message fails DKIM	Check the actual signing domain/selector, published key, sending-side setup and whether the tested reply address matches.
SPF fails or reports an error	Have IT examine the applicable SPF domain/policy, authorized sender, duplicate records and policy evaluation.
SPF or DKIM passes but DMARC fails	Check alignment with the visible From domain, not only the presence of a pass result somewhere in the headers.
Authentication passes but mail lands in junk	Inspect the recipient’s filtering/quarantine and delivery evidence. Avoid random DNS changes when authentication already passes.
Supportbench shows a failure or no confirmed send	Inspect the activity/send result first. DNS changes do not repair every message-processing failure.
Customer reply never reaches the case	Check mailbox forwarding and the Supportbench inbound route. The bounce domain is not your case-intake destination.
Delivery changed after adding a brand or changing an address	Verify the new domain and actual selected Reply Address; the old domain’s successful test is not evidence for the new one.

For an escalation, provide the case ID, send time with time zone, sender domain, recipient domain, sanitized message ID and relevant authentication/error results. Share full headers only through the approved support channel when required; they can contain customer information. Never provide mailbox passwords or private signing keys in a public article or screenshot.

Example: keep a high-priority account update reachable

Test the same identity agents will use

A support team introduces a separate reply address for equipment-service customers. Before using it for a high-priority incident, operations lists its domain, obtains the required records, has DNS and signing verified, and sends a controlled case message using that exact Reply Address. The team confirms receipt and a reply into the same case. This reveals a missing sender-domain setup before a customer is waiting for an urgent update.

Keep this acceptance record with the mailbox/brand operating instructions. Recheck it when the reply domain, DNS provider, mail service or sending configuration changes. A recognizable display name and polished signature are useful, but they do not substitute for verified delivery.

Was this article helpful?