Xplor Growth SPF, DKIM and DMARC setup, step by step

To authenticate a sending domain in Xplor Growth, formerly BrandBot, request its DNS records from Xplor Growth Support, have your domain administrator publish the approved records, and ask Support to confirm completion. Then verify the individual sending email address and check the sending profile. Domain authentication and mailbox verification are different steps.

This guide covers the current Xplor Growth native email workflow, including the sending profile synchronized from Mariana Tek. It does not configure your Google Workspace or Microsoft 365 mailbox, replace its DNS, or authenticate every product sold by Xplor. If your account has a different sending-profile integration, establish its supported procedure with Support before changing settings.

There is no universal BrandBot SPF include, DKIM selector or public key to copy from this guide. The current first-party instructions use a Support-issued packet for your domain, followed by Support confirmation. Use that packet, not an old screenshot, another studio’s settings or a guessed underlying email provider. See Xplor Growth’s authentication procedure.

What you need before starting

Have these people and decisions in place:

• The owner’s approval to use the business domain for this sending service.
• Access to the correct Growth account and, for the profile-sync steps below, the relevant Mariana Tek location. The public instructions do not establish a universal role or subscription entitlement; use an authorized administrator if settings are unavailable.
• The administrator of the domain’s authoritative DNS, which may be different from its registrar or website host.
• A working custom-domain mailbox that its owner can access for verification and replies.
• An inventory of existing SPF, DKIM and DMARC records, active senders, inbound mail routes and any delegated DNS namespaces.
• A controlled test recipient already available to your team, with permission to inspect that receiving service’s raw message headers.

Personal domains such as gmail.com, yahoo.com and outlook.com are not your business’s domains to authenticate. If you need a new mailbox, arranging it with a mail host is a separate prerequisite. Authenticating Growth does not create an inbox or require moving existing inbound mail. The provider explains this distinction in its custom email address guidance.

If several locations use the same sending domain, Growth says it needs authentication only once. Each additional domain needs its own authentication. Still verify the actual account and location using it; a domain’s approval does not establish that every scheduled email has the right sender.

1. Request the records for your exact sending domain

Use the developer or IT team option in the official authentication article. Contact your established Xplor Growth Support channel and request the authentication records for the precise domain you intend to use after @ in the visible From address.

For example, a request can say:

Please provide the current domain-authentication records for our approved sending domain. Include each record’s type, full DNS owner name and complete value, the applicable Growth account or location, and how you will confirm authentication after publication.

Also establish whether any record affects bounce handling, inbound delivery, tracking or another existing service. Ask Support to identify the expected DKIM signing domain and selector, the SPF envelope domain, and any prerequisites needed to activate this account’s signing. The public guide does not publish those tenant-specific details, so do not fill gaps with a guessed value.

The same official page offers onboarding assistance and an IPStudio partner route. Those are alternatives, not a requirement to give an outside party your registrar password or broad administrative authority. The IT-managed option lets your existing DNS administrator make the approved changes. Any additional access or information sharing needs a separate security decision.

Do not ask for, publish or paste a DKIM private key. The DNS packet should contain public records. If Support’s instructions conflict with an existing service or do not specify enough information to identify the exact owner and value, resolve that conflict before publication.

2. Review the packet before editing DNS

Record the original DNS state and the proposed changes. Keep the packet’s full owner names separate from the shortened names your DNS editor may expect.

SPF: change the policy at the issued owner, not automatically the root

SPF evaluates the SMTP envelope sender, normally shown as smtp.mailfrom in a receiver’s authentication result. That domain can differ from the visible From address. A root-domain SPF change cannot repair an unrelated envelope identity.

At each owner being changed, publish one TXT record beginning v=spf1. If one already exists, have the DNS/mail administrator combine the approved authorization into that policy while preserving legitimate senders and the intended qualifiers. Do not replace a working mailbox policy or add a second SPF record.

If the issued policy uses redirect=, do not append it casually to an existing policy containing all: an all mechanism causes the redirect modifier to be ignored. Include and redirect are not interchangeable. Check the complete policy’s limit of 10 evaluated DNS-dependent terms, including nested evaluation, rather than counting only visible includes. These rules come from RFC 7208.

Do not change -all, ~all or ?all merely to make a tutorial match. They express different SPF outcomes, not guaranteed delivery decisions. Growth’s current public instructions do not establish one universal policy for all tenants.

DKIM: keep the type, selector and entire value intact

