On this page: Scope the server, From domain and signing method · Choose CNAME-managed DKIM or a TXT key · Configure the custom bounce domain and enable it · Avoid record collisions and preserve existing mail · Publish DMARC safely · Verify each layer with concrete evidence · Troubleshooting and FAQs · Related guidance and review scope
SocketLabs' custom bounce-domain route uses a CNAME and account activation, not an extra SPF record on your root domain. Configure branded DKIM separately, then verify which identities the actual sending server uses. Default provider-domain authentication does not establish DMARC alignment for your brand. SocketLabs bounce-domain instructions
Scope the server, From domain and signing method
This guide covers SocketLabs' hosted On-Demand sending service. It does not configure an independently operated mail server, change corporate mailbox hosting, or assume every subaccount has the same settings. Identify the application, credentials' server or subaccount identity, From domain and DNS administrator before making changes. Record identifiers, not passwords or API secrets.
SocketLabs signs hosted messages with email-od.com by default and offers additional custom signatures. A signature can therefore pass cryptographic verification while identifying SocketLabs rather than the visible sender's domain. Do not remove a default provider signature just because a second signature is needed for alignment. Default DKIM behavior
Before deployment, confirm your account exposes the chosen signing and bounce features and that you have permission to configure the relevant server. The cited public documentation describes the workflows but does not establish a universal entitlement across every commercial agreement or interface generation. If your screen differs, ask support which workflow applies instead of translating an old screenshot into a guessed setting.
Verify sending permission separately for the actual server. SocketLabs requires ownership or authorization for the From domain. Its Sending Domains procedure supports confirming an address at that domain through an authentication code, or adding an eligible DNS authentication feature: Custom Bounce Domain, DKIM Signature or Engagement Tracking. Check the current plan and account configuration, because they affect how Sending Domains applies. Once domains are listed on Domain Management, only the listed domains can send through that server. Inventory and verify every required brand and subdomain before restricting an existing multi-domain server; obtain each domain owner’s permission. Sending Domains and ownership verification.
Create a mapping worksheet: application, server/subaccount, exact From domain, intended DKIM domain/selector, intended envelope domain and test mailbox. Include subdomains explicitly. example.com and alerts.example.com may need separate configuration even though relaxed DMARC alignment can relate them.
Record the sending-domain permission check independently from DKIM activation, bounce mapping and receiver alignment. A domain allowed to submit mail is not necessarily using branded DKIM or the intended envelope. If submission returns 554 5.1.0 The Sender's Address Was Not Allowed, inspect the correct server’s Sending Domains entry and ownership-verification state before changing signing keys. Resolve permission with the account/domain owner; do not authorize a third-party domain you cannot use. Sender-not-allowed diagnostic.
Choose CNAME-managed DKIM or a TXT key
SocketLabs documents a managed CNAME method and TXT-based methods. Select the method supported by the account and your key-management requirements; do not publish both types at the same selector.
For the documented Use a CNAME record method, the official example is:
Owner: dkim._domainkey.example.com
Type: CNAME
Target: dkim._domainkey.email-od.com
Replace example.com with the configured signing domain and compare the example with the account's actual instructions before use. SocketLabs manages the keys behind this delegation. The control panel must verify the CNAME before activation. Its documentation associates signing with the configured domain's responsible sender identity, usually From or Sender, so test applications that insert a distinct Sender header. CNAME signing instructions
With Generate your own TXT record, SocketLabs generates the key pair and supplies the public record for DNS. Save the public value when issued: the documentation says it is no longer displayed in the portal after successful publication and saving. With Bring your own TXT record, the authorized key owner supplies the signing domain, selector and private key to the account's supported configuration. Publish only the corresponding public key. The panel verifies the public record before allowing the settings to be saved. TXT signing options
For these TXT signing methods, SocketLabs states that the signing domain must exactly match the message’s From domain for the custom signature to be applied. This differs from the CNAME documentation’s responsible-address wording, which can involve From or Sender.
The current DKIM overview also describes an exact From match, while the CNAME-specific page uses the responsible-address wording above. For an application with a separate Sender header or unusual identity, obtain SocketLabs clarification and test that exact message form rather than treating either wording as a universal rule. Current DKIM overview.
Do not paste a private key into a DNS TXT value, support screenshot or shared change ticket. For either TXT method, copy the full generated public value and actual selector rather than assuming dkim, slkey or default. A selector is part of the lookup name, not part of the public-key string. DKIM specification
For key rotation, retain the old public record while messages signed with it can still be delivered and validated. Coordinate activation and retirement with the service administrator. Deleting a selector immediately after switching signing can break queued or delayed mail even if new messages pass.
Configure the custom bounce domain and enable it
Choose an unused hostname beneath the appropriate organizational domain. SocketLabs' published target is tracking.socketlabs.com; for example:
Owner: bounces.example.com
Type: CNAME
Target: tracking.socketlabs.com
This example owner is a choice, not a mandatory name. Do not create multiple competing CNAMEs at it. After publication, use the relevant authentication settings to enable the custom bounce feature. The documented legacy control-panel path is Configuration > Advanced Authentication. DNS alone is not activation. Tracking can share the supported hostname or use a separate one, but branding a link is not proof of envelope alignment. Bounce and tracking configuration
SPF evaluates the SMTP MAIL FROM domain, normally exposed as Return-Path after delivery, not the visible From. On this CNAME route, the envelope subdomain resolves to provider-managed SPF. Adding a root-domain include:email-od.com does not select a custom bounce domain. Preserve your existing root SPF for other senders.
SocketLabs supports multiple bounce mappings and matches the From address to the appropriate entry. An unmatched sender can use the selected default entry or email-od.com. Therefore, a correctly published bounce hostname for one domain does not establish alignment for a second brand using the same server. Mapping and fallback behavior
A useful acceptance worksheet has one row per From domain, including at least one intentional nonmatching test in a controlled environment if you administer multiple brands. Record the observed envelope domain rather than inferring it from the chosen default. Do not send tests to customers or introduce production fallback changes simply to demonstrate the behavior.
Avoid record collisions and preserve existing mail
Find the authoritative DNS host and export the existing records first. A CNAME owner cannot simultaneously contain ordinary TXT, MX, A or another independent CNAME. If bounces.example.com already receives mail or serves a website, choose an unused owner and configure that same owner in SocketLabs. Do not remove a functioning service to make the example fit.
For a signing domain of alerts.example.com, a relative DKIM owner inside the example.com zone includes .alerts. A DNS editor that automatically appends the zone must not produce example.com.example.com. Inspect the saved full name and keep authentication aliases unproxied so public resolvers can follow them.
For SELECTOR._domainkey.alerts.example.com, the relative name is SELECTOR._domainkey.alerts in the parent example.com zone, SELECTOR._domainkey in a delegated alerts.example.com zone, or just SELECTOR if _domainkey.alerts.example.com itself is delegated. For apex signing in a delegated _domainkey.example.com namespace, SELECTOR._domainkey.example.com also uses relative name SELECTOR. Use dkim only for the documented CNAME method or when actually issued; TXT methods keep their configured selector. Preserve NS delegations and publish at the real authority. DNS zone boundaries.
A long TXT key may appear as multiple quoted character strings within one DNS record. That differs from multiple conflicting TXT key records at the same selector. Confirm the concatenated key matches the issued value. Other services may keep their own selectors without conflict.
For the applicable DKIM and bounce CNAMEs, require the exact literal alias and target at authoritative and recursive resolvers. Keep them DNS-only. On Cloudflare, turn the relevant per-record Flatten option off where available and ensure zone-wide flattening does not suppress these aliases. Coordinate any shared setting change with the DNS owner and dependent services first. Apex flattening is automatic; same-zone targets are flattened regardless of the setting. If mandatory behavior prevents the required alias, stop and agree a supported configuration with the DNS host and SocketLabs, without inventing a switch or removing delegation. These controls do not apply to native TXT keys. Cloudflare CNAME verification and flattening behavior.
SPF has a separate constraint: one SPF policy per evaluated owner and at most ten DNS-lookup-causing terms during evaluation. Preserve existing authorizations and the final policy qualifier when changing an unrelated SPF policy. Never add a TXT SPF record beside the custom bounce CNAME to make a checker turn green. SPF processing rules
If an unrelated direct SPF policy uses redirect=, any all mechanism makes that redirect ignored regardless of position. Preserve its legitimate redirected authorizations and approved ending through a reviewed design; do not append all blindly. This does not authorize adding local SPF TXT beside the SocketLabs bounce alias. SPF precedence.
Publish DMARC safely
Inspect the exact From domain and applicable inherited policy before adding anything. Do not overwrite enforcement or create a child monitoring exception to bypass a parent policy. Preserve reporting recipients and alignment settings unless the domain owner has approved a deliberate change.
For a new domain with no established or inherited protection to preserve, an approved monitoring example is:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
For From addresses at news.example.com, the local policy owner is _dmarc.news.example.com. Use _dmarc.news in the parent example.com zone, or _dmarc when editing a separately delegated news.example.com zone. Confirm the full saved owner. External aggregate-report destinations must satisfy RFC 9990 section 4 reporting authorization; use the reporting service’s issued authorization rather than guessing a record.
For the apex example _dmarc.example.com, use relative name _dmarc when the editor appends example.com. Compare the report destination host’s Organizational Domain with the Organizational Domain where the applicable policy was discovered. If different, the receiver generating reports must check external DNS authorization; a destination in the same Organizational Domain is excepted. A different hostname alone is not external. Separately approve the recipient, data sharing and retention with the domain owner. RFC 9990 section 4.
Use your real domain and a provisioned reporting mailbox. Keep the semicolons and publish only one DMARC policy at this owner. External report destinations can require separate authorization. Monitoring is not enforcement; inventory other senders before considering quarantine or rejection.
DMARC needs either aligned passing SPF or aligned passing DKIM. Relaxed alignment permits domains sharing an organizational domain; strict alignment requires exact equality. Thus bounces.example.com and example.com can align under relaxed SPF but not strict SPF. A correctly aligned DKIM signature can still provide the DMARC pass. RFC 9989 supersedes RFC 7489 and removes the legacy pct tag.
Verify each layer with concrete evidence
Use the actual configured names in these read-only checks:
dig +short NS example.com
dig +short CNAME bounces.example.com
dig +short TXT bounces.example.com
dig +short CNAME dkim._domainkey.example.com
dig +short TXT _dmarc.example.com
For TXT signing, replace actual-selector below with the selector issued or configured for your account; it is a placeholder, not a literal selector:
dig +short TXT actual-selector._domainkey.example.com
Use that TXT query instead of relying on the example CNAME query. Expect the issued alias or public key, the chosen bounce alias and one intended DMARC policy. A TXT lookup at the bounce alias may show a CNAME and its resolved provider answer; do not interpret the absence of a local customer TXT as automatically broken. Compare authoritative and recursive DNS if results differ.
After the panel confirms activation, send a new message through each production application to a controlled mailbox. Inspect the receiving system's trusted Authentication-Results, not arbitrary earlier fields. Capture spf and smtp.mailfrom, dkim and header.d, plus dmarc and header.from. Obtain the selector from the corresponding DKIM-Signature. Authentication-Results trust model
Use results produced inside the actual receiving service’s known processing boundary, established from its documentation or mail administrator. Confirm its handling/removal or distinction of externally supplied Authentication-Results and ignore attacker-supplied fields. Header position and a matching authserv-id are not proof. If provenance is uncertain, leave acceptance open and obtain receiver-controlled diagnostics or an administrator-confirmed trace. Forged results.
Acceptance of the branded DKIM setup requires the expected envelope mapping and the intended SocketLabs custom signature itself to pass and align with the unchanged intended visible From. Reconcile its observed d= and s= with the account-configured signing domain and selector. Also require trusted receiver dmarc=pass for that From. An unrelated passing signature, provider-domain From rewrite or SPF-only DMARC pass is insufficient. A green DNS badge or removal of a client-specific “via” label is not sufficient evidence. Store redacted headers, server identity, configuration version and timestamp; keep live delivery testing separate from documentation review.
Investigate SPF independently at the actual observed envelope identity: fail or softfail means the connecting sender is not authorized as intended; check the route, IP and policy. temperror indicates transient DNS/evaluation failure, while permerror needs repair of invalid syntax, duplicate policies or excessive evaluated lookup terms. A merely unaligned SPF pass is different. Do not dismiss these errors because branded DKIM supplies DMARC pass. SPF result handling.
Troubleshooting and FAQs
Why does SPF pass but DMARC fail?
Compare the envelope domain to From. Default email-od.com authentication is not your brand. Check unmatched bounce mappings, server selection and the branded DKIM result before changing root SPF.
Why does only one application receive the custom signature?
Compare exact From and Sender domains, the selected server and the configured signing method. Test a fresh message after saving. Do not assume that configuration in one subaccount applies to another.
What if the DNS host rejects an underscore CNAME?
SocketLabs documents TXT signing as an alternative. Arrange the supported method with the account administrator; do not remove _domainkey or rename the selector only in DNS. The signer and public record must agree.
Why does the custom bounce setting stay disabled?
Check the public CNAME and exact owner before retrying activation. A DNS-only change is incomplete until the platform validates it. An existing record conflict, duplicated suffix or wrong authoritative zone can prevent validation indefinitely.
Does DMARC require both customized SPF and DKIM?
One aligned passing mechanism suffices for DMARC. Configure both supported paths for operational resilience where appropriate, while distinguishing receiver-specific sending requirements from the DMARC pass rule. Authentication does not guarantee inbox placement.
Related guidance and review scope
For domains also used by employees, EmailAuth's Workspace alias and secondary-domain guide covers a separate sending route. Preserve those authorizations during SocketLabs changes.
No account configuration, DNS modification or delivery test was performed. Verify your account settings, live DNS and delivered-message results using the checks above.