Use the account configuration as the starting point
Sendloop provides an account workflow for sender-domain authentication, while its public authentication wizard also mentions dedicated DKIM and alignment settings. Those pages establish that authentication is available, but they do not establish the exact record set, signing identity or envelope controls for a particular account. This guide takes you through the documented account workflow and a controlled verification plan. A dedicated DKIM arrangement or custom envelope requirement remains a provider-confirmation item. Sendloop authentication wizard, DKIM and domain alignment settings.
First identify the account, approved From domains and the campaigns or automations that use each one. Record whether the account has a dedicated delivery arrangement and who can confirm it. Do not infer dedicated infrastructure from a pricing label, an old onboarding email or a third-party list of sending IPs. Assign a Sendloop administrator, a DNS owner and a reviewer for the organization's DMARC policy.
Before making changes, export the current DNS entries for the relevant owners. Keep one representative received message from the existing approved route if available. An inventory of what already works prevents a new authentication project from accidentally disabling another sender. The target is an authenticated and aligned Sendloop route, not a wholesale replacement of the domain's email configuration.
Open the sender domain control panel
The provider's guide routes you through Settings > Sender Domain Authentication > Authenticate Sender Domain, then Add Domain. The resulting Domain Control Panel supplies account-relevant values and a Check DNS Records action. Capture that output before editing DNS. If the current interface differs, use the current provider instructions or support rather than guessing equivalent buttons. Sendloop guide, Using the Email Authorization Wizard and Check Your Authentication Set Up.
Record each full owner, DNS type, value and TTL with its purpose. Keep the displayed record set attached to the change ticket. If the panel shows a missing record, determine whether it is absent, published at the wrong owner or present with a different value. A domain already configured for another Sendloop account may need provider coordination rather than replacement.
The public guide has an SPF example and an existing-record amendment that do not list identical includes. It also describes preparing text files. Do not turn either detail into an automatic production recipe. DNS must contain the current, applicable policy; a text file saved on a workstation does not publish it. Resolve any discrepancy between the account panel and the public page before implementation. Sendloop guide, Set Up the SPF Record.
Review SPF without widening unrelated permissions
Determine which envelope domain the real Sendloop message uses. That is the identity to investigate for SPF, rather than assuming that the visible From domain must be the evaluation owner. If an authorized custom envelope arrangement exists, capture its issued settings and scope. If it does not, record the observed provider envelope identity and evaluate DKIM alignment separately.
At any owner being changed, retain a single SPF policy and preserve authorizations required by other active senders. Review nested DNS lookups before adding new terms. SPF's ten-term limit applies to mechanisms and modifiers that cause DNS lookups during evaluation, not to the number of words visible in the record. Existing permissive mechanisms are also worth reviewing, but removing them is a separate dependency decision. RFC 7208, sections 4.5 and 4.6.4.
Do not copy a broad sample policy as a replacement for the existing record. Doing so could authorize unwanted hosts, change the failure qualifier or remove another provider. When the required authorization cannot fit safely, stop and ask the mail owner to choose a supported design. Do not solve the problem by publishing another SPF policy or deleting services that happen to be unfamiliar.
Publish only the issued public DKIM material
Use the owner and public value provided for this account. The public guide shows a DKIM TXT setup, but its demonstration key is not the customer's key. If the panel or support supplies a different supported record form, retain that instruction rather than converting it without evidence. Sendloop guide, Set Up the DKIM Record.
Only the public verification key belongs in DNS. DKIM creates a cryptographic signature with a private key; it does not embed the private key into the outgoing message. The public guide's informal explanation should not be read as a request to share signing secrets. The message carries a signature, and the verifier uses the public key identified by its signing domain and selector. RFC 6376, sections 3.5 and 6.1.
Check the proposed owner for an active key belonging to another route. A collision requires coordination; it is not safe to overwrite a working selector just to clear a red status. Verify the fully qualified name after publication, including the domain suffix added by the DNS editor. Keep timestamps and query results so later reports can distinguish a stale cache from an incorrect owner or key.
Keep link branding outside the alignment conclusion
The provider's guide describes an optional CNAME for aliased message links. Its purpose is link branding, not evidence that SPF or DKIM aligns. Implement it only if the relevant tracking change is approved and the account supplies the exact target. Sendloop guide, OPTIONAL: Set Up the CNAME Record.
Check existing website or tracking use before claiming the proposed owner. Do not point the root website or a live application hostname at a tracking target. Keep a harmless test link in the controlled campaign so the reviewer can verify both its destination and its displayed hostname. Authentication and link function are separate acceptance checks; a branded link that works does not establish a valid signature.
Return to the account's DNS check after publication. Compare every displayed result with an independent public lookup. Record pending states honestly. If an account shows verified while the external test still fails, leave the change open and use the message evidence to locate the remaining boundary.
Collect a received message identity record
Send through the actual campaign workflow to controlled external mailboxes using no customer data. Repeat for materially different From domains or delivery configurations. Preserve the original message and trusted receiver results, along with a Message-ID and UTC timestamp. Record all DKIM signatures rather than stopping at the first signature that passes.
The evidence record should contain the visible From domain, authenticated envelope identity, Return-Path, DKIM d= and s= values, SPF and DKIM outcomes and the receiver's DMARC result. Establish which passing mechanism aligns with the From domain. Relaxed and strict alignment impose different domain comparisons; record the mode in use. RFC 9989, Identifier Alignment Explained.
If the only passing signature uses an unrelated provider domain, request the supported customer-domain signing option and its activation conditions. The public wizard's dedicated-DKIM contact note does not prove that the option is enabled, free, available on every plan or configured automatically. Obtain those answers for the exact account. Do not represent a tracking alias as an alternative envelope domain.
Use the failure to select the next check
For a missing DKIM signature, confirm the account, selected From identity and provider activation. For a signature failure, compare the observed selector and public key before investigating downstream changes to signed content. A test with a different sender address may succeed while the affected campaign still fails, so keep the workflow constant during diagnosis.
For SPF failure, identify the evaluated domain and final sending source. For SPF pass with DMARC failure, inspect alignment rather than adding more SPF includes. If the provider cannot document the required identity option, keep that requirement blocked and assess another supported route with the business owner. Do not lower a whole domain's policy simply to make one provider's test stop failing.
Prepare a support bundle containing account identification, the affected domain, issued public records, observed DNS answers, Message-ID, time and relevant receiver results. Exclude passwords, API keys, recipient lists and unrelated message content. A concise reproducible failure is more useful than multiple uncorrelated screenshots of DNS edits.
Worksheet recovery and acceptance
Use the Sendloop authentication worksheet (create a separate review record with the fields described here) to track the record discrepancy review, dedicated-feature confirmation and final identity comparison. A missing envelope capability answer can remain explicitly unresolved even when ordinary aligned DKIM works. Define acceptance against the business requirement rather than filling every blank with an assumption.
If the change fails, pause affected sends and restore the previously approved configuration through the recorded change plan. Coordinate DKIM changes with provider activation; deleting a public key while the service still signs with it creates a new failure. When retiring Sendloop, confirm all campaigns and automations have stopped and review shared SPF dependencies before removing trust or tracking records.
Fictional worked example of an SPF discrepancy
Fictional written case only: SLP-01 assumes intended From offers@workshop.example. The public example contains two provider includes while its existing-policy instruction names one; current account authorization, envelope identity and DKIM/SPF results are unknown. The DNS owner holds the change and asks the account owner to obtain route-specific confirmation. A text file and a branded link do not establish authentication. After clarification, the team would review one policy and collect a controlled campaign message. No account, DNS or sending test was executed.
Documentary coverage and remaining gates
This draft covers the public account workflow and safe verification. It does not establish a universal dedicated-DKIM or custom Return-Path setup, and it does not claim a live aligned Sendloop message has been inspected. Those account-dependent details, live DNS and header evidence, independent review, visual review and human SME approval remain pending. Keep the original full implementation scope on hold until the required account evidence closes the gaps.
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.