Spotler SPF, DKIM and DMARC setup, step by step

On this page: Start with Mail+, not a generic Spotler record · Confirm the reply address and account relationship · Read the domain status before requesting new records · Publish the issued SPF and DKIM records · Retain DMARC protection and useful reporting · Verify DNS, activation and the actual sending route · Troubleshooting and frequently asked questions · Documentation review and testing boundary

For Spotler Mail+, add and confirm a reply address, open Settings → Security → Deliverability, and use the reply domain's Request DMARC Authentication workflow to obtain its DNS instructions. Publish the issued SPF and DKIM configuration without overwriting existing senders, retain the correct DMARC policy, and check both the Mail+ status and a real delivered message. Mail+ authentication instructions.

Start with Mail+, not a generic Spotler record

Spotler operates several products with different setup workflows. This article covers Mail+. It does not apply SendPro, MailPro, Copernica or a legacy CommuniGator account's settings to Mail+ merely because the services share a corporate relationship or a similar name. The Mail+ Help Center links to separate product help centers, including MailPro and SendPro. Mail+ product documentation.

If you actually use Flowmailer, now SendPro, follow the separate Spotler SendPro/Flowmailer authentication guide. A SendPro CNAME recipe is not a shortcut for the Mail+ instruction email.

Write down your exact Mail+ account, intended visible From domain, reply addresses, campaign-link domain and expected return-path domain. These are separate identities even when some use the same name. Record whether this is a standalone account or a franchise/corporate main account with subaccounts.

Confirm the reply address and account relationship

In Mail+, open the account settings and choose Security → Deliverability. Use New reply address, enter the intended address and confirm the email delivered to that mailbox. The address initially remains inactive; confirmation changes its state to Activated. A newly introduced reply domain appears in the domain list. Reply-address prerequisite.

Use a mailbox your organization controls. Reply-address confirmation proves mailbox access; it does not prove SPF, DKIM or DMARC. Arrange a DNS administrator and preserve the current DNS zone before requesting changes.

There is an important account-hierarchy change: the October 2026 release says franchise and corporate main accounts configure DMARC once, and existing and new subaccounts inherit those settings. Check the main account's Deliverability settings rather than creating competing setups in each subaccount. This documented inheritance is specific to that hierarchy, not a promise that every unrelated Mail+ account shares authentication. October 2026 release notes.

For the same domain used in otherwise separate Mail+ accounts, the setup documentation directs you to configure one account and coordinate with support. Retain the account relationship in your change notes and test actual sends from every relevant route. Multiple-account guidance.

Read the domain status before requesting new records

The domain's DMARC column distinguishes these states:

An application warning does not authorize deleting an established corporate DMARC policy. Likewise, an Active status is not proof that every account, From identity and delivered message is correct.

To request records, use the domain's context menu in Deliverability and choose Request DMARC Authentication. Select the supported DKIM key format; Mail+ recommends 2048-bit. Confirm the instruction-recipient email address in the dialog, then click OK to submit the request. The requesting user receives the instruction email. Implement its exact records, then return to Deliverability to check activation. Current workflow.

Do not regenerate keys because an email is slow to arrive. First check the requesting mailbox and account/domain selection. If a different key size is needed, involve support in a controlled replacement instead of deleting a live authentication setup. Keep the previous key while its traffic may still need verification, following the provider's rotation plan.

Publish the issued SPF and DKIM records

The public Mail+ setup page directs the DNS administrator to the instruction email for the actual SPF and DKIM details. There is no basis here for choosing one universal selector, target or key for all accounts. Treat the complete issued owner, type and value as a set, and confirm it belongs to the intended domain and account.

If the actual instruction packet includes an MX record, treat that as a separate routing decision. The official DNS-check illustration includes MX, but its example destination is not authorization for your domain. Obtain the routing owner’s approval for the exact full owner and complete priority/target MX set before publication; preserve corporate mailbox routes. Query that owner at its authoritative nameservers and recursive resolvers and compare every tuple with the approved plan. Stop for any extra, missing or different MX tuple; a nonempty answer alone is not acceptance. Mail+ instruction-page context.

SPF: use the evaluated envelope domain

SPF normally evaluates the SMTP MAIL FROM domain, represented in a delivered message by Return-Path and the receiver's smtp.mailfrom result. It does not evaluate Reply-To or the visible From address simply because the application calls a domain a “reply domain.” For mail with an empty reverse-path, the HELO identity is used. SPF identities.

Before publishing an SPF change, determine the exact owner required by the issued Mail+ instructions. If the real return path is provider-owned, an SPF pass there can be valid but unaligned with your From domain. Adding an include at your corporate domain does not change that identity. If Mail+ supplies a branded envelope arrangement, use its precise records and confirm it is actually selected when sending. Do not invent a custom-return-path control that the public workflow does not document.

