Scope the current SendPro domain model
This guide uses the current Spotler SendPro Help Center workflow for the catalogue entry associated with SendPro and Flowmailer. It does not assume that every older interface, integration or account exposes identical controls. Record the account, edition, source application and sender domains before preparing a change.
The Domains guide separates three identities: the sender domain associated with the author address, the return-path domain used for bounce handling, and the web domain used for click tracking. A source application commonly determines the sender, while a dedicated flow step can change it. The configuration review must therefore include the processing flow rather than assuming the original application's From address survives unchanged.
No account, API credential, flow or DNS setting has been accessed or changed for this manuscript. Its implementation and current-applicability requirements remain open. Domains
Choose the return-path and tracking layout before copying records
The provider describes a standard setup in which the web domain initially uses the same name as the return-path domain. It also supports separating them. In the separate-domain scenario, the guide calls for MX and SPF at the return-path domain and a separate CNAME for the web domain. An inbox-domain source introduces another receiving-mail dependency.
These alternatives explain why a screenshot of three aliases is not a universal record list. Obtain the generated plan for the selected layout and record the purpose of each owner name. Do not configure an inbox domain merely to reproduce an example, and do not overwrite existing mail routing when a name already serves another system.
The guide states a strict-alignment constraint for its return-path configuration. Treat that as a provider-specific design condition requiring clarification against the account's actual policy. Do not generalize it into a claim that the DMARC protocol always forbids strict alignment or silently remove strict tags from a shared domain. Return-path domain; Different setups
Distinguish Validate from Save
The Domains guide makes an important distinction between previewing and committing changes. Validate checks the current input values and can show the records that would be required for edited values without saving those edits. Save changes the configured domain values and updates the required records and status.
The proposed operational process is to prepare and review the layout before approving a saved change. Record whether a screenshot reflects a preview or the committed configuration. A preview showing expected records does not establish that the account currently uses them. Likewise, a saved change does not prove that DNS has already been updated.
The provider warns that production domain changes can affect incoming and outgoing email. Preserve a before-state, identify active sources and flows, and agree a rollback owner. Domain removal also has lifecycle consequences and should be reviewed separately from a routine status check. This manuscript performs none of those actions. Editing, saving, validating and removing domains
Read the essential-record and DMARC indicators accurately
The compliance guide directs users to Setup > Domains. For its illustrated standard layout, it describes three CNAMEs: one for bounce handling and tracking, and two for DKIM. Use the current account-generated records rather than assuming those exact counts cover every alternative layout.
The guide requires a valid DMARC record for sending, but distinguishes a missing valid policy from a warning that rua does not contain the SendPro reporting address. It says the latter can be sufficient, while recommending reporting integration. Do not treat a recommendation to share reports as automatic permission to add a new data recipient. Preserve the existing reporting arrangement unless the domain owner approves a change.
A suggested DMARC record is a policy example, not a mandatory replacement for the organization's current configuration. Review the applicable domain policy and alignment requirements before accepting it. Recheck the specific sender domain after approved publication; one successful domain does not establish every other domain or subdomain. Sender-domain compliance guidance
Keep SPF and source submission separate from domain identity
The setup guide describes an optional SPF item for manual inspection and visibility and names include:spf.flowmailer.net. That interface description must not be interpreted as permission to ignore an SPF policy required by a different return-path layout. Map the relevant identity and generated records first.
SPF's evaluation limit concerns DNS-dependent terms, including nested processing, rather than simply counting includes typed into the visible record. Review one complete policy at the affected owner name and preserve other legitimate sources. Do not add a second SPF policy to satisfy an isolated dashboard item.
SendPro also supports source submission through API and SMTP, among other options. Source credentials authorize submission; they do not themselves prove domain alignment on the final message. This guide does not create or expose those credentials. The proposed acceptance must connect the chosen source, any sender-changing flow step and the final observed author and signing identities. Setup guide; RFC 7208, section 3.2; RFC 7208, section 4.6.4; RFC 9989, section 4.4
Acceptance worksheet for application and DNS owners
Use this original proposed worksheet to prevent preview state, submission authorization and message authentication from being confused.
- Application scope: account, edition, source application, submission protocol and relevant flow steps.
- Identity layout: sender domain, return-path domain and web domain recorded separately.
- Preview evidence: generated record plan and whether it reflects unsaved inputs or committed settings.
- DNS review: purpose of each alias, TXT or MX record, existing dependencies and approved change owner.
- Policy decision: applicable DMARC alignment, SPF review and separately authorized report recipients.
- Product status: actual per-domain validation result and timestamp after approved publication.
- Message acceptance: minimized authorized sample showing author, envelope and signing identities plus trusted receiver results.
- Lifecycle: active source dependencies, rollback plan and retirement approval for unused domains.
This is a blank control design. It is not a completed API integration, DNS inspection, saved configuration change or test transmission.
Fictional diagnosis: a preview was mistaken for deployment
A fictional application team edits its return-path and web-domain fields, selects Validate and forwards the resulting record list to a reviewer. Another team assumes the preview represents the account's live configuration and marks the migration complete. The saved settings still describe the previous layout.
The proposed correction is to distinguish preview evidence from an approved committed change. The teams reconcile the actual saved configuration, DNS plan and relevant application flow before scheduling any deployment. They also preserve the current DMARC report recipients rather than copying every field from an example.
After a properly authorized change, message-level evidence would still be required. The preview alone cannot prove authentication or delivery. This fictional example describes no executed SendPro action and makes no allegation about a real account.