Gather the right account and DNS access
Flodesk's current manual process requires a custom-domain email address, access to the Flodesk account and access to the domain's DNS manager. Identify who controls authoritative DNS rather than assuming the registrar hosts the active zone. Preserve the current records before making changes, especially records used by other marketing tools or ordinary mailboxes.
Decide whether the domain owner will use the manual workflow or authorize the automatic Entri integration. These are alternative ways to publish the required records, not different authentication protocols. Do not run both repeatedly just because verification is pending.
Use the account's manual record set
Open My Account > Domain setup, select Authenticate now on the domain card and choose the manual option. The current documentation describes two possible sets: five records consisting of one SPF, three DKIM and one DMARC record, or three records consisting of one of each. The account determines which set applies. Do not copy a fixed count or selector from an unrelated tutorial.
Use each Copy control to obtain the exact owner and value. Flodesk specifies CNAME records for its SPF and DKIM entries and a TXT record for DMARC. Preserve the displayed types. A CNAME is a DNS alias to another name; it is not a text mechanism to paste inside an existing SPF string.
In particular, Flodesk says to add its SPF CNAME as a separate record, not combine it with an existing SPF TXT policy. This does not mean publishing two v=spf1 policies at one owner is safe. The generated CNAME has its own owner and function. If that owner is already occupied by incompatible data, stop and resolve the conflict with the DNS administrator rather than overwriting another service.
Preserve the existing DMARC decision
The manual instructions say to add the displayed DMARC TXT record only if no DMARC record already exists. The displayed policy is intended for members without a policy. Do not create a second DMARC record or replace an established reject or quarantine policy with a setup example.
Check the exact policy owner and current configuration with the domain administrator. Authentication success requires a valid aligned SPF or DKIM path under the applicable mode; publishing a policy is not proof that campaigns satisfy it. Keep the organization's reporting and enforcement decisions separate from the mechanics of adding Flodesk's generated records.
Finish verification without unnecessary restarts
After publishing the records, return to Flodesk and finish with Next and Done. The service monitors DNS automatically. The documentation describes Pending and partial-verification states during its stated window of up to 48 hours. Treat that as provider guidance, not a universal guarantee that every DNS fault resolves itself after two days.
A partial state can arise while different records become visible. First compare authoritative answers with the account's exact record set. Check duplicated domain suffixes, wrong record types, incorrect CNAME targets and edits made at an inactive DNS host. If the correct records are visible but the state remains unresolved beyond the documented window, gather the record set and status for support instead of repeatedly restarting authentication.
Understand the automatic alternative
The automatic flow also starts under Domain setup. Choose automatic authentication and connect the domain provider through Entri. The owner authorizes the access needed for Entri to add DNS records. Review the requested access and intended changes before approving; the integration is a third party, not merely a different view of the DNS editor.
Flodesk says an unsupported provider leads to the manual option. If automatic setup does not finish, inspect what was actually created before switching methods. Avoid duplicate policies or accidental replacement of a working record. Changing DNS hosts later also requires preserving these records in the newly authoritative zone; a registrar change alone is not proof that DNS moved or that records were lost.
Verify a campaign, not only the domain card
Send a controlled email through the production workflow to a mailbox where original headers can be inspected. Record the visible From domain, envelope domain, every DKIM signing domain and selector, and the trusted receiver's authentication results. Confirm the passing path's alignment rather than assuming a verified card guarantees every future route.
Illustrative case, not a Flodesk observation: From is hello@example.com and DKIM passes with d=example.com. That supplies exact DKIM alignment. If an unrelated envelope domain passes SPF, that result alone does not align with example.com. Preserve both outcomes so a later signing failure is not concealed by an unrelated SPF pass.
Keep a recovery record and test any DNS-host migration before declaring it complete. Authentication does not guarantee inbox placement; reputation, message content and receiver decisions remain separate. This guide retains first-party documentation and a synthetic example only. No real DNS change, tenant validation or received campaign was executed, and human production approval remains pending.
Resolve a record collision without guessing a target
For written case FL-01, assume the Flodesk panel requests a CNAME at a generated owner represented here as bounce.example.com, but the DNS inventory shows that same owner is already a working A record for an unrelated service. This owner is illustrative, not a real Flodesk-generated label; the requested CNAME target is unknown. Do not overwrite the A record or paste the target into the root SPF TXT. The DNS owner must identify the dependency and agree a supported conflict resolution with the provider before proceeding. Keep the existing DMARC policy unchanged and the campaign unverified. No DNS answer, account grant or message was obtained for this case.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.