Floify SPF, DKIM and DMARC setup, step by step

For Floify’s native outbound email, request the domain-specific CNAME records from Floify support, publish them at your authoritative DNS host, and return to support for verification. Floify also documents include:spf.floify.com for SPF. Do not guess the DKIM targets, overwrite another sender’s selectors, or replace an established DMARC policy with a tutorial example. Floify’s SPF instructions and DKIM/DMARC instructions establish this support-assisted workflow.

This is a source-document review, not hands-on testing.

This guide covers an existing Floify deployment sending from your organization’s domain. It does not configure your employees’ Microsoft 365 or Google Workspace mailboxes, authorize a new mortgage-data integration, or move your website. Those are separate operations. Authentication improves identity assurance; it does not guarantee inbox placement.

Prepare the domain and change plan

Identify the exact visible From address used by the Floify notices you intend to authenticate. Record the product/account and any sending subdomains. Obtain the domain owner’s permission and access to the authoritative DNS zone, not merely the registrar’s billing account. If the nameservers point elsewhere, make changes where that zone is actually hosted.

Before editing, export or record the current affected DNS records and TTLs. Capture the existing SPF policy, DKIM selectors, direct and inherited DMARC policy, and approved reporting destinations. List other legitimate senders sharing the domain. Agree who can approve the proposed changes, perform them, confirm support verification and restore the previous state if necessary. Do not change MX, parent nameservers, DNSSEC or security controls just to follow an email tutorial.

Floify’s public instructions do not establish universal plan, administrator-role or regional eligibility rules. Confirm entitlement and authorized contacts with your existing account team before requesting a packet; do not assume purchasing a different plan or granting broader access is necessary.

Obtain the actual Floify DNS packet

Ask Floify support for the complete authentication records for the intended domain and account. Confirm which records are DKIM selectors, which serve an envelope/bounce identity, and whether there is a separate activation step after DNS validation. Floify explicitly directs customers to obtain its CNAME records through support and notify support after publication. Official setup workflow

Your change sheet should contain each full DNS owner, record type, complete target/value, purpose, existing value and intended new value. Keep the full owner visible even if the DNS console later accepts a relative name. Provider-issued values are public DNS data, but private signing keys, API secrets and account passwords do not belong in the change sheet.

Do not treat examples such as em1234, s1 or s2 as your allocated records. Obtain every required record rather than inventing a fixed number of CNAMEs. If a selector is already occupied by another sender, request a custom selector from Floify instead of replacing it. Floify’s selector-conflict guidance

Add Floify SPF without breaking existing senders

SPF authorizes sending servers for the SMTP envelope identity, normally the MAIL FROM domain, not automatically the address readers see in From. Ask support which envelope domain your route uses. An apex SPF edit cannot establish alignment for a different provider-owned envelope domain. A customer subdomain can align under relaxed DMARC alignment when it shares the relevant Organizational Domain; strict alignment requires the exact same domain. Do not infer a custom Return-Path from a generic example. SPF specification and DMARC specification

Floify’s documented authorization mechanism is:

include:spf.floify.com

Add it only at the appropriate SPF owner and only after confirming that this sending route is authorized. If that owner already has a v=spf1 TXT record, edit that single policy; do not create a second SPF record. Preserve legitimate existing mechanisms, their order and qualifiers, and the chosen final policy. Include mechanisms normally belong before a terminating all. An existing redirect= design needs deliberate reconciliation: adding an all mechanism makes redirect inapplicable. Floify’s SPF instructions

The following is a minimal conditional example, not a replacement for your real policy. It applies only when this owner has no SPF policy, Floify is its only authorized sender, and the owner approves softfail:

v=spf1 include:spf.floify.com ~all

Floify’s sample also includes a and mx. Do not add these merely because they appear in a sample: they authorize additional machines and consume DNS-dependent SPF terms. Preserve them when they are an intentional existing requirement; otherwise assess their necessity. SPF allows at most ten evaluated DNS-dependent terms, including nested include/redirect evaluations, rather than ten visible includes. A syntactically correct policy can still exceed the limit during evaluation. RFC 7208

Softfail is not an instruction guaranteeing acceptance. ~all produces softfail for an unmatched sender; receiving systems still apply their own handling. Likewise, -all does not promise a particular delivery outcome. Floify’s simplified softfail explanation should not be read as an inbox guarantee. Investigate SPF fail, temporary DNS errors and permanent policy errors separately even if DKIM allows DMARC to pass.

Publish each DKIM CNAME at the correct owner

Use the records in your support packet. A CNAME value is a DNS hostname, not a web URL: do not add https://, a path or a trailing browser slash. Copy the issued target precisely. If anything in the packet is ambiguous, ask support rather than converting it by guesswork.

