On this page: Scope: current SendPro, not every Spotler product · Prerequisites and the three-domain worksheet · Obtain the actual DKIM and return-path records · Understand SPF and the alignment constraint · Validate, save, then validate the saved configuration · Read the DMARC indicators without weakening policy · Acceptance: public DNS plus a real received message · Troubleshooting and frequently asked questions · Review boundary
Authenticate Spotler SendPro, formerly Flowmailer, using the sender-domain wizard's account-generated DNS records. Keep the visible sender, return-path and tracking domains distinct; publish the issued CNAMEs; save the intended configuration; then revalidate and inspect a delivered message. A successful Validate preview does not save edited domain settings. SendPro DNS setup, domain controls.
Scope: current SendPro, not every Spotler product
Spotler confirms that Flowmailer's platform is now Spotler SendPro. This guide covers the current SendPro sender-domain model. It is not a Mail+, MailPro, CRM, Activate or blanket Spotler authentication recipe. Nor does a current help article prove that every legacy account presents identical controls. Official product continuity.
Record the account, edition, source application, protocol and actual visible From domain. Basic accounts have default SMTP and API sources; Premium supports creation of additional sources. Admin access is required for source setup. The source documentation also retains a SendPro Go! reference within its detailed API instructions, so confirm legacy-account entitlements in the account instead of translating plan names by guesswork. Sources & API.
Source credentials grant application access. They do not prove domain authentication. Keep credentials separate from the public DNS worksheet and never put passwords in DNS records or troubleshooting screenshots.
If an application can also send directly through Google Workspace, test that separate path using the Google Workspace SMTP relay guide. SendPro domain validation does not certify a bypass route.
Prerequisites and the three-domain worksheet
Arrange access to the SendPro domain settings, permission to publish DNS, and a controlled receiving mailbox. Export the existing DNS values and applicable DMARC policy. List other senders and any existing selectors or bounce hostnames that could conflict.
Build a worksheet before choosing names:
- Sender domain: the visible From identity after any configured sender-changing processing.
- Return-path domain: the bounce/envelope identity relevant to SPF alignment.
- Web domain: the hostname used for tracking links when tracking is enabled.
The current Domains page allows different return-path/web arrangements and says those choices change the generated records. A sender flowstep can also change the sender identity. Do not assume the source application's original From is the one that leaves SendPro. Current domain model.
For each row, record the intended full name, DNS zone, existing occupants and change owner. Reject a hostname collision before saving. Keep inbound MX routing unchanged unless a separate, deliberately scoped inbox-domain implementation requires it.
Obtain the actual DKIM and return-path records
Open the intended sender under Setup → Domains and use the account's setup workflow. The DNS guide describes essential CNAMEs with values generated from account and domain information. Copy every issued name, type and target; do not derive targets from another account ID or a screenshot. Account-generated records.
The standard compliance walkthrough shows three CNAMEs: one for bounce handling/tracking and two for DKIM. Its required count is a description of that arrangement, not permission to omit extra or alternative records generated for a different setup. Publish both issued DKIM records, even if one selector appears in the first test message. DKIM and DMARC compliance walkthrough.
Some domain layouts generate MX records for a separate return-path/web domain or an inbox domain. If your issued arrangement includes MX or another routing change, compare every full owner, type, priority and target with the mail-routing owner’s separately approved plan before publication, saving or activation. A generated DNS packet is not approval to redirect mail. Preserve existing root-domain mailbox routes and do not copy routing values from a standard-layout screenshot. Domain layouts and generated routing records.
Set up parent and child sender domains separately in SendPro: using both example.com and mail.example.com requires DKIM setup for each, even where the parent DMARC policy applies. Subdomain setup requirement.
Only public keys or public DNS targets belong in DNS. Signing secrets stay with the signing system. Preserve unrelated DKIM selectors. If a required CNAME owner already has TXT, MX or other ordinary data, stop and resolve the layout instead of deleting the older service's record. A CNAME cannot coexist with ordinary other records at that owner. DNS alias constraints.
For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.
Watch the DNS editor's suffix behavior. The account may display a full hostname while the DNS provider expects a relative name. Verify the final public owner rather than accepting an accidental example.com.example.com suffix. Targets are hostnames, not web URLs. Use the account-issued values, never the placeholders in this article.
For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.
Understand SPF and the alignment constraint
SendPro's SPF help page specifies include:spf.flowmailer.net, while the DNS wizard guide classifies the sender-domain SPF addition as optional. First determine the actual envelope domain and its generated DNS arrangement; an optional visible-sender SPF indication is not a substitute for authenticating the return path. The SPF help page also uses inconsistent language about a green status and web.flowmailer.net. Do not turn that hostname into an invented include or override the account's issued records. SPF help.
If an SPF edit is needed at a customer-controlled TXT owner, merge the supported authorization into its single existing policy. Do not create a second SPF record, append TXT beside a CNAME, replace other senders or loosen the existing ending solely to clear a UI warning. SPF uses the exact MAIL FROM domain and does not inherit a parent SPF policy. Its limit is ten evaluated DNS-querying terms, including nested include, a, mx, ptr, exists and redirect, not ten visible includes. ip4, ip6 and all do not consume that term budget. SPF specification.
If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.
The Domains documentation warns that the return-path model cannot use strict alignment. Treat an existing strict-policy domain as a compatibility question for SendPro support, not an instruction to remove aspf=s or adkim=s. At the protocol level, relaxed SPF alignment allows the same organizational domain, while strict alignment requires an exact match. Aligned DKIM can satisfy DMARC independently, but its presence does not establish that SendPro supports your intended strict-policy configuration. Resolve that before release. SendPro domain constraint, DMARC alignment.
Validate, save, then validate the saved configuration
Use Validate to inspect current inputs; after editing, it can preview the required records without applying those edits. Save commits the changed domains. Reopen the saved configuration and validate again after publication. Production-domain changes need care because existing mail routes may depend on the prior arrangement. Validate versus Save.
Make this an explicit handoff between the application and DNS owners:
- Capture the currently saved domain layout and DNS values.
- Agree the intended layout and inspect the proposed records.
- Resolve conflicts and arrange the deployment sequence with the responsible operator.
- Complete both the approved DNS publication and the intended account save.
- Reopen the configuration to confirm the saved names, validate, and test delivery.
The example is a change-control checklist, not a claim that these actions have been performed. If a preview is green but the saved page differs, the new configuration has not passed this handoff.
Read the DMARC indicators without weakening policy
The compliance page requires sender-domain DKIM and DMARC. It distinguishes missing/invalid records from a yellow reporting indicator: absence of SendPro's address from rua can still be sufficient. Adding that destination enables SendPro's reporting visibility; it is not a prerequisite to make a passing aligned message authentic. Compliance indicators.
Keep the existing policy and approved report recipients. Do not overwrite enforcement with a sample, create a duplicate DMARC record or weaken strict settings to make all icons green. If no applicable policy exists, consider a monitored p=none policy before enforcement. Check parent-policy effects as well as the exact From-domain record. Current RFC 9989 removes pct; do not plan percentage-based enforcement using that old tag. DMARC needs at least one passing aligned mechanism, SPF or DKIM. Current DMARC.
Approve any additional report recipient and satisfy external-destination authorization where necessary. Aggregate reporting, RFC 9990. Do not add failure-report destinations casually, since reports may disclose content and personal data. Failure reporting, RFC 9991.
Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.
Publish a first DMARC policy only when appropriate
First inspect the applicable exact-domain and inherited policies. Only if there is no existing or inherited protective policy, and the domain owner approves a monitored rollout, create a TXT record at _dmarc beneath the visible From domain with the minimal value v=DMARC1; p=none. For From addresses at example.com, the full owner is _dmarc.example.com; for From addresses at news.example.com, it is _dmarc.news.example.com. In the example.com DNS zone, relative-name fields take _dmarc and _dmarc.news respectively. A separately delegated news.example.com zone instead takes _dmarc. Confirm how your DNS editor handles names before saving.
These are illustrative names, not records to publish unchanged. Maintain one DMARC policy at the intended owner: edit the existing record after review rather than adding a duplicate or overriding a protective inherited policy with p=none. A minimal policy requests no aggregate reports. If monitoring is approved, append ; rua=mailto:AGGREGATE_REPORT_ADDRESS only after replacing the placeholder with a provisioned, authorized report address. Have an external reporting service establish the required destination authorization. External report authorization, RFC 9990 section 4.
Acceptance: public DNS plus a real received message
Replace the uppercase placeholders below with issued or observed values. These read-only queries have not been run against a customer domain for this guide:
dig +short CNAME DKIM_OWNER_ONE_FQDN
dig +short CNAME DKIM_OWNER_TWO_FQDN
dig +short TXT DKIM_TARGET_FQDN
dig +short CNAME RETURN_PATH_OWNER_FQDN
dig +short TXT ENVELOPE_DOMAIN
dig +short TXT _dmarc.FROM_DOMAIN
Expect each CNAME to match the account's target, DKIM resolution to lead to the public key, and the envelope lookup to follow the intended SPF arrangement. If answers differ across resolvers, check authoritative publication, delegation and TTLs. A blank answer can indicate a wrong owner or zone, not just propagation delay. Recheck saved SendPro status afterward.
If the saved layout issues MX records, query MX at each exact full owner against both its authoritative nameserver and a recursive resolver. Compare the complete returned set of numeric priorities and target hostnames with the separately approved routing plan before accepting the saved configuration. Any nonempty MX answer is not enough: extra, missing or different entries need resolution. Preserve root-domain mailbox routes while validating the designated return-path or inbox owner. Issued domain layouts.
Next, an authorized operator should send non-sensitive test mail through each intended SMTP/API source and any distinct resending or inbox-derived route. Source-level restrictions and processing can change the result; a shared sender domain alone is not sufficient coverage. The source documentation identifies a system source used for copies and resends, so include those streams when your application depends on them. Source distinctions.
In the original received message, read the trusted receiving server's Authentication-Results. Record the visible From, smtp.mailfrom, SPF result, DKIM header.d, selector s=, DKIM result and DMARC header.from/result. Accept when the identities match the saved design and dmarc=pass follows from aligned authentication. Reject a result that only shows a signature exists or a provider status is green. Test direct delivery first; forwarding and later content changes need separate diagnosis. Authentication does not guarantee an inbox placement.
Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.
Complete this branded-DKIM setup only when the intended provider signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. DMARC success through SPF alone does not establish that this DKIM deployment works; neither does an unnoticed provider-domain From rewrite. Diagnose SPF independently at the actual smtp.mailfrom: fail or softfail calls for checking sender authorization, temperror indicates a transient evaluation failure such as DNS availability, and permerror calls for checking invalid syntax, duplicate policies and lookup limits. Investigate these even if aligned DKIM supplies DMARC pass; a passing but unaligned provider envelope is a different outcome. DMARC alignment, SPF result meanings.
Troubleshooting and frequently asked questions
Why did Validate succeed but the message use the old domain?
You may have validated edited fields without saving. Compare the reopened configuration with your intended layout, then inspect any sender flowstep and the actual outgoing From. Do not change DNS again until the intended saved state is established.
If the final From still differs, inspect any existing fallback sender under Setup → Settings. The documented fallback needs a valid-DMARC sender domain and may replace an original sender that fails DMARC. Review this independently of sender flowsteps; do not enable fallback automatically to hide an unresolved authentication problem. Fallback sender behavior.
Why are three CNAMEs not enough for my setup?
Three is the standard compliance example. Different return-path, web or inbox-domain arrangements can generate different requirements. Follow the actual account's issued record set.
Does the yellow SendPro reporting check mean DMARC failed?
Not necessarily. The documented missing-SendPro-rua indicator can be acceptable. Look separately at the published policy and the trusted receiver's DMARC verdict.
Should I remove strict alignment to use SendPro?
Not as a routine fix. Preserve your policy and ask support to confirm a supported layout and the intended DKIM/return-path behavior. Hold the affected route until both platform compatibility and receiver results are established.
Why does SPF pass but DMARC fail?
The authenticated envelope may not align with the visible From, and DKIM may also be unaligned or failing. Compare the actual identities, including any sender-changing flowstep, rather than adding includes at unrelated names.
Does this guide apply to all former Flowmailer integrations?
It covers the current SendPro domain model. Confirm legacy plans, source types and account controls before migrating a working integration. It is not authentication guidance for every Spotler product.
Review boundary
No account, DNS or delivery operation was performed. Legacy entitlements and strict-policy compatibility require account-specific confirmation. Complete the saved-configuration and receiver checks before production release. Successful authentication does not guarantee inbox placement.