Start with the subdomain and sender profile together
A Sendlane rollout has two connected parts: a verified sending subdomain and the sender profile that actually uses it. Complete both before testing a campaign. Sendlane documents verified subdomains as its required sending model and does not offer primary-domain verification. Its delegated approach gives Sendlane control over the selected subdomain, while the primary domain keeps its existing nameservers. The subdomain remains visible in the From address. Sendlane verification overview, primary-domain and nameserver questions.
Decide who owns marketing sends, DNS, security policy and replies. Inventory scheduled campaigns and active automations before altering a shared profile. Include brands or regions with distinct profiles, and record which of them may change together. The scope here is Sendlane campaign and automation mail. It does not establish the identities of unrelated transactional integrations, storefront receipts or the corporate mailbox service.
Use an unused subdomain approved for this purpose. A DNS lookup showing no answer for one record type does not prove that a name is unused. Check the zone, delegated children, website configuration, certificates, application settings and other email providers. If a proposed name is already serving something, choose another name or obtain a separately approved migration plan. Do not delete an unfamiliar record to make verification succeed.
Obtain the DNS method from this account
The setup page selects either four NS records or a set containing one MX, two CNAME and two TXT records. Its documented route is Account > Email > Setup Domain, followed by the primary domain and sending-subdomain fields. The guide specifically routes AWS users to the CNAME/MX/TXT method through support, even though AWS supports NS records. It also states that Wix and Hostgator support neither documented method; a DNS-host migration would require its own approved plan, not an improvised deletion of existing records. Shopify users are directed to a separate Shopify guide, so this general procedure is not a substitute for that route. Treat the current account output and provider confirmation as the implementation authority, rather than a remembered DNS recipe. Sendlane setup guide, Steps One through Three.
Save a dated copy of every issued owner, type, value, TTL and any MX priority. Do not substitute the demonstration domains or nameserver values in a help article for the account's current instructions. If the visible records conflict with the DNS host's capabilities, pause at this point and obtain a supported method. This is safer than implementing half of each method or attempting to translate delegation into guessed TXT records.
For an NS-based setup, the DNS review must explicitly identify the child zone being delegated. Verify that the change is below the primary domain. Changing the registrar's default nameservers would affect much more than Sendlane mail. Confirm the scope with a second reviewer and keep a pre-change export of the parent zone. Delegate only after the business and security owners approve that trust boundary.
Publish and inspect each issued record
Apply the record set at the authoritative DNS service, which may differ from the registrar. Check whether its editor appends the zone suffix. A host field that already contains the whole name can accidentally produce a duplicated domain. Compare the resulting fully qualified owners with the provider's issued names after saving.
NS delegation requires checks from both sides of the zone cut: the parent's referral and the child's authoritative answers. For the alternative method, inspect every CNAME, MX and TXT separately. A green check for one key does not establish that the other records are correct. Leave any unrelated records intact and save the before-and-after difference with the change ticket.
When a TXT record contains an SPF policy, review the complete policy at that exact owner. Multiple SPF policies at the same owner are invalid, and DNS-querying SPF terms have a ten-term evaluation limit including nested dependencies. Do not add Sendlane permissions to the corporate apex merely because it is the most familiar domain. Review the domain actually used for SPF. RFC 7208, sections 4.5 and 4.6.4.
Return to Sendlane and use Verify DNS Records. The guide allows up to 24 hours for initial verification; compare DNS answers rather than repeatedly changing them while caches expire. Preserve the provider's record status and observation time. A provider status is one acceptance layer, not proof of a received message's alignment.
Bind profiles without losing campaign coverage
Sendlane's setup instructions require a new or existing sender profile to select the Verified option and the verified subdomain in its From Email selection. Review reply handling separately: the overview describes authenticated profiles using the verified domain for From and Reply-To, while the setup form requests a Reply-To address. Confirm the account’s allowed reply configuration and actual monitored destination rather than assuming arbitrary overrides. Sendlane setup guide, Step Four.
Check every campaign or automation intended to use that profile. A verified domain sitting unused in account settings will not correct a stale profile elsewhere. Record the profile name, displayed From address, intended reply mailbox and the workflows that reference it. Make changes in a controlled window so a scheduled send cannot start between DNS verification and profile review.
Do not assume that changing a Reply-To address changes authentication. It is an operational destination for responses and should be tested for correct routing, but it is not the From identity against which DMARC alignment is evaluated. Also avoid treating a branded click-tracking hostname as the envelope sender. These fields can belong to different domains even when the message looks consistent in the inbox.
Inspect campaign and automation deliveries
Use harmless content and controlled external recipients. Send one test through the campaign route and one through a representative automation that uses the production profile. Repeat when different profiles, brands or material delivery routes are involved. Record the UTC time, campaign or automation identifier and Message-ID so support can locate the same message.
Preserve the recipient's original headers and trusted authentication results. Record the visible From domain, the SPF-authenticated envelope domain, Return-Path, each DKIM signing domain and selector, and the receiver's SPF, DKIM and DMARC outcomes. The signing domain and selector tell the verifier where to locate the key; they are not interchangeable with a sender-profile label. RFC 6376, sections 3.5 and 6.1.
Confirm which passing mechanism aligns with the visible From under the policy's alignment mode. A pass for an unrelated service identity is insufficient by itself. Keep the selected subdomain's policy and any relevant parent policy in the evidence so the reviewer can reproduce the conclusion. RFC 9989, Identifier Alignment Explained and DMARC Evaluation.
This guide does not promise a separate, user-selectable custom Return-Path feature. The public sources establish domain verification and profiles, not every tenant's envelope controls. If a required strict alignment outcome is missing, obtain the supported identity options from Sendlane and inspect a new message before approving that requirement.
Resolve failures at the correct layer
If records cannot be verified, first confirm the authoritative DNS provider, exact owner names, record types and any pre-existing use of the subdomain. If public DNS is correct but the account remains unverified, retain the issued record set and timed observations for support. Avoid deleting and recreating the domain while scheduled sends still reference it.
If DNS verifies but the received From is unexpected, inspect the chosen profile and the campaign or automation reference before changing keys. If DKIM is absent, confirm the tested workflow really used that profile. If DKIM fails, compare its actual selector with DNS and investigate message changes after signing. If authentication passes but DMARC fails, inspect the domain comparisons, not just the green result labels.
A delivery warning does not authorize weakening the organization's DMARC policy. Diagnose the failing identity with the policy owner and provider. Likewise, an internal allowlist can conceal a problem that external recipients still encounter. Use controlled receivers that evaluate the normal delivery path.
Keep a worksheet and rehearse recovery
Create a separate review record for the Sendlane implementation worksheet using the fields below. Keep one copy per subdomain and profile group. Record issued records, DNS evidence, affected workflows, receiver results, the aligned mechanism and the person approving release. Put public keys in the evidence only when needed; never include credentials or private keys.
Before release, decide how to pause new campaigns and automations and return affected workflows to a previously approved identity if tests fail. Do not remove delegation first: doing so can remove the authentication answers while mail is still being sent. Retain evidence for queued or already delivered messages, and agree on a retirement window before deleting obsolete trust. Treat moving DNS providers, changing the selected domain or altering profiles as reasons to retest.
Fictional worked example of an unbound profile
Fictional written case only: SL-01 stipulates a campaign profile with From offers@news.example and passing d=news.example. A welcome automation still references an older profile with From welcome@old.example; its DKIM and SPF identities/results are unknown. The marketing owner must inspect the automation’s binding and obtain a new controlled message before approving that route. The campaign result cannot close the automation gap. No account, DNS change or message test was executed.
Plan controlled sending after authentication
The setup guide’s Step Five directs operators to warm the verified domain. Do not interpret successful DNS and header checks as permission to immediately send full volume. Agree a gradual, consent-based sending plan with the deliverability owner and monitor outcomes; this guide does not prescribe a universal rate or claim that any warm-up was executed.
Acceptance remains an evidence decision
Release only when the intended workflows use the approved profiles, public DNS matches the issued record set, Sendlane verifies the configuration, and received-message evidence shows the required aligned pass. Authentication does not guarantee inbox placement or a good sending reputation. Live tenant access, live DNS and message tests, independent technical review, visual review and human SME approval remain pending for this unpublished draft.
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.