Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Separate sender permission from domain authentication
Flexmail uses two setup stages. Sender validation confirms that someone can approve use of a specific email address. Domain authentication configures the DNS identities used by receiving systems. A checked sender address does not, by itself, prove aligned SPF or DKIM. Flexmail’s guide says authentication is not technically enforced below 5,000 contacts, while strongly recommending it. That product threshold is not an exemption from a receiving provider’s requirements or a reason to omit authentication.
Prepare access to the sender's inbox and to the domain's authoritative DNS, or identify the responsible administrators. Also identify every marketing and transactional workflow using this domain. Return-path changes can affect these routes differently, so do not treat a campaign-only test as proof that transactional delivery remains safe.
Validate each sender address
Open Settings > Add or remove senders, choose Add a new sender and request approval for the intended address. The mailbox owner follows the confirmation email's verification link. A checkmark indicates the address has been validated. Each address needs its own validation, even when several share a domain.
Use an address with an accessible inbox. A no-reply label is not inherently invalid, but an address with no readable mailbox cannot complete this flow. If a pending sender already exists, use the documented resend-approval option rather than creating confusing duplicate entries. The star selects a default sender for new campaigns; it is not a DNS authentication control.
Generate the domain's authentication report
References: RFC 7208 §3.2, RFC 9989 §4.10.
In the same settings area, addresses are grouped by domain. Choose Set up authentication for the intended domain. Flexmail generates SPF and DMARC instructions automatically. DKIM requires generating the key; the documented default selector is flexmail, which can be changed when the domain administrator has a reason, such as a naming conflict.
Generate the DKIM keys, then use Generate report to download the TXT report containing the required records. Give the approved record set to the DNS administrator. Use this current per-domain output, not values from a different account. Merge any SPF requirement into the single applicable policy and preserve an existing DMARC policy rather than creating duplicates or weakening enforcement.
The interface distinguishes record and installation states. A red DKIM indicator with a green authentication-keys badge can mean DNS is correct while installation on Flexmail's servers is still processing. A red badge instead calls for checking whether DNS records were detected. Inspect these two signals separately before regenerating keys or changing DNS repeatedly.
Configure and protect the return-path
References: RFC 9989 §4.4.
The documented default return-path uses a shared address outside the customer's domain. In Set up authentication, find Return-path, choose an appropriate prefix and select Set up return-path. The default prefix is bounce; the account supplies the resulting CNAME name and target. Publish that exact record and verify its status.
A return-path subdomain can support SPF alignment under relaxed alignment when it shares the applicable organizational domain with the visible From. It does not automatically satisfy strict SPF alignment, which requires exact domains. Aligned DKIM can independently satisfy DMARC. Do not interpret the provider's simplified alignment description as a requirement that both authentication paths must pass and align.
Changing the prefix creates a new record to publish. Plan that as a controlled change, preserve previous evidence and test the affected routes. Do not remove the old configuration merely to clear a status display before you understand the consequences.
Treat removal as a delivery-impacting change
Flexmail's current documentation gives an explicit warning: removing the return-path causes transactional mail for that domain to be rejected until a validated return-path exists again, while marketing mail falls back to its default non-aligned return-path. This is not a harmless cosmetic reset.
Before removal, obtain the workflow owner's decision, identify transactional dependencies and prepare the replacement or retirement plan. A marketing message may still meet DMARC through aligned DKIM after a fallback, but that does not remove the documented transactional requirement. Check the actual route instead of assuming all Flexmail mail behaves alike.
Verify the final identities on each route
References: RFC 6376 §6, RFC 9989 §5.3.5.
After product validation, send controlled marketing and transactional tests for the workflows in scope. Save original received messages and identify visible From, envelope domain, DKIM d= and s=, trusted receiver verdicts and the aligned passing path. Record delivery failures separately from authentication failures.
Illustrative case, not a Flexmail measurement: From is alerts@example.com, SPF passes for bounce.example.com and DKIM passes with d=example.com. Exact DKIM alignment is available. SPF would not provide strict alignment between those two different domains, even though relaxed alignment may apply. A dashboard check cannot replace examining the applicable policy and actual identities.
When DNS checks fail, compare authoritative answers with the downloaded report, including owner suffixes and CNAME conflicts. When only server-side DKIM installation is pending, follow the provider's status guidance rather than destroying a correct record. This documentary guide performs no tenant changes or live delivery tests. Preserve those execution holds and require human sign-off before production rollout.