Use the complete public DKIM record supplied for your account. If it is TXT, retain the full tagged value, not just the key after p=. If the DNS editor splits a long TXT value into quoted character strings, those strings must remain parts of one record and concatenate correctly. Do not create multiple competing key records at the same selector.

If Support instead supplies a CNAME, publish that exact alias rather than converting it to TXT. At a CNAME owner, do not add another CNAME or conflicting TXT, A, AAAA or MX records. Stop and coordinate an approved selector or routing change if the owner is already occupied.

The current Growth help pages do not disclose which record type or selector your packet will use. These are conditional handling rules, not a claim that Growth always issues a particular number of CNAMEs or TXT records.

Keep any routing changes separate

Do not change MX, parent nameservers, DNSSEC, credentials or mailbox forwarding simply because a packet or example contains those settings. Compare any such request with an explicit, approved design for inbound mail, bounces and other affected services. Publishing an authentication record is not blanket permission to redirect business email or replace the website’s DNS.

3. Publish at the correct DNS owner

Use the zone served by the authoritative nameservers. A record in an unused registrar zone will not become public through waiting.

The following examples show names only, not Growth’s actual records. SELECTOR must be replaced with the exact issued selector; example.com and mail.example.com are placeholders.

An editor that expects the full owner may require the full name instead. Verify the resulting public name so it does not accidentally become example.com.example.com. Keep existing _domainkey delegations intact and make the change in the delegated zone when applicable. Do not delete a delegation or another service’s selector to force an entry into the parent zone.

If the packet requires visible CNAME aliases

Authentication CNAMEs should be DNS-only, not HTTP-proxied. Where validation requires the literal alias, turn a relevant per-record Flatten control off when available and ensure the applicable zone-wide settings do not flatten that issued alias. Coordinate a shared-setting change with the DNS owner rather than disabling it globally without assessing other records.

Cloudflare distinguishes whole-zone, per-record, mandatory apex and same-zone-target behavior. A per-record control may be unavailable in some of those cases. If the required alias cannot remain visible under the applicable behavior, stop and agree a supported configuration with Support and the DNS administrator. Do not invent a switch, move nameservers or remove a delegation. See the actual Cloudflare flattening procedure and proxy-status guidance.

For TXT-only packets, no CNAME flattening change is needed.

4. Check DNS, then obtain Growth’s confirmation

Compare the published answers with the issued packet. Query the actual authoritative server and a separate public resolver. The following are read-only examples; replace every uppercase placeholder before use:

dig @AUTHORITATIVE_NAMESERVER TXT SPF_OWNER_FQDN
dig @AUTHORITATIVE_NAMESERVER TXT DKIM_OWNER_FQDN
dig @AUTHORITATIVE_NAMESERVER CNAME DKIM_OWNER_FQDN
dig @PUBLIC_RESOLVER TXT SPF_OWNER_FQDN

Use the DKIM query matching your record type. For a CNAME packet, also inspect the issued target and its public key as appropriate. A record lookup proves only the answer returned at that time, not that Growth has activated signing or used the key on a message.

Missing or different answers call for checking authority, exact owner, record type, conflicting records, complete value and caching. The current Growth procedure does not promise a universal propagation or activation time. Do not import another provider’s 24-, 48- or 72-hour promise.

After the DNS administrator publishes the records, tell Xplor Growth Support. Its documented next step is for the team to confirm authentication is complete. Keep that confirmation for the exact domain and account. There is no public basis here for an additional self-service Generate, Verify or Activate button.

If Support cannot confirm completion, keep the affected campaign paused while it identifies the failed record or account-side configuration. A DNS screenshot or a Support request acknowledgment is not completion.

5. Verify the email address and set the sending profile

Open your business name at the top right, then Settings → Emails. The current email-settings instructions separate verified addresses from the default sending profile.

1. Use Add another verified email address for the address you intend to send from.
2. Have that mailbox’s owner complete the confirmation received by email. An address does not need its own Growth user account to be verified.
3. If verification is pending, use its warning label to resend the confirmation through the documented control. Do not use a recipient you do not control.
4. Confirm the address uses the authenticated domain. Growth says the first user added to an account is automatically included as a verified address; that does not replace domain authentication.

For the Mariana Tek-connected profile covered here:

• Default From Name can be changed in Growth.
• Default From Email and Reply To Email are synchronized from Mariana Tek and are the same address.
• In Mariana Tek, the documented path is Configuration → Locations → the location → Edit Location → Email → Save.
• For HQ accounts, contact Support to update the profile.

