Webpower SPF, DKIM and DMARC setup, step by step

Webpower's current product is Spotler MailPro. Start by choosing whether messages use a dedicated local domain or your main domain. MailPro documents a local-domain DNS bundle and a separate main-domain Sender domain workflow with two license-specific DKIM CNAMEs, an email verification step and a final Spotler support configuration step. Do not apply the local-domain A and MX records to your organization's main domain. Product continuity, Sender domain setup.

On this page: Identify the route · Local-domain setup · Main-domain setup · Safe DNS and SPF · DMARC · Verification · Troubleshooting · FAQs · Review boundary

Identify your MailPro license and domain route

This is a MailPro guide, not a generic Spotler guide. Mail+, SendPro and MailPro have separate interfaces and authentication procedures. If your account is Mail+, use the Spotler Mail+ authentication guide. If it is SendPro/Flowmailer, use the SendPro guide. Do not select records merely because a product carries the Spotler name.

A MailPro Local Domain is an organization-owned domain or subdomain supporting the technical parts of mailings, such as links, pages and images. The visible sender can use that local domain or a main domain; a main-domain sender still needs an available local domain in the license. MailPro's Local Domain page uses the term “Mail-From” for the sender setting, but that wording alone does not establish the SMTP envelope emitted by your campaigns. Keep the visible From address and actual SMTP MAIL FROM identity in separate fields. Local Domain roles.

Before changing settings, record:

• The MailPro license name. The documentation identifies it in the account URL: LICENSE_NAME.webpower.eu.
• Every campaign and brand using the license, plus the expected sender addresses.
• The dedicated local domain, selected web/link domain and intended visible From domain.
• The authoritative DNS provider for each domain, including any delegated subdomains.
• The current SPF, DKIM, DMARC, A and MX records, with owners and TTLs.
• Who controls the verification mailbox, who can use Setup → Sender domain, and who approves changes.

Sender domain settings affect the entire license, not only the campaign currently open. Schedule changes accordingly. Adding a local domain can involve costs; confirm availability and entitlement with your account manager rather than assuming DNS publication provisions it. License-wide scope and prerequisites.

Configure the local-domain route

Choose a domain or subdomain specifically assigned to this MailPro use. If it is absent from the license, involve your account manager or Spotler support to add and configure it. A public DNS record cannot make an unprovisioned domain appear in your account. Local Domain provisioning.

MailPro publishes the following preferred settings for its local-domain route. LOCAL_DOMAIN and LICENSE_NAME below are placeholders. Replace them with the actual domain and license confirmed for your account, and reconcile the complete bundle with current provisioning instructions before publishing. MailPro Sender addresses and DNS settings.

For this dedicated local-domain branch only, obtain the routing owner’s separate approval of the exact full-owner A address set and complete MX numeric-priority/target set before publication or activation. Reconcile the provisioning packet with the approved website and inbound-mail design; receiving it does not approve its consequences. Stop on unapproved destinations or mismatches. Use the complete authoritative and recursive comparisons below; do not apply the bundle to the main-domain branch.

The source recommends 86400 seconds (24 hours) for these DKIM CNAMEs. Treat that as a provider setting recommendation, not proof of authentication or a guarantee against false positives. Cache behavior, key activation and message handling still require verification.

The provider also gives a DMARC sample with p=reject and a reporting mailbox. Do not copy that policy or invent its mailbox. Retain the policy already applying to your From domain and follow the DMARC checks below. A local-domain setup is not authority to alter organizational enforcement.

Once the domain is provisioned, open Setup → Sender Addresses → Insert, choose the intended domain and create the sender address. The Sender Addresses list identifies the visible From addresses. If choosing My own sender address, the screen offers an SPF check; inspect the exact domain and policy it checks, then verify the actual envelope identity in a delivered message. Sender-address selection.

Configure a main-domain sender

A main-domain sender requires access to the Sender domain function and an existing local domain in the license that can be associated with it. Changing this configuration affects campaigns across that license. Do not begin by replacing your main domain's A, MX or SPF records with the local-domain bundle.

1. Publish the main-domain DKIM aliases

For the intended visible sender domain, MailPro documents these two CNAME patterns:

wps1._domainkey.SENDER_DOMAIN CNAME wps1._domainkey.LICENSE_NAME.webpower.eu.
wps2._domainkey.SENDER_DOMAIN CNAME wps2._domainkey.LICENSE_NAME.webpower.eu.

Replace both placeholders. Check the license name against the actual account and preserve both selectors even if only one appears in the first test message. A quiet selector can be needed for rotation; absence from one message is not evidence that it should be deleted. Main-domain records.

The main-domain procedure specifies DKIM CNAMEs; it does not instruct you to move the main domain's website or inbound mail to the local-domain A/MX targets. Its relationship to SPF must be established from the actual outgoing envelope, rather than guessed from a branded From address.

2. Add and verify the Sender domain

In Setup → Sender domain, select Insert and complete:

