Wordfly SPF, DKIM and DMARC setup, step by step

WordFly authentication starts with a custom DKIM TXT record supplied by WordFly Support. Publish that record for your approved sending domain, ask Support to verify and finish the setup, and retain or establish the appropriate DMARC policy. WordFly manages SPF for its own return-path domain; adding an include to your visible From domain does not, by itself, create SPF alignment. Confirm the customer-domain DKIM signature on a delivered campaign before treating the setup as complete. WordFly DKIM instructions, WordFly sending infrastructure.

Which WordFly email does this guide cover?

This guide covers email sent through WordFly's campaign infrastructure using your organization's From domain. It does not configure your employee mailbox provider, an unrelated transactional platform, or WordFly SMS. Treat each From domain and sending workflow as a separate validation case, including automated campaigns and any testing route your team uses.

Before starting, record the account, the exact From address, the DNS administrator and the person coordinating with WordFly. Confirm that the domain is yours to configure. A reply mailbox, a website address and a newsletter sending domain may be related, but they do not automatically share authentication settings.

New accounts also require WordFly's account review before sending is activated. Publishing DKIM and DMARC does not replace that onboarding step. WordFly account setup.

Understand WordFly's two DKIM signatures and SPF identity

WordFly documents a double signature: one using wordfly.com and one using the customer's sending domain. The provider signature supports its complaint-report handling; your custom signature supplies the identity that can align with your visible From domain. Do not stop inspecting a message after finding a passing provider signature. WordFly custom and provider DKIM.

Keep these identities separate:

SPF checks whether the connecting sending IP is authorized for the envelope domain. It does not authenticate the address displayed in the mail client's From field. SPF identity rules.

For example, a message can pass SPF for a provider-owned return path and still need custom DKIM to pass DMARC for example.com. That is an expected architecture, not a reason to overwrite the organization's root SPF record.

1. Request the correct custom DKIM record

Ask WordFly Support for DKIM for the exact domain your campaigns will use. Use your existing onboarding or support conversation so the record is associated with the intended account. The official instructions identify support@wordfly.com as the request destination. Allow the documented two to three days for setup and testing rather than assuming publication makes signing immediately active. Custom DKIM provisioning.

Have the administrator retain the complete supplied DNS name, type and value. The public guide uses wordfly02._domainkey as its selector owner, but the actual support-issued record for your domain governs implementation. The key value is organization-specific. Never copy a public-key example from another domain or use an independent key generator unless WordFly explicitly coordinates that workflow.

Save existing records before changing anything, especially a record already present at the proposed selector. A collision could indicate an earlier WordFly setup or another account using the same domain. Ask Support how to resolve it instead of replacing a working key without knowing which campaigns rely on it.

2. Publish the TXT record without damaging other mail

Open DNS at the authoritative host for your sending domain. This may be different from the company that registered the domain or hosts your website.

Create the exact TXT record supplied by WordFly. In a DNS interface that automatically appends example.com, the documented selector would be entered as wordfly02._domainkey. An interface that requires a full name would instead use wordfly02._domainkey.example.com. Check the published owner afterward to catch an accidental repeated suffix.

For an illustrative issued full owner wordfly02._domainkey.news.example.com, the relative owner is wordfly02._domainkey.news in example.com, wordfly02._domainkey at a delegated news.example.com authority, or wordfly02 at an existing delegated _domainkey.news.example.com authority. Substitute the actual Support-issued selector and preserve NS delegation and other keys. Relative DNS names.

Paste the complete public-key value into the TXT value field. Do not paste the email's explanatory prose, a screenshot, smart quotes or a private key. WordFly advises against adding surrounding quotes in a DNS web interface; a zone-file editor may use different syntax. Use your DNS host's instructions for long TXT values. Multiple quoted character strings in one TXT answer can be a valid presentation of one record, but two competing key records at the same selector need investigation. WordFly DNS publication, DKIM key lookup.

Keep employee-mail MX records, other providers' selectors and unrelated verification TXT records intact. This setup is an addition for a sending service, not a migration of the organization's incoming email.

After publication, reply to the WordFly support ticket and ask for confirmation that the custom key is configured and their verification is complete. Arrange monitored postmaster@ and abuse@ addresses as part of your sending operations; WordFly documents their role in complaints and feedback-loop coordination. WordFly mailbox guidance.

3. Handle SPF according to the actual return path

WordFly's official sending guide says it publishes SPF for its sending domain and that SPF authenticates the return-path/bounce address. The reviewed workflow does not establish a universal customer-root SPF include that every WordFly account must add. Provider-managed SPF.

Do not add include:wordfly.com merely because an older third-party setup article lists it. First establish the envelope domain used by your account. A root-domain authorization cannot make a provider-owned envelope domain become your domain.

If Support gives you a different, account-specific envelope configuration, request the precise DNS owner, record type, current value and activation requirements. Verify that configuration separately. Do not invent a custom return-path feature or derive its targets from a WordFly hostname.

For any authorized SPF edit, modify the one existing SPF TXT policy at the required owner, preserving legitimate senders. Never publish a second v=spf1 policy there. Evaluate the full policy, including nested includes and other DNS-querying terms, against SPF's ten-term lookup limit. Do not replace a managed include with a snapshot of provider IP addresses. SPF publication and processing rules.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics. Preserve the approved terminal qualifier rather than changing it to match another sender’s example.

