In Flexmail, validate each sender address first, then configure its domain under Settings → Add or remove senders → Set up authentication. Generate the DKIM key, download the DNS report, publish the required records without overwriting existing mail settings, and configure a custom return-path where appropriate. Transactional email requires the authenticated domain and custom return-path; marketing email can otherwise use Flexmail's shared, non-aligned return-path. Confirm both DNS and delivered-message authentication before launch. Flexmail authentication workflow, Transactional prerequisites.
Choose the sending product before changing DNS
Flexmail's marketing campaigns and transactional product share account-level sender/domain setup, but their sending requirements and fallback behavior are different. This guide covers that authentication setup. It does not treat a working marketing campaign as proof that an HTTP API or SMTP integration is ready.
The transactional product supports application-triggered mail and can be used independently of a marketing subscription. Before integrating, activate the transactional product through its dashboard widget. That product activation does not enable SMTP automatically: SMTP access must be requested separately. Its username and password come from Flexmail; the HTTP API's personal access token is not an SMTP password. Transactional product overview, SMTP access and prerequisites.
Prepare these items:
- Access to the Flexmail account and the inbox of each proposed sender address.
- Control of the domain's authoritative DNS, or an administrator who can publish changes.
- The exact From domains and whether each is used for marketing, transactional mail or both.
- An inventory of current SPF, DKIM, DMARC and other mail-related records.
- A DNS change owner, rollback record and authorized validation recipient.
A branded sender, an API credential and a DNS record solve different problems. A successful API login does not authenticate the From domain, and domain authentication does not grant an unverified address permission to send.
1. Validate every sender address
Open Settings → Add or remove senders, choose Add a new sender, enter the address and request approval. The mailbox owner must complete the verification email. An existing pending address can use Resend approval email. The resulting checkmark confirms address validation, not the completion of DNS authentication. Sender validation.
Use a real accessible mailbox. A no-reply address without an inbox cannot complete this step merely because you control the domain's DNS. Validate every address you intend to use, even when its domain is already authenticated. Conversely, domain authentication is performed per domain, not separately for every local part before the @.
Record which address the campaign or integration actually uses. A change in a template's sender can select a different domain or an address whose verification is incomplete. Resolve that before trying to repair SPF.
2. Generate the domain's DKIM key and DNS report
Sender addresses are grouped by domain. Select Set up authentication for the intended group. Flexmail automatically prepares SPF and DMARC suggestions, but the DKIM key must be generated. The documented default selector is flexmail; retain it unless your administrator has a reason to select another. Choose Generate DKIM keys, then Generate report to download the TXT report of required DNS changes. Current key-generation workflow.
Use the report from the correct account and domain. It is a text document containing DNS instructions, not a single DNS TXT value to paste wholesale.
| Setting | Fixed or generated? | Safe implementation |
|---|---|---|
| DKIM selector | flexmail is the documented default; the selected value governs |
Use the issued owner for that selector and sending domain |
| DKIM public key | Generated for the setup | Publish the complete supplied TXT value, not another customer's key |
| SPF | Suggested by the account report | Confirm the owner and merge with an existing policy if needed |
| DMARC | Account suggestion must be reconciled with existing policy | Preserve established enforcement and authorized reporting |
| Return-path prefix | bounce is the documented default; it can be changed |
Select an unused, appropriate subdomain |
| Return-path CNAME target | Displayed after setup | Copy the exact name and value from Flexmail |
The current official authentication screenshot shows DKIM as a TXT public-key record. The account's generated report remains the implementation authority. Do not recreate its key with an external generator or publish a private key. Flexmail record example and procedure, DKIM key semantics.
Before replacing an existing selector, establish whether another active Flexmail setup uses it. Avoid repeatedly generating keys as a troubleshooting experiment: coordinate the signing key, public DNS and activation state rather than changing one side without the other.
3. Publish DKIM and merge SPF without replacing other senders
Save the old values and check the authoritative DNS host. Do not assume the registrar's DNS panel is active merely because the domain appears there.
For DKIM, publish the supplied TXT public key at the exact owner. In a zone for example.com, a relative-name field may take flexmail._domainkey; a full-name field may require flexmail._domainkey.example.com. These illustrate the default selector, not the key or domain values for your account. Check the resulting public name for duplicated suffixes.
For an issued signing domain such as news.example.com, a full owner flexmail._domainkey.news.example.com is flexmail._domainkey.news relative to the parent example.com zone, or flexmail._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is flexmail. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names. If a different selector was selected, substitute that value.
Preserve other senders' selectors. For long TXT values, follow your DNS host's entry convention. Several character strings returned as one TXT record can be valid; copying an incomplete key or inserting unwanted characters is not. A public record's presence does not prove Flexmail has installed the matching private key or is signing with it.
For SPF, use the authorization shown in the generated report at its specified owner. If that owner already has an SPF policy, incorporate the needed authorization into the existing policy instead of adding a second v=spf1 record. Preserve employee mail and other legitimate sending services, including the intentionally chosen final all qualifier. Check nested includes and other DNS-querying terms against the ten-term evaluation limit. SPF record and lookup rules.
If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.
Do not assume that an SPF include at the root domain creates DMARC alignment. SPF authenticates the SMTP envelope sender, usually reflected in the delivered Return-Path. With Flexmail's default shared return-path, an SPF pass can belong to Flexmail rather than your visible From domain. The custom return-path addresses the identity used for that alignment check. Flexmail return-path behavior.
For another application’s separate sending route, see the Microsoft 365 authentication guide. Its tenant configuration does not replace Flexmail’s generated records.
4. Set up the custom return-path
In the domain's authentication panel, find Return-path. Choose the prefix, which defaults to bounce, then select Set up return-path. Flexmail displays the CNAME name and target to publish. Copy both exactly and verify its status after DNS becomes available. Return-path setup.
For a hypothetical example.com sender, the owner might be bounce.example.com. That is an illustration of the prefix mechanism, not a target you should invent. Use a name that is not already serving a website, mailbox route or another sending platform.
A CNAME cannot coexist with ordinary TXT, MX, A or other records at the same owner. Do not add SPF TXT alongside the return-path CNAME or delete an existing record without understanding its use. Resolve a collision by selecting an appropriate unused prefix and coordinating the change. CNAME ownership rules.
If DNS is hosted on Cloudflare, keep the email-authentication CNAME DNS only and avoid CNAME flattening that hides the alias. Cloudflare's documentation explains that the proxy returns its own addresses and flattening can prevent third-party verification from seeing the CNAME. Do not apply this advice indiscriminately to unrelated web records. Proxy behavior, CNAME flattening.
Apply the following to the issued return-path CNAME only, not to the DKIM TXT key. For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.
Changing or removing a return-path can interrupt mail
Changing the prefix in Flexmail replaces the configured return-path and produces a new CNAME to publish. Plan the DNS update and validation with the application owner, particularly for transactional messages.
Removing the custom return-path causes transactional email for that domain to be rejected until a validated return-path exists again. Marketing email falls back to Flexmail's default non-aligned return-path. It is not a harmless cleanup step. Flexmail's documented removal warning.
Before removal or migration, identify every campaign and transactional integration using the domain. Do not remove the old DNS entry just because a new prefix was entered; agree on a retirement sequence with Flexmail and confirm the new configuration first. Keeping an obsolete record also is not a substitute for validating the new one.
5. Review DMARC and confirm alignment
DMARC can pass through aligned SPF or aligned DKIM; it does not require both mechanisms to align. However, complete and verify the authentication mechanisms the sending product requires rather than using one pass to ignore an unrelated failure. DMARC authentication and alignment.
For SPF, compare the envelope domain to the visible From domain. For DKIM, compare the passing signature's d= domain. Relaxed alignment permits a shared organizational domain; strict alignment requires equality. Thus bounce.example.com and example.com can align in relaxed SPF mode but do not match under aspf=s. A correctly aligned DKIM signature can still make DMARC pass.
Inspect the existing applicable policy before publishing Flexmail's generated DMARC suggestion. Preserve enforcement, reporting addresses and intentional adkim/aspf settings. Do not add a second policy at the same _dmarc owner or reset an established p=reject or p=quarantine policy to monitoring just to finish onboarding.
For a domain with no applicable policy, a reviewed monitoring rollout can start with v=DMARC1; p=none. Add an approved aggregate-report destination when monitoring is required, and arrange external destination authorization if necessary. The policy alone does not request reports or guarantee delivery. Account for parent policies affecting subdomains and check all legitimate mail streams before enforcement. The current DMARC specification is RFC 9989; the old pct percentage tag is no longer part of it.
Only when no direct or applicable inherited policy exists and the domain owner approves first-time monitoring, publish one TXT policy with v=DMARC1; p=none at the intended From domain’s DMARC owner. For example.com, the full owner is _dmarc.example.com, entered as _dmarc in that zone. For news.example.com, use full owner _dmarc.news.example.com: _dmarc.news relative to the parent zone, or _dmarc in the separately delegated child zone. Do not create a child monitoring exception to an existing protective policy. The minimal value requests no reports; append ; rua=mailto:APPROVED_REPORT_ADDRESS only after replacing the placeholder with a provisioned, approved destination. DMARC policy publication.
Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.
6. Separate DNS detection from Flexmail activation
Flexmail documents a 24–48-hour DNS waiting window, with return-path changes potentially taking up to 24 hours. Reopen the authentication panel after publication, but do not treat a delay estimate as a substitute for checking the actual records.
Two red-DKIM cases need different action:
- The overview badge says authentication keys are correctly added, but DKIM remains red: Flexmail says server-side key installation can still be processing.
- The overview badge is also red: the required DNS records have not been detected. Compare the latest report with the authoritative DNS answers.
If the condition persists beyond the documented window, provide Support with the affected domain, public record names, report and status details. Do not send credentials or private keys. Flexmail status interpretation.
Public DNS acceptance checks
Replace each example with the actual account-issued name. The SPF owner must be the one your configuration calls for; the return-path prefix and selector may differ from these examples.
dig +short NS example.com
dig +short TXT example.com
dig +short TXT flexmail._domainkey.example.com
dig +short CNAME bounce.example.com
dig +short TXT bounce.example.com
dig +short TXT _dmarc.example.com
Confirm that the DKIM public value is complete, the return-path alias matches Flexmail's target, and SPF/DMARC contain the intended policies without duplicates. Following the return-path alias for TXT helps inspect the envelope's SPF resolution; it does not mean you should create a second record alongside that alias.
For a discrepancy, compare an authoritative nameserver with a recursive resolver, substituting the actual server and owner:
dig @ns1.dns-host.example CNAME bounce.example.com +noall +answer
dig @1.1.1.1 CNAME bounce.example.com +noall +answer
Check a delegated subdomain's nameservers separately where applicable. A wrong authoritative answer needs correction. A correct authoritative answer with an older cached response calls for allowing the prior TTL or negative-cache lifetime to expire.
Delivered-message acceptance checks
After account readiness and approval to test, send representative messages to a controlled mailbox. Test marketing and transactional paths separately if both are in use. For SMTP, test through the actual application configuration rather than assuming an HTTP API result covers it.
Use the receiving mailbox's original-message view and its trusted receiver-added Authentication-Results, not an arbitrary authentication header copied into the message. Trusted authentication results.
Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.
Check:
- The visible From address is the intended, validated sender.
- SPF passes for the actual
smtp.mailfromdomain. If custom return-path is configured, the delivered envelope uses it rather than an unexpected fallback. - The expected branded DKIM signature is present, passes and aligns under the applicable
adkimmode, even when SPF supplies DMARC pass. - The receiver reports
dmarc=passfor the intended From domain, with an identifiable aligned passing mechanism. - The transactional integration is accepted and behaves as intended; a campaign-only result is insufficient.
Save the date, route, observed domains and relevant results. Limit shared diagnostics to what Support needs and redact personal information. Passing authentication does not guarantee inbox placement or prove every other sender sharing the domain is ready for enforcement.
Troubleshooting and frequently asked questions
Why is Flexmail's DKIM indicator still red after DNS was added?
Compare the overview badge and the detailed DKIM status. Correct DNS with pending provider-side installation is different from undetected DNS. Check the exact selector owner and full key, wait within the documented window where appropriate, and escalate a persistent mismatch without repeatedly regenerating keys.
Why does SPF pass but DMARC fail?
Check the actual envelope domain and policy alignment mode. A shared provider return-path can pass SPF while remaining unaligned. A branded bounce subdomain can fail strict SPF alignment. Inspect the branded DKIM result and alignment before changing policy.
What if SPF fails but DKIM makes DMARC pass?
Do not ignore the SPF failure. For fail or softfail, compare the sending IP with authorization at the actual envelope owner. For permerror, investigate duplicate SPF policies, syntax errors and excessive DNS-querying terms. For temperror, investigate DNS availability and retest after the transient issue clears. Ask Flexmail to resolve provider-managed record problems rather than changing an unrelated root policy.
Why did transactional email stop after I removed the return-path?
Flexmail explicitly documents rejection until a validated return-path exists again. Restore an approved configuration and confirm validation with the application owner. Marketing fallback does not prove the transactional route works.
What is the exact Flexmail SPF include or DKIM key?
Use the current report for the intended domain. The DKIM key is generated, and the public instructions do not make another customer's example an authoritative value for your account. Confirm the SPF owner and preserve existing authorizations when merging the report's requirement.
Do I need to authenticate every sender separately?
Validate every email address separately, but authenticate each sending domain once through its domain group. A different subdomain should be checked as its own configured sending identity rather than assumed covered by a parent-domain setup.
Is authentication optional for a small marketing list?
Flexmail's guide says its marketing interface can permit sending below 5,000 contacts without full authentication, but recommends authentication from the start. That is a platform rule, not a universal mailbox-provider exemption or inbox guarantee. Transactional authentication and return-path requirements are separate and mandatory. Marketing setup, Transactional setup.
Do these DNS records fix an SMTP login error?
No. SMTP access must be enabled by Flexmail and uses separately supplied credentials, not the API token. Resolve the connection/authentication error independently, then validate domain authentication on an actual delivered message. SMTP submissions.
No customer account was configured, no DNS was changed, and no message was sent or live delivery tested in preparing this guide.*