Obtain the location owner’s approval before changing the linked email address. This is not merely a DNS label: it affects customer-facing identity and replies. Confirm that the mailbox still receives replies as intended.

Updated settings apply to new emails going forward. Previously scheduled emails may retain their earlier configuration, so review their sender details separately before release. Do not assume changing the default retroactively fixes every queued campaign.

6. Prove the intended native email path

Start with Growth’s Test Email procedure: open the email draft, complete its required details, select Test Email, choose an existing team member and send the controlled test when authorized. Missing subject or sender details can prevent delivery even when a sent banner appears.

Do not create an unnecessary user account merely to add a test recipient. Use an authorized existing team recipient. A preview can also differ from production personalization: Growth notes that merge tags may not behave normally in test emails. If a production-path check is needed, use an explicitly approved, tiny segment containing only controlled recipients, with no customers or unrelated automations included.

A mailbox-webmail test is not a Growth test. Keep the Growth account, draft, sender domain and intended native campaign route identifiable. If Support says preview mail follows a different authentication route, validate the intended native route before approving production.

Acceptance checklist

Accept the setup only when all applicable checks are satisfied:

• The issued records are visible at the correct authoritative owners.
• Growth Support has confirmed completion for the intended domain/account.
• The chosen address is verified, and the actual message retains the approved visible From address rather than a rewritten provider identity.
• The intended Growth DKIM signature passes and its signing d= domain aligns with that From domain under the applicable adkim mode. Record the actual selector s= too.
• The trusted receiving service reports dmarc=pass for that unchanged From domain.
• The SPF result is understood for the actual smtp.mailfrom, including any failure, temporary DNS error or permanent policy error.
• Replies reach the approved inbox, and the checked scheduled message uses the intended profile.

Use results produced within the receiving service’s known processing boundary, with its documented handling of externally supplied Authentication-Results. A familiar authserv-id string or a header’s position is not proof of origin. If that boundary is unclear, have the receiving administrator identify its own evaluation and ignore untrusted, sender-inserted results. See RFC 8601 section 7.1.

DMARC needs at least one passing, aligned SPF or DKIM path, but an SPF-only DMARC pass does not prove the DKIM setup succeeded. EmailAuth’s raw versus aligned DKIM guide explains why a passing provider-domain signature may still fail the brand’s alignment requirement.

Relaxed alignment permits the relevant Organizational Domain match; strict alignment requires the exact domain match. A child envelope domain may align with the parent From domain in relaxed SPF mode but not strict mode. Growth’s public instructions do not promise a fixed Return-Path or strict alignment, so inspect the actual identities rather than assuming them. See RFC 9989.

DMARC: preserve existing protection

Check both the direct From-domain policy and any applicable inherited policy before adding or changing DMARC. Keep existing enforcement and approved report destinations. Do not downgrade to p=none to accommodate Growth, and do not create a second policy at the same owner.

Only if no direct or applicable inherited policy exists, the domain owner approves, and a monitoring plan is in place, a first monitoring TXT value can be:

v=DMARC1; p=none

That record does not itself request aggregate reports. Add an actual approved rua destination only after deciding who may receive the reports and arranging monitoring.

If the report destination is in a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check DNS authorization for that destination. A destination within the same Organizational Domain is excepted; a different hostname alone is not enough to make it external. Protocol authorization does not replace the owner’s privacy/data-sharing approval. See RFC 9990 section 4.

One successful Growth message does not establish that every other sender can tolerate a stricter policy. Review the complete sender inventory and accumulated evidence before changing enforcement.

Troubleshooting

Rollback and ongoing changes

Keep the pre-change DNS inventory and Support correspondence. If the new route fails acceptance, pause affected sends and coordinate recovery with Growth Support and the domain owner. Restore only changes attributable to this setup after checking other services’ dependencies; do not delete an entire SPF policy, a shared selector or a delegation.

Do not rotate a selector or replace a key by editing DNS alone. Coordinate the signing change and transition with Support so queued messages and other senders retain their required records. When retiring Growth, stop scheduled/automated sends, establish when old traffic no longer needs the records, and remove only the confirmed unused authorizations.

Repeat the relevant checks after a domain, location, sender profile, DNS provider or Support-managed authentication change. Keep inbox replies and existing scheduled messages in that review.

Sources and documentation dates

The current Help Center displays September 30, 2026 on Authenticating your Sending Domain, October 2, 2026 on How to Configure Email Settings, August 19, 2026 on How do I send a test email?, and May 13, 2025 on How can I set up a custom email address?. These are displayed documentation dates, not dates of a customer setup or delivery test.