Start with the product and the domain decision
Webpower's current documentation trail leads to Spotler MailPro. The official rebranding page explicitly identifies MailPro as the continuing Webpower marketing automation product. That connection permits a product-specific guide; it does not make the instructions interchangeable with Spotler Mail+, SendPro or every account that once used the Webpower name. Confirm the actual license and interface before planning implementation.
This article uses public instructions reviewed on 9 November 2026. It concerns selecting an authorized sending identity within MailPro, preparing the corresponding DNS changes and collecting evidence from the real campaign path. No account was inspected and no records or messages were tested. The first decision is whether the visible sender uses a dedicated local domain or the organization's main domain, because those choices have different dependencies.
Separate the local domain from the visible address
MailPro's local-domain explanation describes an organization-owned domain or subdomain supporting technical elements such as links and pages. It distinguishes that role from the sender-domain setting. A main-domain sender can still depend on a separately configured local domain. Identify each name and its owner rather than putting every domain into one “authenticated” column.
The page also uses “Mail-From” terminology. Do not translate that wording directly into a claim about the SMTP envelope emitted by a particular campaign. Record the visible From address, intended reply handling, link domain and actual envelope identity as separate fields. The first three can be reviewed during preparation; the last requires suitable route documentation or a received-message observation. Product labels are not a substitute for protocol evidence.
Choose the appropriate setup branch
For the main-domain branch, the Sender domain instructions require an existing local domain and access to the Setup function. They specify two license-specific DKIM CNAMEs, verification through an address on the chosen domain and a final provider configuration step. These settings affect the license, not just the campaign currently displayed. The verification recipient must have the documented account access.
Treat that breadth as a change-management requirement. List the campaigns using the license, identify their owners and decide when a change can be accepted or reversed. Prepare the exact domain and license-specific targets, but do not send a verification email or request activation without authorization. Additional local-domain provisioning may involve a commercial decision; this article establishes neither entitlement nor price.
Do not apply local-domain records to unrelated infrastructure
The separate Sender addresses page supplies a preferred local-domain record bundle, including A, MX, SPF, DKIM and DMARC examples. That bundle is not a universal prescription for the organization's main domain. An A change can affect website routing; an MX change can affect inbound mail. Establish the purpose of the selected domain and existing dependencies before including either in a change.
The configuration map below distinguishes the documented branches. Its DKIM destinations contain the actual license name, which must come from the intended account. A placeholder, another customer's value or an old selector from an unrelated tutorial cannot establish that relationship. Under RFC 6376, section 3.6, verification uses the selector and signing domain to retrieve public key material; a DNS alias alone does not prove that an outgoing message was signed.
Evaluate SPF and DMARC at the correct identities
Before proposing an SPF edit, determine which domain's policy the outgoing route actually evaluates. SPF normally concerns the SMTP MAIL FROM identity, not whichever address a mail client prominently displays. If a change is needed, preserve legitimate existing authorization and evaluate the combined policy's DNS-querying terms. RFC 7208, sections 2.4 and 4.6.4 supplies the protocol basis. Do not publish another independent SPF policy at the same name.
Assess DMARC separately. Its authentication result depends on a passing SPF or DKIM path that aligns with the visible From domain, as defined in RFC 9989, section 4.4. Both mechanisms need not pass for that result. A policy example is not authority to replace existing enforcement, and adding a policy without an appropriate report destination does not automatically create a reporting process. Keep disposition, alignment and reporting decisions distinct.
The provider's 24-hour DKIM TTL recommendation is a documented setting preference, not a promise that every resolver or mailbox provider will behave identically. Nor does waiting a day prove successful authentication. Preserve existing policy and DNS evidence, obtain approvals for the specific differences, and verify outcomes instead of treating elapsed time as acceptance.
Collect a campaign-specific acceptance record
An acceptance table should identify the license, selected Sender address, campaign workflow, time, receiving system and evidence location. Add the observed From domain, envelope identity, all DKIM d= and s= values, trusted authentication results and the alignment conclusion. Keep unobserved cells explicitly empty or marked “not collected.” A preview screenshot cannot fill a message-header field.
Consider a fictional invitation from events@harbor.example. A receiver-verified signature with d=harbor.example supplies an exact aligned DKIM identity. A link pointing at mail.harbor.example proves nothing about that signature. Similarly, merely seeing a wps selector in a header does not prove that its cryptographic verification passed. These examples illustrate the decision rule only; they are not captured Webpower traffic.
After an approved change and the required provider handoff, inspect a controlled message from the selected workflow. Establish which receiver produced the authentication assessment, rather than trusting an assertion inserted by an upstream sender. RFC 8601, section 7.1 explains that trust boundary. Keep unexpected results and diagnostics with the case, and avoid extending one campaign's conclusion to every license workflow.
Preserve the unfinished evidence requirement
The exact catalogue requirement is: Current Webpower first-party setup evidence and a received-message identity table from the exact product and route.
The current product and documentary workflow are supported. The original identity table, account applicability, provider activation and authorized operational verification are not complete. Recovery planning must cover affected campaigns and any changed routing or trust, with dependencies checked before old records are retired. Independent technical review, site presentation, owner acceptance and publication approval remain open. Nothing here certifies delivery or a completed deployment.