Sugar Market SPF, DKIM and DMARC setup, step by step

In current Sugar Market, formerly Salesfusion, connect the approved domain through Admin > General > Brands and Domains, publish the exact records generated for the account, and finish DNS, SSL and completion checks. The current illustrated DNS screen uses an SPF CNAME and DKIM/DMARC TXT records. It is not a universal apex-SPF include recipe. The domain must reach Active, followed by a controlled test of the intended branded sending route. Current domain setup · Former Salesfusion identity

Scope, permissions and the October 2026 change

This guide covers the Brands and Domains administration workflow introduced in Sugar Market 26.2.0 on October 19, 2026. The official page says existing connected domains remain listed but require completion of the new setup. Do not combine an old Salesfusion static-key tutorial with the current account-generated packet. This is Sugar Market, not a procedure for Sugar Sell or an unrelated SMTP provider.

Access requires the default Admin Navigation role or Marketing Admin - Brands permission. The DNS owner also needs access to the actual authoritative zone. The interface shows the account's connected-domain limit; the Customer Success Manager handles increases. A screenshot showing a particular limit does not establish your entitlement. Eligibility and version boundary

Before starting, record the existing domain, sender, DNS, DMARC and web-routing baseline. Obtain the domain owner's approval of the sending identity and the website/routing owner's separate approval of the complete proposed Pages and Link Tracking hostname and target design. Receiving a generated packet is not approval to move an occupied website or redirect existing links. Do not change parent nameservers, mailbox MX, DNSSEC or credentials to match a screenshot.

The documented connection flow includes routing and SSL steps even if optional web tracking remains disabled. If those consequences are not approved, stop before committing hostnames; do not assume the DNS-authentication stage alone completes onboarding.

1. Start the correct domain in Brands and Domains

1. Open the user menu and choose Admin.
2. In the Administrator area's General tab, choose Brands and Domains.
3. Set up the root domain provided for the instance first, using Connect your domain.
4. After the root is connected, use Add Subdomain or Add Brand for the appropriate additional domain. A subdomain requires its associated Brand and Subdomain, then Add. A brand requires its brand name and domain, then Create.

Complete the setup already in progress before adding another domain. Progress is saved, so an incomplete entry can be resumed rather than creating a duplicate. The root-domain label describes the instance workflow; it is not an instruction to put every generated DNS record at @. Official connection sequence

2. Review the account-issued authentication records

On DNS Configuration, copy the generated SPF, DKIM and DMARC details with the page's copy controls. Use your own current packet, not the masked screenshot values. The official screenshot distinguishes the SPF CNAME row from the two TXT rows grouped under DKIM/DMARC. Never turn the SPF CNAME target into an invented include, replace an apex TXT policy with it, or assume a universal owner or selector. DNS Configuration and record illustration

Keep DNS purposes separate:

SPF evaluates the actual SMTP MAIL FROM domain, or HELO in relevant cases, rather than visible From. A generated SPF alias does not prove aligned SPF for every sending identity. Inspect the resulting envelope and the alias target's TXT policy. If you also maintain a separate applicable SPF TXT policy, preserve one v=spf1 policy per owner, all legitimate senders and its qualifiers. The ten-term limit concerns evaluated DNS-dependent mechanisms/modifiers including nested lookups, not merely ten visible includes. An all mechanism makes redirect ineffective; do not blindly combine them or alter unrelated policies. Qualifiers do not guarantee final delivery decisions. SPF rules

3. Map owners and prove publication

Use the record type and complete owner supplied by Sugar Market. For example, an issued full SELECTOR._domainkey.example.com is relative SELECTOR._domainkey in the example.com zone. For SELECTOR._domainkey.news.example.com, use relative SELECTOR._domainkey.news in the parent zone, SELECTOR._domainkey in a delegated news.example.com zone, or SELECTOR in an existing delegated _domainkey.news.example.com namespace. SELECTOR is illustrative, never a prescribed value. Preserve all existing NS delegations and other selectors.