Keep only one selected SPF TXT policy at each owner. Merge the approved authorization into an existing policy, preserving other services and the existing final qualifier. SPF is not inherited: a TXT record at example.com does not provide SPF for bounce.example.com.

Use this as a schematic merge only. ISSUED_INCLUDE_DOMAIN is a placeholder, not a literal Mail+ value, and the IP is reserved for documentation:

Before: v=spf1 ip4:192.0.2.25 ~all
After: v=spf1 ip4:192.0.2.25 include:ISSUED_INCLUDE_DOMAIN ~all

Use the actual instructions if they specify a different mechanism or a delegated record design. Do not add TXT beside a CNAME. Check the full nested SPF evaluation against the ten DNS-querying-term limit; the number of visible includes alone is insufficient. An existing redirect= policy also needs deliberate reconciliation. SPF multiple-record and lookup rules, evaluation limits.

An SPF all mechanism causes redirect to be ignored wherever it appears in that policy. Preserve the legitimate senders authorized through an existing redirect and the approved terminal semantics in a reviewed combined policy; do not append all and silently discard that authorization. SPF precedence.

DKIM: publish the supplied public record, not a key pair

Use Mail+'s issued selector and signing domain. Public TXT key data or a supplied public CNAME target belongs in DNS; a private signing key does not. Do not publish both a TXT key and CNAME at the same owner, and do not remove another sender's selector.

For TXT keys, preserve one logical record even if the DNS host splits a long value into quoted character strings. The strings concatenate without inserted spaces. A display split is different from separate TXT records with conflicting keys. DKIM key lookup and storage.

These examples show how to map an issued owner into the correct DNS zone. None is a reusable Mail+ selector or target:

If news.example.com is delegated with NS records and managed as its own zone, use ISSUED_SELECTOR._domainkey and _dmarc there. If _domainkey.news.example.com itself is delegated, the selector belongs at ISSUED_SELECTOR in that delegated zone. Editing a dormant parent-zone copy will not change the authoritative answer.

For the apex-domain DMARC example, the full owner _dmarc.example.com is relative host _dmarc in the example.com zone. Preserve current direct and inherited policy rather than creating a child exception just to make Mail+ activate.

Check the final owner generated by the DNS host. Prevent doubled domain suffixes. For a CNAME, use the issued hostname without a web URL scheme and keep it publicly resolvable. An ordinary CNAME cannot share its owner with TXT, MX, A or AAAA records. Do not replace corporate inbound MX or repurpose an occupied tracking hostname. DNS alias constraints.

For an issued Mail+ CNAME hosted in Cloudflare, keep the alias DNS only and unflattened: check both the record's Flatten control and the zone's CNAME flattening for all CNAME records setting. Both flattening settings must be off for the alias to be returned as required. A zone-wide setting can affect other services, so coordinate any change with the DNS owner rather than switching it silently. Check existing NS delegation too; the record must be published at the authoritative provider. Re-query the CNAME after the approved change. Cloudflare's CNAME checks, flattening controls and precedence.

Cloudflare always flattens apex aliases and aliases whose target is in the same zone; same-zone behavior can ignore the selected setting. Per-record controls depend on the plan and cannot be assumed to override mandatory behavior. If an issued alias cannot return the required literal CNAME, stop and coordinate a supported record configuration with the DNS owner and Mail+ support. Do not invent a switch, remove delegation or change unrelated services globally. Mandatory flattening and controls.

Retain DMARC protection and useful reporting

Mail+ requires proper DMARC authentication to send through its platform. That product requirement should not be confused with a delivery guarantee or with a requirement that both SPF and DKIM align in every message. Protocol-level DMARC needs either aligned SPF pass or aligned DKIM pass. Mail+ requirement, DMARC alignment.

With relaxed alignment, the authenticated domain and visible From domain share an organizational domain. With strict alignment, they must match exactly. For example, bounce.example.com can align with example.com under relaxed SPF alignment but not aspf=s. DKIM has its own adkim setting. Do not weaken either setting just to turn a dashboard indicator green.

Read the current applicable policy before applying the instruction email's suggestions. Preserve existing p=quarantine, p=reject, reporting recipients and intentional child-domain controls. “Merge” means reconcile settings into one valid record, not paste two complete v=DMARC1 policies together.

For a domain without an existing applicable policy, a separately approved monitoring rollout might use this fictional record:

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

Replace the destination with an approved, operational mailbox or reporting-service address. This example does not instruct you to add sp=none, remove an inherited policy or replace an established enforcement record. p=none does not mean relaxed alignment, and a record with no working report destination provides no useful reporting feedback by itself.

