Authenticate Flodesk from My Account → Domain setup, using the DNS records generated for your account. Its current manual setup uses CNAME records for SPF and DKIM, not a new root-domain SPF TXT policy. Preserve existing DMARC, complete the setup in Flodesk, and check a delivered campaign for aligned authentication before treating the job as finished.
Choose the correct domain and account
This guide covers custom-domain authentication for email sent through Flodesk. It does not configure employee mailboxes, website hosting, or authenticate a different application simply because it uses the same From address. Preserve staff-mailbox authentication separately from this campaign route.
Start with a domain you control and a working address on that domain. Access to a Flodesk login is not access to DNS. Identify the authoritative DNS operator, which can differ from the company that sold the domain. Record the exact sending address, domain, Flodesk account and person responsible for publishing DNS.
If the domain card is missing, add your custom-domain sending address under My Account → Email setup. Flodesk's troubleshooting documentation connects that address to the Domain Setup page. A personal Gmail, Yahoo or Hotmail address does not give you control of those companies' DNS.
Save the current zone entries before editing. Include existing SPF, DKIM selectors, DMARC and any records at the specific names Flodesk requests. This makes it possible to distinguish a new record from a collision with another sender. Do not use domain authentication as a reason to replace your incoming-mail MX records.
Publish the Flodesk record set
Open My Account → Domain setup, select Authenticate now, then I'll do it manually. The current manual guide describes two account-dependent sets: one SPF, three DKIM and one DMARC record, or one SPF, one DKIM and one DMARC record. Both use CNAME for SPF/DKIM and TXT for DMARC. Copy the complete names and destinations from your own account; do not recreate a screenshot's tokens.
Use this change worksheet:
- SPF delegation: type CNAME; owner is the exact SPF Name displayed by Flodesk; value is its corresponding account-generated destination.
- DKIM: type CNAME; owner is each account-generated selector name containing
_domainkey; value is the matching destination for that row. - DMARC: type TXT; review the domain's current policy before adding or changing anything, as explained below.
These are field instructions, not universal publishable values. Keep each name paired with its destination. A CNAME destination is a hostname, not a URL: do not add https://, a path or an email address.
Many DNS panels append the zone name automatically. If Flodesk displays a fully qualified name ending in example.com and your panel adds that suffix, enter only the required relative label. For example, fictional selector._domainkey.example.com would become selector._domainkey in that panel. The final public name must contain the domain only once. Confirm the provider's convention rather than assuming every panel behaves alike.
For a required literal authentication CNAME in Cloudflare, use DNS only, turn the applicable per-record Flatten option off when available, and ensure CNAME flattening for all CNAME records does not conceal that alias. Coordinate any shared-zone setting change with affected owners rather than disabling it globally without review. DNS-only alone is insufficient. Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of the setting. If mandatory behavior or shared dependencies prevent the required literal CNAME answer, stop and coordinate a supported configuration; do not invent a switch or delete NS delegations. Cloudflare CNAME verification, flattening controls. A CNAME owner cannot also hold conflicting ordinary TXT, MX or another CNAME destination. Stop at a collision. Ask the DNS administrator to identify the existing record's purpose; do not delete a working sender's record to make the form save.
For fictional selector._domainkey.news.example.com, use relative selector._domainkey.news in the parent example.com zone, or selector._domainkey at a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, use selector there. Publish at the actual authority and preserve NS, other selectors and DNSSEC; never delete delegation to force a parent-zone entry.
Keep existing SPF working
Flodesk's SPF explanation specifically distinguishes its CNAME-based setup from another provider's SPF TXT record. Publish Flodesk's generated CNAME separately at its specified owner. Do not paste the target into a v=spf1 string or invent an include:flodesk.com mechanism.
Your root-domain SPF may still authorize Microsoft 365, Google Workspace or other systems. Leave those authorizations intact. One SPF policy is allowed at each owner name, not just one across an entire DNS zone. A dedicated subdomain can have a different policy from the root; that is not the duplicate-SPF problem.
SPF evaluates the SMTP envelope sender (or HELO in applicable cases, including a null reverse-path), usually visible as smtp.mailfrom in authentication results, rather than the friendly display name, Reply-To or visible From address. A successful SPF lookup for the root does not prove which domain a Flodesk message used. Check the actual message before concluding that SPF aligns with your visible From domain. SPF specification.
If a separate sender requires changing a TXT policy, retain a single v=spf1 record at that owner and check the ten DNS-querying-term limit, including nested includes. That separate maintenance is not a prerequisite invented for Flodesk's CNAME flow. SPF ignores redirect= whenever any all mechanism is present, irrespective of ordering; mechanisms after all are unreachable. Preserve the approved qualifier and do not add an all that disables an existing redirected policy. Qualifiers specify SPF outcomes, not guaranteed delivery or rejection. RFC 7208 section 5.1.
Preserve DMARC protection
Flodesk's manual instructions say not to add its suggested DMARC record when one already exists. Also check for inherited protection: absence of _dmarc.news.example.com does not prove that mail from news.example.com has no applicable policy. Review the parent domain and the organization's policy before creating a local override.
Only for a domain without an established applicable policy, where the owner has approved an observation-first rollout, an illustrative starting record is:
Type: TXT
Owner: _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace example.com with the intended policy domain and the address with an approved, monitored reporting destination. In a zone-relative editor the root-domain owner is _dmarc. For a deliberate local policy on news.example.com, the full owner is _dmarc.news.example.com, or _dmarc.news in the example.com zone. In a separately delegated news.example.com zone, use _dmarc there. Substitute only the mailbox after mailto:, not another mailto: prefix.
Do not publish the example alongside an existing DMARC record. Preserve p=quarantine or p=reject, reporting destinations, subdomain policy and alignment settings unless the policy owner approves a specific revision. When the Organizational Domain of the report destination host differs from that of the domain where the DMARC policy was found, the report-generating receiver must check DNS authorization for the destination. Destinations within the same Organizational Domain are excepted; a different hostname alone does not trigger that requirement. DNS authorization does not replace the domain owner’s approval of the recipient and report-data sharing. RFC 9990 section 4.
DMARC requires an authenticated identity to align with the visible From domain: either passing aligned SPF or passing aligned DKIM suffices. Relaxed alignment permits the same organizational domain; strict alignment requires an exact match. p=none requests monitoring, not blocking. RFC 9989 replaces RFC 7489 and removes pct; do not add that retired tag to a new example.
For a fictional From: news@example.com, a passing intended signature with d=mail.example.com aligns in relaxed mode (assuming the same Organizational Domain), but not strict mode. A passing d=example.com matches exactly under both modes. These illustrate comparison, not measured provider defaults. Do not accept a rewritten provider-owned From as successful authentication of the intended brand. DMARC alignment.
See raw DKIM results versus aligned DKIM results when a signature passes without authenticating the intended visible identity.
Complete manual or automatic authentication
After manual publication, return to Flodesk and finish with Next → Done. Flodesk monitors the records. Its authentication overview points to the Domain Setup page for progress. Completion of the wizard is not the same as receipt of a correctly signed message.
The alternative is automatic authentication through Entri. From the domain card, choose Automatically authenticate, connect the supported DNS provider and follow the prompts. Before authorizing a connection, review the requested DNS changes and access. Automatic setup is a publishing method, not permission to weaken an existing DMARC policy. Use manual setup if you need the DNS administrator to inspect the change set first.
The manual documentation gives up to 48 hours; Flodesk's troubleshooting article allows up to 72 hours. Treat these as documented windows, not delivery guarantees. Check obvious mistakes immediately; do not repeatedly rebuild correct records merely because a timer has not elapsed.
Verify DNS and a delivered campaign
First check public DNS. Replace every placeholder with the actual account-issued name; the following are commands to run, not test results:
dig +short NS example.com
dig +short CNAME SPF_OWNER_FROM_FLODESK
dig +short CNAME DKIM_OWNER_FROM_FLODESK
dig +short TXT DKIM_TARGET_FROM_FLODESK
dig +short TXT _dmarc.example.com
Repeat the DKIM checks for every supplied selector. Expected evidence is an exact CNAME target match, resolvable DKIM public-key data behind the relevant target, and one intended DMARC policy at its owner. Compare authoritative answers with a public recursive resolver if results disagree. Blank output requires investigation of the queried name and DNS response, not a conclusion that the account is broken.
Then send an authorized campaign with harmless content to a valid mailbox you control, using the actual production From address. Inspect the receiving service's trusted Authentication-Results, not a header supplied by the sender. Use results produced inside the actual receiving service’s known mail-processing boundary, and ask its administrator how externally supplied Authentication-Results fields are removed or excluded from trusted evaluation. A familiar authserv-id or header position alone does not prove origin. Ignore attacker-supplied results. RFC 8601 section 7.1.
A useful acceptance record contains the visible From, smtp.mailfrom, DKIM d= domain and s= selector, receiver results and sending time. Require dkim=pass for the intended Flodesk branded signing domain and account-issued selector, alignment under the effective policy, AND trusted dmarc=pass for the intended From. An SPF-only DMARC pass does not close DKIM setup. Record SPF separately and explain whether its passing domain aligns. Investigate actual SPF fail, softfail, temperror or permerror even if aligned DKIM permits DMARC to pass. Check the envelope domain, authoritative policy, lookup errors and whether forwarding changed the connecting server; DKIM success does not make a broken direct-sending SPF route healthy. Verify the selected domain has not been replaced by another identity. Repeat on workflow emails if they use different sender settings; a broadcast test cannot prove every route.
Troubleshoot incomplete authentication
Only SPF remains pending: compare the SPF CNAME owner and target with Flodesk, then inspect public DNS. Do not add a second root SPF TXT record as a workaround. Flodesk notes that SPF can take longer to verify than the other rows.
Everything looks saved, but nothing resolves: check authoritative nameservers. Records entered at an inactive registrar panel do not change the live zone. Also inspect doubled suffixes and reversed Name/Value fields.
A domain is partially verified: repair the individual failed row. Preserve working DKIM and DMARC records. Capture the current account display and DNS answers before escalating.
DNS and the domain badge pass, but DMARC fails: check the campaign's actual From domain and the signature's d= value. A passing signature for an unrelated domain is insufficient. Review strict alignment before changing any policy.
Authentication passes but mail enters spam: investigate consent, list quality, complaints, content and sending behavior. Authentication does not guarantee inbox placement.