Resolve which Sarbacane service is sending
“Sarbacane” is not a sufficiently precise DNS change request. The inspected first-party documentation includes a Campaigns delegated-subdomain procedure and a separate Sendkit manual-record procedure. A generic-looking domain-configuration URL redirected to a page explicitly titled for Sendkit during this review. That difference determines which instructions belong in the change ticket.
Ask the account owner to identify the product, account and actual campaign or application route. Save a screenshot or administrative reference privately in the change record. Do not authenticate Campaigns by copying an SPF value or DKIM key from a Sendkit article simply because both live in the Sarbacane help center. This guide leads with Campaigns, explains the Sendkit boundary, and leaves any unsupported route unresolved rather than guessing.
The Campaigns explanation of personalized sending domains distinguishes shared service domains from an organization’s own identity. Decide which identity recipients should see before provisioning anything. A branded display name and a link containing your company name are not substitutes for that decision.
Check the subdomain before delegating it
Choose a namespace with a documented owner and purpose. Inventory its existing records, dependencies, delegated children, links and applications. A subdomain that looks unused in the browser can still support mail, verification records or another service. Do not place a new delegation over existing production use without a reviewed migration plan.
Document which team manages the parent domain and which party will answer for the delegated child. Keep the proposed boundary explicit in the ticket. Changing the registrar’s nameservers for the entire domain is materially different from adding NS records for one child zone. The latter must not accidentally become the former because a DNS interface uses similar labels.
Also record the existing DMARC policy applicable to the intended From domain. Authentication setup does not authorize replacing that policy or changing report recipients. If a new sending subdomain is chosen, ask the domain owner to review the effective policy and alignment mode rather than assuming the child is isolated from parent-domain decisions.
Follow the Campaigns account-issued delegation
The Campaigns hosting guide, “Prérequis” and “Étapes (exemple avec OVH)” requires the subdomain to have been created in Campaigns and the Configuration du domaine par délégation window to be available. It directs administrators to obtain the values from that window, put the ownership TXT at the root domain, and add the two supplied NS targets at the selected child. The related troubleshooting guide allows up to 48 hours for validation and notes that hosting support for delegation varies.
Record each issued owner, type and value before opening the DNS editor. Confirm the interface’s treatment of a relative owner versus a fully qualified name. For the ownership token, do not confuse the parent-domain location with the newly created sending child. For the NS records, verify that both target values match the account instructions and that the owner is the intended subdomain.
Preserve unrelated TXT records, including existing SPF and verification values. The ownership token is not an instruction to create or replace an SPF policy. Keep a before-and-after DNS export and the exact time of publication. Validate the delegation with authoritative DNS answers, not just the application’s green indicator or the hosting control panel’s saved state.
Do not invent nameserver targets or copy the sample domain shown in the help article. If the selected DNS host cannot support the required delegation, stop that route and ask Sarbacane for a supported approach. Changing hosting providers or buying a new domain is a separate decision, not an automatic repair.
Diagnose an invalid domain without blind deletion
The Campaigns “Invalide” article, timing and verification sections distinguishes ordinary propagation from records added more than 48 hours after domain creation. For that delayed-setup case it describes removing and re-adding the domain in Campaigns to restart activation, while retaining the DNS records. It also reiterates the parent TXT and child NS locations.
Use those distinctions as a diagnostic sequence. First compare the actual DNS owners and values with the account. Next determine when the domain was created and when the records became public. Then establish whether there is existing campaign activity attached to the domain. A historical timing remedy is not permission to delete a production object without understanding its dependencies.
If support recommends re-adding an active domain, obtain a scoped change plan and record what must be restored. Retain the current campaign settings and evidence of the old state. After any recovery action, repeat both domain validation and a received-message test; a changed application status alone does not prove that every scheduled campaign uses the restored identity.
Keep Sendkit manual records in their own change
The Sendkit domain page, required records and domain-validation sections documents SPF, DKIM, MX, A and tracking-domain configuration for that service. It describes 1024-bit and 2048-bit DKIM options, recommending 2048-bit. Its validation requirements include SPF, DKIM, MX and tracking. These are product-specific instructions, not the Campaigns NS-delegation procedure.
For a Sendkit deployment, start a separate record inventory and compare the current account instructions with the page. Do not replace an existing mail-receiving MX or website A record merely to satisfy a checklist. Establish a suitable domain and the supported handling of incoming replies and bounces with the product owner. If the source’s examples conflict with account-issued settings, obtain a provider answer before publication.
A tracking hostname can be relevant to a provider’s domain validation and link reputation, but it is not the domain that DMARC authenticates. Keep tracking validation, return routing and sender authentication as separate acceptance fields. This review does not establish a single custom Return-Path workflow valid across all Sarbacane services.
Verify the authentication identities after sending
After the account reports the domain ready, send a small harmless campaign to controlled external mailboxes through the actual product. Record the campaign identifier and UTC time. Include representative link and reply behavior, but no customer list or private customer content. If multiple accounts, domains or automation routes are in scope, test each meaningful variation.
Capture the visible From domain, Return-Path or receiver-reported envelope identity, every DKIM signing domain and selector, and the receiving system’s trusted authentication results. RFC 6376, section 3.5 defines the DKIM d= and s= fields. Confirm that the public key found for the observed signature belongs to the configured route. Do not infer signing from the fact that DNS authority was delegated.
RFC 7208, sections 2.3 and 4.6.4 explains the MAIL FROM identity and SPF lookup limit. If a manual SPF change is required for the confirmed product, review the entire existing policy and nested lookups. Do not add a second policy or blindly copy a complete sample over other senders’ authorization.
Apply RFC 9989, section 4.4, “Identifier Alignment Explained” to the received identities. Record the aligned passing mechanism, not only three green labels in a dashboard. A passing DKIM signature under an unrelated service domain does not establish your From-domain alignment. Strict and relaxed alignment can also lead to different conclusions when a parent and child domain are involved.
Complete the product-and-domain worksheet
Create a separate review record for the Sarbacane product and delegation worksheet using the fields below. It keeps Campaigns and Sendkit decisions visible, separates ownership verification from authentication, and provides fields for DNS authority, application status, received identities and recovery. Complete the product field first. If it is unknown, record who will confirm it and do not proceed using whichever article is easiest to find.
For a delegated zone, retain both the parent-side NS evidence and the child’s resulting authentication answers. For a manual-record setup, retain each intended record and its live answer. In both cases, keep the receiver evidence tied to the same account and campaign. Those artifacts let a future administrator distinguish a provider-side configuration issue from a parent-zone error.
Fictional worked example: correct records for the wrong service
Fictional written case only: SC-01 assumes the owner requests Campaigns From news@updates.example, while the DNS ticket cites a Sendkit key. Account-issued Campaigns ownership token and child nameservers are not yet collected; DKIM, SPF and receiver identities are unknown. The marketing owner confirms the product and the DNS owner holds the mismatched ticket, retrieves the correct delegation and reviews the unused child zone. Approval remains open pending product validation and a received-message identity check. No account, DNS record or message was accessed.
Set the recovery and maintenance boundary
If delegation breaks an existing dependency, pause new campaigns and coordinate recovery with the DNS owner and Sarbacane. Restore only a reviewed prior configuration. Removing a delegation can also remove access to authentication or tracking records below it, so it is not a harmless way to reset a warning icon. Keep cached DNS and messages already in flight in the recovery plan.
Recheck after a product migration, domain change, delegation change or newly introduced automation. Current account values, custom envelope support for the selected route, live DNS and header evidence remain unverified here. The original broad Sarbacane scope stays on hold until the exact product is confirmed. This is an unpublished documentary draft with visual review and human SME approval still pending.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.