For a subdomain From address, check _dmarc at that exact domain and any applicable parent policy if it has no record. Aggregate reporting helps distinguish Mail+ traffic from other senders. Compare the report destination URI host’s Organizational Domain with the Organizational Domain of the domain where the policy was found. A different Organizational Domain requires the report-generating receiver to check DNS authorization for that destination; a destination within the same Organizational Domain is excepted. Protocol authorization is separate from the owner’s approval to share report data. Failure reporting is optional and needs its own privacy decision, not a copied ruf placeholder. Aggregate-report destination authorization and exception.

Verify DNS, activation and the actual sending route

Use the real envelope domain, signing domain and selector in place of these examples:

dig +short TXT example.com
dig +short TXT bounce.example.com
dig +short TXT ISSUED_SELECTOR._domainkey.news.example.com
dig +short CNAME ISSUED_SELECTOR._domainkey.news.example.com
dig +short TXT _dmarc.news.example.com
dig +short TXT _dmarc.example.com

The two DKIM queries are diagnostic alternatives, not instructions to publish both record types. The returned type, owner and value must match the issued setup. For a CNAME, also verify the target resolves to the expected public key. Count SPF policies at the relevant owner, not every unrelated TXT record. Compare authoritative answers with a recursive resolver when cached data differs.

Then check Settings → Security → Deliverability for the active status. Do not mark completion from this alone. Mail+'s own setup page warns that its precheck can miss malformed input, including unintended spaces, even when the indicator is green. Documented validation limitation.

Have an authorized operator send a harmless message from the actual Mail+ campaign route to a controlled external inbox. Include the real From-domain choice and any personalization or subaccount involved. Inspect the receiving system's trusted Authentication-Results, not only a sender-supplied header or the campaign editor preview. Authentication-results trust boundaries.

Use results produced inside the actual receiving service’s known processing boundary, with its documented removal or exclusion of externally supplied Authentication-Results. If raw headers do not establish that boundary, use receiver-controlled diagnostics or an administrator-confirmed trace. A familiar authserv-id or header position alone is not proof; ignore attacker-supplied or otherwise untrusted fields. Operational receiver trust.

Accept the configured route only after recording:

• From: the intended visible domain, not an unexpected platform fallback.
• SPF: spf=pass on the expected MAIL FROM identity for direct delivery, with alignment separately identified. A provider-domain SPF pass may be unaligned without being an SPF failure.
• Branded DKIM: the intended signature has dkim=pass, the expected d= and s=, and alignment with From under the applicable adkim mode. A different passing signature or DMARC pass via SPF does not complete this DKIM test.
• DMARC: dmarc=pass for the expected From domain.
• Scope: the account or subaccount, campaign route, recipient system, time and observed domains. Repeat for every intended domain/route, including inherited subaccounts.

Investigate genuine SPF failures and errors even if aligned DKIM preserves DMARC. permerror can indicate multiple policies, invalid syntax or an excessive lookup path; temperror calls for DNS availability checks. fail, softfail and unexpected none require an envelope-domain and authorization review. Forwarding can change the connecting IP; compare a direct test rather than authorizing arbitrary forwarding servers. SPF result interpretation.

Troubleshooting and frequently asked questions

The reply domain is missing. What comes first?

Add and confirm its reply address in Mail+. Check that the confirmation was completed for the correct mailbox and account. DNS changes do not activate an unconfirmed reply address.

The domain says “A problem occurred.” Should I replace DMARC?

No. Inspect the instruction page's specific missing authorization, then compare it with authoritative DNS. A valid corporate policy can already exist while Mail+ lacks a needed record or account association.

Why is the domain green but a send fails?

Check leading/trailing whitespace and invalid characters in the submitted fields, as Mail+ specifically warns about this. Also inspect the actual selected domain and account. A green precheck does not override a real send error or failing received-message authentication.

Do subaccounts need their own DNS records?

For the franchise/corporate hierarchy described in the October 2026 release, subaccounts inherit the main account's DMARC settings. Unrelated accounts sharing a domain still require support coordination. Inheritance does not eliminate per-route delivered-message testing.

What is the universal Spotler SPF include or DKIM selector?

There is no universal value established by this Mail+ workflow. Get the values in the instruction email for your account and domain. Do not substitute a SendPro value, an older MailPlus example or a selector from another customer.

Can I use an existing stronger DMARC policy?

Preserve it and configure Mail+ to pass under it. Check other legitimate senders before any enforcement change. Do not automatically copy the setup page's illustrative monitoring and failure-reporting fields over your organization's existing policy.

Does a successful authentication test guarantee inbox placement?

No. It verifies a particular message's identities and authentication results. Reputation, consent, complaints, content and recipient policy still affect acceptance and folder placement. Monitor reports and subsequent real traffic for changes.

Documentation review and testing boundary

No account authentication request, support contact, DNS edit or sending test was performed. Current account-issued values and actual delivered-message results remain implementation checks.