• Domain: the exact sender domain, without an address or URL.
• Email address: a mailbox on that same domain. Its recipient must be able to log into this MailPro license and access the Sender domain module.
• Web domain: an available web/local domain for message links and pages. If omitted, MailPro uses the license's primary web domain.

Select Add domain and send verification mail. The entry initially shows pending validation. The authorized mailbox owner follows the verification email to confirm use of the domain. A valid DNS record does not replace this mailbox/account-access step. Verification fields and sequence.

3. Complete the Spotler handoff

After verification makes the domain available in the license, the documented final step is to ask Spotler to add it to the configuration. The Sender domain page specifies support+mailpro@spotler.nl for this handoff. Give support the correct license and domain through your approved support process and retain their completion confirmation. This guide does not send that request or claim that a validated row is fully activated. Required provider completion.

Then select/create the intended address under Setup → Sender Addresses, and confirm which address the campaign actually uses. Keep verification, provider configuration and message acceptance as separate checks.

Publish DNS without breaking other mail

Put records in the zone that answers publicly

A registrar is not necessarily your authoritative DNS host. Identify the zone serving each record. If mail.example.com or _domainkey.example.com is delegated, its records belong at that delegation's authoritative provider. Do not publish an ineffective copy in the parent zone or remove an existing delegation as a shortcut.

DNS editors differ on owner names. In the example.com zone, wps1._domainkey.mail may produce the full owner wps1._domainkey.mail.example.com. In a delegated mail.example.com zone, the relative name is normally wps1._domainkey. Confirm the actual resulting full owner so the domain is not appended twice.

For existing delegated _domainkey.mail.example.com authority, full owner wps1._domainkey.mail.example.com maps to relative wps1; map wps2 likewise. Preserve its NS delegation and other selectors, and use the correct license-specific targets. Relative DNS names.

A CNAME owner cannot also hold ordinary TXT, A or a conflicting CNAME record. Resolve collisions with the existing service owner before changing it. Publish the complete license-specific target, not the target from a different MailPro account, and never publish private signing material. DNS aliases, DKIM key lookup.

If your DNS host supports HTTP proxying or CNAME flattening, make sure the authentication aliases remain visible as CNAMEs. For Cloudflare, use DNS-only, disable per-record flattening and check zone-wide flattening, which can override individual settings. Do not change a shared zone-wide option without coordinating with its owner. A delegated zone must be corrected at its actual authority. Cloudflare CNAME verification, flattening controls.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Evaluate SPF for the envelope domain

SPF normally evaluates SMTP MAIL FROM, shown by the receiving server as smtp.mailfrom and usually reflected in Return-Path. It does not authenticate the visible From or a tracking-link domain. For an empty reverse-path SPF uses HELO, but current DMARC's SPF identifier is the MAIL FROM identity. SPF identity, DMARC SPF identity.

For the local-domain route, the documented a, mx and include:virtualmail.webpower.eu mechanisms depend on the corresponding domain infrastructure. Do not transplant them onto a different domain simply to make a checker green. For a main-domain sender, confirm which envelope MailPro emits and ask support for any required customer-managed SPF arrangement. Do not invent a custom-return-path setting or assume the visible main domain needs the local-domain policy.

At every SPF owner, maintain one policy, preserving all authorized services and the approved final qualifier when merging. An SPF policy at example.com does not cover mail.example.com; SPF does not inherit. Multiple TXT strings within one DNS resource record can form one policy, but two distinct SPF records at the same owner cause permerror.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

The combined evaluation path may use at most ten DNS-querying terms from include, a, mx, ptr, exists and redirect, including nested dependencies. It is not a count of just the mechanisms visible in your top-level record. ip4, ip6 and all do not count toward that limit; additional address-query limits and the recommended two-void-lookup limit apply. MailPro's a and mx terms count too. SPF limits.

Check DMARC alignment and reporting

DMARC protects the domain in the visible From address. A message passes if either SPF passes with an aligned MAIL FROM domain or DKIM passes with an aligned signing domain. Both are useful, but both are not required for a protocol-level DMARC pass. Relaxed alignment compares Organizational Domains; strict adkim=s or aspf=s requires an exact domain match for the relevant mechanism. A branded URL or an unverified DKIM-Signature header is not proof of alignment. Current DMARC specification.

Inspect the policy for the actual From domain and the policy discovered through the RFC 9989 DNS tree walk. A main-domain policy can apply to subdomains; a missing record at _dmarc.mail.example.com is not, by itself, permission to create a conflicting one. Preserve any established enforcement, reporting and alignment settings.

For a domain without an applicable policy, the owner can begin with an approved monitoring policy and working aggregate-report destination. This is an illustrative record at _dmarc.example.com, not a MailPro-issued value:

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. Publish the example as TXT only after confirming no direct or applicable inherited policy exists and obtaining the domain owner’s approval of the monitoring and review plan.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Create and monitor the mailbox before using it. p=none alone does not request reports; rua and recipient readiness are separate. With an external report destination, its operator normally publishes authorization such as example.com._report._dmarc.reports.example.net for reports from example.com to reports.example.net. Follow the reporting service's exact instructions and privacy terms instead of copying a fictional address or adding failure reports by default. Aggregate reporting.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

