Treat the sending domain as a coordinated Sailthru launch
A Sailthru sending domain needs more than visible DNS records before production mail is ready. The launch should join domain authentication, provider enablement, a working sender mailbox and a controlled delivery test. Start with the exact domain after the at sign in the intended From address. Record which account and business messages will use it, and separate marketing campaigns from any transactional route whose configuration differs.
Sailthru's new sending domain guidance calls for DNS setup and a ramp plan reviewed with its team. It also applies this review to a domain already present in an account but not actively used. A dormant domain with records in place should not be treated as having an established sending reputation. Authentication readiness and production-volume readiness are separate decisions.
This guide covers authentication setup and evidence gathering, not a promise of inbox placement or a universal sending-volume schedule. Use the current account's approved setup and provider contact to resolve any mismatch. Live account, DNS and header verification remain pending until the organization completes the worksheet and tests below.
Check strict alignment before making the change
Read the existing DMARC policy and record its alignment modes before enrolling the domain. Sailthru's Configure DNS Records guide explicitly states that strict adkim or aspf is not supported. If the organization's required policy uses either strict mode, treat compatibility as an open design decision with Sailthru and the security owner. Do not silently remove those tags or weaken policy to complete a setup checklist.
Consider the intended sender domain and the wider organization's legitimate mail routes together. An isolated adjustment to a shared domain's policy can affect employee mail, finance applications and other services. If a different sending domain is proposed, evaluate its policy context and business implications before using it. A subdomain is not automatically a safe exception to every inherited policy or sender-reputation concern.
Under RFC 9989, a DMARC pass requires successful SPF or DKIM authentication with an identity aligned to the From domain. Relaxed and strict comparisons differ, so the acceptance worksheet must say which mode applies. Do not report an authentication pass as an alignment pass simply because the provider has recognized the DNS record.
Prepare the record set and inspect dependencies
Obtain the current Sailthru instructions for the domain and preserve a baseline of all affected DNS owners. The published setup includes an SPF include, two DKIM CNAMEs and a bounce-domain CNAME. Review their complete names and targets against the actual sender domain. A subdomain sender requires the corresponding full name; omitting a label can configure a different identity from the one campaigns use.
For SPF, review the whole policy at the relevant owner under RFC 7208. Keep one SPF policy, retain other required senders and account for nested DNS-querying terms. A provider include is a continuing authorization, not a harmless comment. Do not insert all historical examples from different guides or replace an existing terminal qualifier without approval.
Distinguish the DNS tasks by purpose. DKIM verifies a signature. The bounce-domain configuration supports the envelope identity. Ownership or feedback-loop verification records serve their own functions. Link and tracking domains are separate operational dependencies. A successful link redirect does not prove DKIM is active, and an authenticated message does not prove that every old campaign link remains usable.
Publish both DKIM delegations and complete provider enablement
The current Sailthru guide specifies two DKIM CNAMEs and requires the provider to complete setup before they become active for sending. Use the exact current owners and targets for the From domain, and check both records after publication. Do not assume that creating one apparently working selector is enough or that DNS presence triggers activation automatically.
Inspect existing records at the proposed names before saving. A CNAME conflict needs resolution with the administrators of the dependent services. Do not combine incompatible data at the same owner or invent a different selector without provider support. Check the DNS editor's automatic suffix handling and compare the final fully qualified answers with the instructions.
Keep a clear record of the provider's activation confirmation. Ask what time new messages should begin using the configuration, then send a new test after that point. Reusing an old message can show the earlier configuration and mislead the review. Repeated DNS edits while waiting can create several overlapping cache states and make the diagnosis harder.
Verify the bounce identity and sender mailbox separately
Confirm the bounce-domain CNAME in the account's setup instructions and the actual Return-Path observed after activation. A published alias is not proof that a particular sending route uses it. If the received envelope identity differs, preserve the result and ask Sailthru which setting or provisioning step controls that route. Do not alter the root SPF policy repeatedly to compensate for an unexplained envelope identity.
After provider enablement, the documented sender-address verification occurs through Setup and Verified Emails. The sender mailbox must be able to receive the verification message. Use a mailbox controlled by the organization and identify the person responsible for responding to customer replies. A display name or marketing alias without a functioning inbox can create operational problems even when authentication succeeds.
When arranging Google Postmaster or feedback-loop access, separate the technical record from access approval. The setup guide includes provider collaboration steps, but sharing monitoring access is still an organizational decision. Grant only the approved access to verified recipients. Do not place credentials or unrelated domain information in a launch worksheet merely to speed onboarding.
Prove alignment using a real campaign route
Send a harmless test through the same account, sender selection and processing path as the intended campaign. Use controlled external recipients whose complete headers are available. Repeat for any materially different transactional or brand route. Record Message-ID, UTC time and the relevant campaign or test reference, without retaining unnecessary recipient content.
Capture the visible From, Return-Path, every DKIM d= and s= value, and trusted receiver results. RFC 6376 connects the DKIM signing domain and selector to the DNS verification key. Check whether a passing signature belongs to an aligned domain rather than relying on a generic green result. If more than one signature exists, identify which one supplies the relevant pass.
Compare the observed envelope domain with the intended bounce configuration and the From domain. Record whether SPF passed, whether it aligned and whether DKIM supplied alignment independently. Keep these as separate fields so a later change to one mechanism does not erase knowledge of the other. Authentication success is necessary evidence, but content, recipient expectations and sender reputation can still affect delivery.
Preserve working links and diagnose narrowly
If the rollout also changes a link domain, inventory old campaign dependencies before removing any previous setting. Sailthru's DNS guide warns that deleting an old link domain can break links in older messages. Authentication cleanup should therefore be limited to the records whose retirement has been approved, not a broad purge of every unfamiliar Sailthru-related name.
For absent DKIM, check provider enablement and the chosen sender domain first. For a failed signature, check the actual selector, DNS answer and any later message modification. For DMARC failure with a passing mechanism, inspect alignment and the strict-mode compatibility hold. For mail that was never sent, inspect account and campaign evidence before assuming DNS caused the problem.
Keep the ramp decision with the deliverability owner. A technically authenticated new sender still needs the agreed volume and cadence plan. Do not release an entire audience because one test arrives successfully. Save the test evidence, open exceptions and provider correspondence so the production decision is reviewable.
Sailthru launch worksheet
- Account, brand, workflow and intended From domain: ____.
- Business owner, DNS administrator and provider contact: ____.
- Existing DMARC policy and strict-mode compatibility decision: ____.
- SPF policy review and nested lookup assessment: ____.
- Both issued DKIM CNAMEs and public lookup results: ____.
- Bounce-domain configuration and observed Return-Path: ____.
- Provider activation and sender-address verification: ____.
- Monitoring access approvals and any separate link-domain change: ____.
- Test Message-ID, trusted results and aligned mechanism: ____.
- Ramp plan, unresolved exceptions and release approver: ____.
Fictional example of a premature launch decision
Fictional written case only: ST-01 assumes From offers@news.example.org, an existing policy requiring adkim=s, and DNS records on a dormant sender. No provider compatibility exception, current ramp plan or received-message results exist. The launch owner must resolve the documented strict-mode incompatibility with the security owner and provider before volume scheduling, without silently changing the policy. DNS presence does not close either gate. No domain, account or campaign was inspected.
Keep unsupported scope and release gates visible
Strict-alignment deployment remains outside this guide's supported configuration unless Sailthru provides a current supported resolution. Live tenant review, account-issued records, DNS and header verification, visual review and human SME approval remain pending. This is an unpublished implementation draft, not a completed domain launch.
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.