For any issued non-selector child owner such as ENVELOPE.example.com, the relative label in example.com is ENVELOPE; in a separately delegated zone of that same full name, it is the documented root field, usually @. Do not assume an apex CNAME can coexist with required zone records. If the packet appears to conflict with existing apex or child services, obtain a supported design from SugarAI Support and the DNS owner before proceeding. For an independently approved SPF TXT at example.com, the full owner maps to the parent-zone root; a TXT at news.example.com maps to news in the parent or the child-zone root. These are naming examples, not extra records to deploy.

A CNAME cannot share its owner with TXT, A, AAAA, MX or a different CNAME. Use DNS-only rather than HTTP proxy for required aliases. Where a literal CNAME answer is required, turn a relevant per-record Flatten control off if supported and ensure applicable whole-zone settings do not conceal the alias. Mandatory apex or same-zone flattening may still apply; if the required answer cannot be preserved, stop and coordinate a supported configuration. Do not make blanket global changes or remove shared delegations. Named Cloudflare controls apply to Cloudflare, not every DNS host. DNS alias rules · Cloudflare flattening behavior

Replace the uppercase placeholders in these read-only examples and repeat for every issued record:

dig @AUTHORITATIVE-NS CNAME ISSUED-SPF-OWNER
dig @RECURSIVE-RESOLVER CNAME ISSUED-SPF-OWNER
dig @RECURSIVE-RESOLVER TXT RESOLVED-SPF-TARGET
dig @AUTHORITATIVE-NS TXT ISSUED-DKIM-OWNER
dig @RECURSIVE-RESOLVER TXT ISSUED-DKIM-OWNER

Compare complete owner/type/value data at the authoritative and recursive layers. Confirm the SPF alias reaches the expected usable SPF policy and the DKIM TXT contains the complete issued public key, not just that a record exists. Check actual cache lifetimes and auto-appended zone suffixes. Then choose Verify Records in Sugar Market. Once verified, choose Next. A verification indicator is not yet a delivered-message authentication result. Provider verification

4. Complete the approved routing and SSL stages

On SSL Configuration, enter the approved Hostname for both Pages and Link Tracking, then choose Submit. Review the warning before the second Submit: the documentation explicitly says these hostnames cannot be changed after submission; incorrect values require SugarAI Support. Verify the complete names against the approved design, not merely whether they look plausible.

After submission, choose Verify. Copy the issued Domain Routing CNAME details for Pages and Link Tracking into the correct DNS authority. Compare the complete approved owner/target set at authoritative and recursive DNS, preserving unrelated website, mailbox and existing tracking routes. Stop on an unexpected destination, occupied owner or incomplete set. Then choose Verify Records.

Next, add only the pending SSL Validation records from the generated list. The page shows records for all connected domains, including already-complete ones; do not republish or overwrite them wholesale. The current illustrated SSL-validation rows are CNAMEs. Apply the same alias conflict and literal-answer checks, compare every pending owner/target with the approved packet, and choose Verify Records, then Next once verified. Do not substitute the domain-routing aliases for the distinct SSL-validation aliases. Official SSL sequence and warnings

Read-only alias checks for each approved routing or validation record:

dig @AUTHORITATIVE-NS CNAME ISSUED-ROUTING-OR-SSL-OWNER
dig @RECURSIVE-RESOLVER CNAME ISSUED-ROUTING-OR-SSL-OWNER

5. Finish without enabling unrequested web tracking

Web tracking is optional. If it is not approved or wanted, disable Enable Web Tracking on the final step and choose Complete. The official page and domain-list illustration show connected Active domains with tracking Disabled. Do not add tracking code to a site merely to complete email authentication.

If tracking is separately approved, the documented branch provides code for the head of the selected pages, followed by Verify and Complete. That website change needs its own approved scope. This guide performs neither branch on your behalf.