4. Preserve DMARC and establish aligned signing

DMARC passes when at least one mechanism both passes authentication and aligns with the visible From domain. For DKIM, compare the passing signature's d= domain; for SPF, compare the authenticated envelope domain. Relaxed alignment permits a shared organizational domain. Strict alignment, requested by adkim=s or aspf=s, requires exact domain equality. Current DMARC specification.

If the From address is news@example.com, a passing DKIM signature with d=example.com aligns even under strict DKIM alignment. A passing signature with d=wordfly.com does not align with it. A signature using mail.example.com can satisfy relaxed alignment but not strict alignment for that From address.

Look up the applicable DMARC policy before editing. Preserve existing enforcement, approved reporting destinations and intentional alignment settings. If a message currently signs only with WordFly's domain, arrange custom DKIM and hold the affected campaign until alignment is fixed. Do not weaken an established organization-wide policy to compensate for unfinished onboarding.

WordFly's DMARC article distinguishes provider-only signing from signing with your From domain and recommends checking all mail streams before enforcement. Apply its monitoring advice as a new-policy rollout, not a blanket instruction to reset an existing policy. WordFly DMARC guidance.

Where no applicable policy exists, a reviewed initial policy may use v=DMARC1; p=none, with an approved aggregate-report destination added for monitoring. p=none does not itself request reports or guarantee delivery. External report destinations may require authorization. Check parent-policy effects for a subdomain and review every legitimate sender before enforcement. The current DMARC standard, RFC 9989, supersedes RFC 7489 and removes the old pct rollout tag.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. Publish that first TXT value only if no direct or applicable inherited policy exists and the domain owner explicitly approves the monitoring and review plan; use only a provisioned approved report destination.

5. Verify public DNS, then a delivered message

These are separate acceptance checks. A public key can exist before WordFly uses it, and a syntactically valid DMARC policy cannot prove that a campaign aligns.

Public DNS checks

Replace the illustrative domain and selector below with the support-issued values. These commands only read DNS:

dig +short NS example.com
dig +short TXT wordfly02._domainkey.example.com
dig +short TXT _dmarc.example.com

The DKIM answer should contain the public key WordFly supplied at the exact owner. A missing or different answer needs correction or a cache check. For a delegated subdomain, identify its authoritative nameservers rather than assuming the parent zone hosts the record.

Compare authoritative and recursive answers when results disagree. Substitute an actual authoritative nameserver in this example:

dig @ns1.dns-host.example TXT wordfly02._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT wordfly02._domainkey.example.com +noall +answer

WordFly describes DNS availability within 24 hours or faster depending on TTL. That is not a guarantee that every cache or provider-side setup is ready. Correct a wrong authoritative record immediately rather than waiting for a typo to disappear.

Delivered-message checks

After Support confirms readiness and your team authorizes testing, send a representative campaign to a mailbox you control. Inspect its raw source using the receiving mailbox's original-message view. Use the Authentication-Results added by that trusted receiver, not an arbitrary copied header. Authentication-Results trust rules.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Record these results:

1. The final visible From domain is the intended domain.
2. The customer-domain DKIM signature is present, with the expected d= and s= values, and the receiver reports a pass for it. Its d= domain must also align with the visible From domain under the applicable adkim mode, even if SPF supplies DMARC pass.
3. Any provider signature is distinguished from the customer signature.
4. SPF is evaluated for the actual smtp.mailfrom domain; look up that domain's TXT policy when investigating SPF, not automatically the From domain's policy.
5. The receiver reports dmarc=pass for the intended header.from, with an identifiable aligned passing mechanism.

Investigate SPF failures independently even when aligned DKIM makes DMARC pass. For spf=fail or softfail, verify the connecting IP and actual envelope domain with Support; for permerror, check multiple policies, invalid syntax and excessive lookup terms at that owner; for temperror, investigate DNS availability and retry after the transient fault clears. Do not broaden a root SPF record when the receiver evaluated a provider-owned domain.

Repeat for materially different From domains or sending paths. A single successful campaign does not establish the state of employee mail or every other platform sharing the domain. Retain the date, route and relevant authentication evidence securely; redact personal information before sharing a diagnostic sample.

Keep each signature’s actual selector and signing domain paired as described in EmailAuth’s DKIM selector guide. Require the active WordFly-issued customer signature itself to pass and align under effective adkim with the unchanged intended From, plus trusted receiver dmarc=pass; an unrelated aligned signer or rewritten provider From is not completion.

Troubleshooting WordFly authentication

WordFly's sending guidance covers consent, list maintenance and responsible sending practices. Authentication supports those practices; it cannot compensate for unwanted mail. Sending best practices.

Before launch, the campaign owner must separately confirm subscriber permission, a working unsubscribe link and an appropriate IP warm-up plan. DNS authentication does not complete these campaign-readiness checks. WordFly sending requirements.

Keep the affected campaign on hold until the campaign owner accepts a successful final-content retest. Preserve old selectors needed for queued mail during a coordinated rotation, and retire dormant selectors only after checking dependencies with Support. DNS repair does not authorize deleting the provider signature or changing unrelated routes. RFC 9989 section 7.4 requires valid DKIM for p=reject domains and cautions about indirect and mailing-list delivery; assess all legitimate sources before separately approved enforcement. Interoperability requirements.