A full owner such as ISSUED-SELECTOR._domainkey.example.com is a placeholder illustration. In the example.com zone, a relative-name interface may need only ISSUED-SELECTOR._domainkey. In a separately delegated child zone, remove only that child zone’s suffix. Check the console’s final expanded name to avoid publishing example.com.example.com. For example, selector._domainkey.mail.example.com becomes selector._domainkey in the delegated mail.example.com zone, but becomes just selector in a separately delegated _domainkey.mail.example.com zone. Preserve the existing NS delegation and publish at its authoritative host; coordinate with its administrator instead of deleting delegation records.

At a CNAME owner, do not add conflicting TXT, A, AAAA, MX or another CNAME. Keep other providers’ independent selectors intact. A selector conflict is an allocation problem, not permission to disable another sending system. Floify conflict handling

Keep authentication aliases DNS-only rather than HTTP-proxied. Where the DNS provider can flatten CNAMEs, ensure the required literal aliases remain visible. On Cloudflare, turn off a relevant per-record Flatten control when available and check applicable zone-wide behavior. Apex and same-zone behavior can differ. Do not disable a global setting without assessing other dependencies; if mandatory flattening prevents the required answer, stop and arrange a supported configuration with the DNS host and Floify. Cloudflare’s current flattening controls

Preserve DMARC protection and approved reporting

DMARC evaluates whether SPF or DKIM passes with an identity aligned to the visible From domain. The adkim setting controls alignment of DKIM’s d= signing domain; aspf independently controls alignment of the SPF-authenticated MAIL FROM domain. Relaxed alignment allows the same Organizational Domain, whereas strict alignment requires an exact domain match. Thus an envelope domain such as bounce.example.com does not strictly align with a visible From domain of example.com, even if SPF passes. Adding a Floify selector does not replace your domain-wide DMARC governance. Preserve any applicable direct or inherited policy, alignment settings and authorized report destinations. Do not create duplicate DMARC records, downgrade quarantine or reject to none, or copy a reporting address from a sample. DMARC specification

Only when there is no applicable policy, the domain owner approves monitoring, and someone is responsible for reviewing results, a first policy might be:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none

Here example.com is a placeholder for the relevant policy domain. In its authoritative zone, the relative owner is normally _dmarc. For a separately governed sending subdomain, determine its actual policy discovery and authority rather than putting every policy at the organizational apex. Monitoring requests neither quarantine nor rejection under DMARC, and the example has no report destination. Add reports only through an approved monitoring arrangement.

For an aggregate-report destination in a different Organizational Domain from the policy domain, report-generating receivers check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone is not enough to make it external. This protocol check is separate from the owner’s approval to share reporting data. RFC 9990, section 4

Verify DNS, then return to Floify support

Read back every issued record from authoritative DNS and a public recursive resolver. Compare full owners, types and targets against the approved packet, not just the appearance of a green DNS-console badge. The commands below are placeholders, not results from a customer test:

dig +short TXT SPF-OWNER.example.com
dig +short CNAME ISSUED-SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

Repeat the CNAME lookup for every issued alias. Confirm there is only one SPF policy at its owner and no competing DMARC policy at the same name. DNS caching can delay what different resolvers see. Do not keep rewriting a correct record while cached data expires.

Tell Floify support when the approved records are published and obtain confirmation that the intended domain has been verified for your account and is ready for signing on the intended route. DNS publication alone is not proof that Floify is using the signature. Floify advises that changes can take up to 48 hours and explicitly requests this return-to-support verification. Floify verification instructions

Test a real notice safely

After support confirmation, use a controlled test borrower or other approved test workflow with a valid recipient you control. Do not create a real loan application, expose borrower documents, or trigger production borrower notices merely to test authentication. Use representative notice types from the route being deployed; a message from an employee’s normal mailbox is not the same test.

At the receiving service, inspect its original-message or administrative trace output. Use Authentication-Results produced inside that service’s known processing boundary, following its documented handling of externally supplied result fields. A familiar authserv-id string or a header near the top is not independently trustworthy: senders can insert fake fields. Ask the receiving administrator to identify the trusted result if necessary. Authentication-Results trust boundary

Record the actual visible From, MAIL FROM/Return-Path, DKIM d= signing domain and s= selector. For the branded DKIM setup to be accepted, the intended Floify signature must pass and align with the intended From under the current policy, and the trusted receiver must report DMARC pass. A DMARC pass achieved solely through SPF does not prove DKIM works; a provider-rewritten From is not proof of your brand’s authentication. See raw DKIM results versus aligned DKIM results.

Keep the verification record free of unnecessary borrower details. This article’s preparation involved documentation review, not account access, DNS changes or actual notice sending.

Troubleshooting and safe rollback

If a new change causes harm, pause the affected sending workflow through an approved operational process and restore only the changed records from the prior snapshot after checking shared dependencies. Coordinate signer rollback with Floify. Retain required keys for messages still in transit; do not delete unrelated selectors or weaken DMARC as a shortcut. Record what changed, when and which tests establish recovery.