In the Domains list, Active means connected and available for email sending; Incomplete requires further setup. A connected root domain cannot be edited through the normal list workflow; contact SugarAI Support for changes. Do not delete an active domain as a troubleshooting shortcut. Completion and domain management

6. Verify the actual Sugar Market sending route

After the domain reaches Active, send a controlled message through the actual approved Sugar Market workflow, using the unchanged intended From address and a valid test recipient. Do not substitute a message sent directly from your ordinary mailbox.

Establish the receiving service’s known processing boundary and its documented treatment of externally supplied Authentication-Results: removal, ignoring or clear separation from its own results. Use only results generated inside that trusted boundary. Header position or a familiar authserv-id string alone is not proof; an attacker can insert convincing-looking fields. If provenance is unclear, use an administrator-verified message trace instead. Authentication-Results trust model

Acceptance requires all of the following:

• The intended Sugar Market-issued signature matches the active configured d= signing domain and s= selector, and the trusted receiver reports dkim=pass for that signature.
• That signing domain aligns with the unchanged approved visible From domain under the effective adkim mode. A different aligned signer, a provider-rewritten From or SPF-only DMARC success does not complete Sugar Market branded DKIM setup.
• The trusted receiving system reports dmarc=pass for that intended From domain.
• SPF is checked separately against the actual smtp.mailfrom identity. Diagnose authorization fail or softfail, transient DNS temperror, and policy/duplicate-record/lookup-budget permerror separately even when aligned DKIM supplies DMARC’s pass.

Relaxed alignment permits matching Organizational Domains; strict alignment requires exact domain equality. Under aspf=s, a child envelope domain such as bounce.example.com does not align with From domain example.com, even if SPF passes. Under adkim=s, a child signing domain likewise does not align with its parent From domain. The generated SPF CNAME does not establish a separate custom MAIL FROM control or guarantee exact strict alignment. Use the actual account-issued identity and observed route; stop and clarify any mismatch. DMARC identifier alignment · Why a custom MAIL FROM affects SPF alignment

Preserve DMARC and approve reporting separately

Check both direct and applicable inherited policy before creating anything. Do not downgrade an existing policy, duplicate it, remove approved report destinations or automatically follow a generic progression to enforcement. A single passing Sugar Market sample does not inventory your other legitimate senders.

Only when no direct or applicable inherited policy exists, and the domain owner explicitly approves an initial monitoring policy with an appropriate review plan, this minimal TXT value can be considered:

v=DMARC1; p=none

For example.com, the full owner is _dmarc.example.com, relative _dmarc in the example.com zone. For news.example.com, the full owner is _dmarc.news.example.com, relative _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. An explicit child policy can override inherited behavior, so do not add it casually. No reporting address is included in this example; an approved monitoring plan must still establish who reviews the relevant authentication evidence.

If reports are desired, use only an actually provisioned, owner-approved and monitored destination. When the report URI host’s Organizational Domain differs from the Organizational Domain of the domain where the DMARC policy was found, the report-generating receiver checks DNS authorization. A destination within that same Organizational Domain is excepted; a different hostname alone is not enough to require external authorization. This protocol check does not replace permission to share potentially sensitive report data with the recipient. RFC 9990, section 4

Troubleshooting and recovery

Coordinate recovery with the domain, routing and campaign owners. Preserve baseline records and evidence; pause only affected sending if approved. Restore a previously approved configuration only after checking queued mail, shared selectors, existing links and SSL dependencies. Do not intentionally break live authentication, delete domains or switch to an unrelated transport to test fallback. After a correction, retest the failed path and a known-good control with controlled recipients. Authentication does not replace consent, unsubscribe and other campaign-owner launch checks.

Documentation review and testing boundary

October 19, 2026 is the documented feature-release date, not an inferred page-update date. No customer account, DNS, website code, Support request, email send, live implementation or publication was changed or tested.