RFC 9989 removed pct; do not rely on it for percentage-based enforcement. Consider every legitimate sender, forwarding route and mailing list before tightening policy. MailPro configuration alone does not certify a shared main domain for stronger enforcement.

Verify DNS and a real MailPro message

Check public records first

These commands are examples for the administrator to run after authorized changes. Replace every uppercase placeholder. AUTHORITATIVE_NS must serve the particular owner's zone; the DKIM zone may be delegated separately.

dig +short NS AUTHORITATIVE_ZONE
dig @AUTHORITATIVE_NS wps1._domainkey.SENDER_DOMAIN CNAME +noall +answer
dig @AUTHORITATIVE_NS wps2._domainkey.SENDER_DOMAIN CNAME +noall +answer
dig +short TXT wps1._domainkey.LICENSE_NAME.webpower.eu
dig +short TXT wps2._domainkey.LICENSE_NAME.webpower.eu
dig +short TXT ACTUAL_ENVELOPE_DOMAIN
dig +short TXT _dmarc.ACTUAL_FROM_DOMAIN

Both CNAME answers should match the correct license-specific targets. Follow the targets to their public DKIM keys. Compare authoritative and recursive answers when caches disagree; waiting a fixed number of hours is not acceptance. For the dedicated local-domain branch only, identify that domain's authoritative server and run both authoritative and recursive routing checks. LOCAL_DOMAIN is the provisioned local domain, not the main-domain sender:

dig @LOCAL_AUTHORITATIVE_NS LOCAL_DOMAIN A +noall +answer
dig @LOCAL_AUTHORITATIVE_NS LOCAL_DOMAIN MX +noall +answer
dig LOCAL_DOMAIN A +noall +answer
dig LOCAL_DOMAIN MX +noall +answer

Compare the entire returned A address set with the approved current provisioning bundle, not merely whether an address appears. MailPro's documented bundle has 91.197.72.25. Likewise compare the complete MX priority-and-target set, including each numeric priority; the documented bundle is priority 10 with virtualmail.webpower.eu. Require agreement between the authoritative and recursive answers after relevant cache expiry, and resolve unexpected, missing or additional records with the domain owner. If current account provisioning specifies a different approved set, reconcile it with Spotler rather than deleting records to force the sample. Protect the local domain's agreed website and inbound-mail design. These A/MX requirements do not apply to the main-domain Sender domain branch, and they are not authority to replace corporate routing.

Check that the selected domain is provisioned, verification is complete where required and Spotler has completed the main-domain configuration. For SPF, inspect the actual envelope owner's policy and evaluation, not just a lookup of the From domain.

Test the intended campaign path

After setup approval, send a controlled campaign message with synthetic content to an approved external test mailbox. Include an internal mailbox if internal delivery is important. Do not use a screenshot preview as a substitute for a delivered message. Test each significant campaign/brand route using this license, especially when sender choices differ.

Obtain the original message and trusted receiving-system authentication results. A familiar authserv-id or header position alone is insufficient. Use a receiver-controlled diagnostic or administrator-established provenance, including confirmation of how the receiver strips or distinguishes external Authentication-Results. An upstream sender can insert a misleading result; only evidence from inside the receiver's trusted boundary is acceptable. Receiver-result provenance.

Retain this acceptance record:

A provider-domain SPF pass can be valid but unaligned. DMARC can still pass through branded DKIM. If DMARC passes only through SPF while the intended branded DKIM is missing or failing, do not accept the DKIM change as complete. Likewise, do not ignore SPF permerror or temperror because DKIM supplied the DMARC pass.

Require the intended active MailPro signature matching the configured d= and s= to pass and align under effective adkim with the unchanged approved visible From, plus trusted receiver dmarc=pass. A rewritten provider From or another aligned signer does not complete this branded DKIM deployment. DMARC alignment.

Authentication success is not an inbox-placement guarantee. Keep the measured result limited to the campaigns, identities and receivers actually tested, and review later aggregate reports for other legitimate traffic.

Troubleshooting and recovery

Keep a before-and-after DNS diff, the license-wide campaign inventory, verification state, support confirmation and test headers. If a regression follows a change, pause affected sends and coordinate rollback with the license and DNS owners. Reverting a CNAME alone may not revert provider-side configuration. Keep selectors needed for queued messages or rotation until Spotler confirms safe retirement.

Obtain the license owner’s explicit approval before pausing affected sends or initiating rollback; coordinate the approved change with the DNS owner. This is not permission to stop unrelated campaigns or change the conditional local-domain routing design.

When opening a support case, include the license, domain branch, selected sender, expected public records, authoritative answers and redacted trusted receiver results. Do not include credentials or private keys.

Documentation review and testing boundary

No MailPro account was changed, verification email sent, support request submitted, DNS record modified or delivery test performed. The checks here describe what the implementing administrator should verify; they do not claim a live account already passes.