FeedBlitz DKIM setup is not finished when its CNAME exists in DNS. Create the domain’s profile, publish the exact issued record, obtain a successful validation result, and then change the profile status to active - CNAME. Finally, verify an actual newsletter message from the intended From address.
This guide covers FeedBlitz’s native publisher/list email route, not its separate transactional API. The current publisher SPF authorization is include:mail.feedblitz.com; do not substitute a transactional-service include or a remembered record from another product. FeedBlitz’s publisher authentication instructions.
No customer account, DNS change, newsletter send or receiving-header test was performed.
Before changing a publisher domain
Confirm the FeedBlitz account, intended list/newsletter, visible From address and domain owner. Locate the authoritative DNS operator, which may differ from the registrar and website host. The reviewed instructions do not establish a universal paid-plan or administrator-role requirement; if the controls are unavailable, confirm access with FeedBlitz instead of inventing an upgrade or permission bypass.
Have the responsible administrator inventory existing SPF and DMARC policies, DKIM selectors, CNAMEs and delegated namespaces. Save the approved configuration and agree the exact changes. A pre-existing feedblitz selector might already be serving mail; do not delete or repoint it merely to recreate a profile.
The workflow below authorizes signing DNS, not a website migration or inbound-mail change. Stop if an unexpected request would replace MX, nameservers, forwarding, tracking destinations or security settings. Resolve the actual purpose and obtain separate owner approval before changing a route. No such routing change is established as necessary by the reviewed publisher instructions.
Create the DKIM profile, but leave it inactive
From the Welcome menu, open SPF, DKIM Authentication, then the DKIM Authentication tab. Enter the intended domain without a URL scheme. Use the default feedblitz selector unless a supported alternative is deliberately required. Choose Create a New DKIM Profile. The new profile starts inactive.
Copy the current profile’s DNS instructions, keeping the owner, record type and target separate. This publisher procedure uses a CNAME, not a public-key TXT record. Do not copy a screenshot’s example domain or convert the alias into a different type. The platform supplies the signing configuration; do not generate and upload your own private key as a shortcut. Official profile and DNS procedure.
Publish the alias at the correct DNS owner
For the default selector and an illustrative From domain example.com, the expected owner structure is feedblitz._domainkey.example.com. Use the actual domain and selector issued for your profile, not this example literally. At a DNS editor managing example.com, the relative host may be feedblitz._domainkey.
If the sending domain is news.example.com, its illustrative owner is feedblitz._domainkey.news.example.com. In the parent zone that may be entered as feedblitz._domainkey.news; in a separately delegated news.example.com zone, it may be feedblitz._domainkey. If _domainkey.news.example.com is separately delegated, work with that authority. Confirm the editor’s full-name behavior so the domain suffix is not appended twice. DNS authority and delegation.
A CNAME owner cannot also contain ordinary TXT, A, AAAA, MX or another CNAME. Do not remove an existing selector or delegation to make the tutorial fit. Ask FeedBlitz and the DNS administrator for a supported non-conflicting arrangement. Preserve other services’ selectors. DNS record representation.
For Cloudflare, keep the DKIM alias DNS-only rather than HTTP-proxied. Also check applicable per-record, zone-wide, apex and same-zone flattening behavior. Where the validator requires a literal CNAME answer, turn the relevant per-record Flatten control off when available and ensure applicable settings do not suppress that alias. Do not disable unrelated zone features globally. If mandatory apex or same-zone behavior cannot preserve the required answer, stop and coordinate a supported configuration. Cloudflare’s current flattening controls.
Reconcile the publisher SPF authorization
FeedBlitz’s publisher procedure calls for include:mail.feedblitz.com. If an SPF policy already exists at the applicable owner, integrate that authorization before its terminal all while preserving other legitimate senders and the approved qualifier. Never paste a second v=spf1 policy or blindly replace an existing apex policy.
SPF evaluates the SMTP MAIL FROM domain, or HELO in relevant cases, not automatically the visible From. A successful check of the domain entered in FeedBlitz does not establish which envelope domain an actual newsletter used. This guide does not establish a custom Return-Path control or promise a universal envelope identity. SPF identity and processing rules.
If no SPF policy exists at the intended owner and the mail administrator approves this as the sole sending authorization, the vendor’s publisher example is v=spf1 include:mail.feedblitz.com ~all. Treat that as a conditional starting policy, not a replacement for an existing multi-sender setup. For a child sending domain, review that child’s policy separately; SPF is not inherited from its parent.
The limit is ten evaluated DNS-dependent terms, including nested mechanisms, not ten top-level includes. An all mechanism causes redirect to be ignored, and mechanisms after all cannot provide the intended authorization. Check the resulting syntax and lookup budget before sending. Neither ~all nor -all guarantees a particular recipient delivery decision.
In FeedBlitz’s first authentication tab, enter the domain and use Check Now for its SPF configuration check. Keep that result separate from DKIM profile status and receiving-message evidence. FeedBlitz SPF check.
Preserve DMARC policy before activating signing
Inspect the direct policy and any applicable inherited policy for the intended From domain. An empty query at one _dmarc owner can reflect inheritance or a DNS problem; it is not permission to introduce an override. Preserve existing enforcement and authorized reporting destinations. Do not change reject or quarantine to none merely to make a test easier, and do not add duplicate DMARC policies.
Only if no direct or applicable inherited policy exists, the domain owner approves and a monitored introduction is appropriate, a first TXT policy may be v=DMARC1; p=none. For From example.com, the full owner is _dmarc.example.com; for From news.example.com, it is _dmarc.news.example.com. The latter is _dmarc.news relative to the parent zone or _dmarc within the delegated child zone. This minimal record requests no reports. Do not use the obsolete pct parameter for rollout. Current DMARC policy standard.
Report destinations require a separate privacy and data-sharing decision. When the report destination’s Organizational Domain differs from the Organizational Domain of the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted. Protocol authorization does not replace the domain owner’s approval. RFC 9990 section 4.
Validate first, then activate the correct profile
Use Check DKIM is OK and the linked FeedBlitz validator. Resolve any failure before changing the profile to active - CNAME. The public screenshot shows an inactive profile and a separate activation dropdown: DNS publication, validation and activation are distinct stages. Official validation and activation instructions.
The provider allows for DNS propagation delays of up to 48 hours, but waiting is not a substitute for a successful check. Compare the exact profile owner and target with authoritative DNS, then consider cached resolver responses. Fix a wrong zone, doubled suffix, conflicting owner, hidden alias or incorrect target rather than waiting indefinitely.
Do not repeatedly delete and recreate a working profile or switch an active route while queued messages and other dependencies are unknown. If the current account differs from the documented controls, obtain the applicable procedure from FeedBlitz instead of assuming a replacement toggle.
Verify the real newsletter, not just the dashboard
After approved publication and activation, send only an authorized small test through the intended native list/newsletter route to controlled valid recipients. Do not release a scheduled production mailing, add customers to a test list, resubscribe opted-out contacts or use the transactional API as a substitute. A preview screen does not prove the production sender’s authentication.
Inspect the original received message using the receiving service’s known processing boundary and its documented treatment of externally supplied Authentication-Results. Ask its administrator for a trace if necessary. A familiar authserv-id string or header position alone is not proof of trust; ignore attacker-inserted result fields. Authentication-Results trust boundary.
Record the actual visible From, SMTP MAIL FROM, intended FeedBlitz signature’s d= domain and s= selector, and trusted SPF, DKIM and DMARC results. Acceptance for this branded setup requires the intended FeedBlitz signature to pass and align with the intended From, plus trusted dmarc=pass. A rewritten provider From or an unrelated passing signature does not authenticate the intended brand.
DMARC can pass through either aligned SPF or aligned DKIM, but a pass through SPF alone does not prove this DKIM setup works. Relaxed alignment compares Organizational Domains. Strict adkim requires an exact DKIM-domain match; strict aspf requires an exact MAIL FROM-domain match. A child envelope domain can align relaxed and fail strict. See raw DKIM versus aligned DKIM results.
Investigate SPF fail, temporary DNS errors and permanent policy or lookup-budget errors separately even if DKIM supplies DMARC’s pass. Authentication is not an inbox-placement guarantee and does not eliminate filtering, consent or reputation requirements.
Troubleshooting without weakening protection
CNAME exists, but DKIM is absent: check whether the matching profile is still inactive and whether the actual newsletter uses its domain. Ask FeedBlitz to investigate signing if the documented activation is complete.
The profile will not validate: compare exact current values and authority. Check for a selector collision, duplicate suffix, proxy or flattening. Do not publish TXT at the same alias owner or remove an NS delegation blindly.
DKIM is present but fails: compare the intended selector and key resolution, then investigate downstream message modification with the responsible administrators. Do not disable required security or compliance controls to preserve a signature.
DKIM passes but DMARC fails: compare the actual d= with From under the current alignment policy. Do not weaken DMARC or accept an unrelated provider signature as branded success.
SPF is a permanent error: inspect duplicate policies, syntax and the evaluated lookup budget. Do not remove unrelated authorized senders or replace includes with guessed IP addresses.
A recipient rejects the message: read the actual diagnostic response. DMARC failure alone does not prove the rejection cause. Suppressions, recipient policy and consent issues require separate investigation.
If a change disrupts service, pause the affected workflow where safe and coordinate restoration to the last approved state. Retain records until queued mail and shared dependencies are understood. Share only necessary redacted domain, selector and diagnostic evidence with approved support recipients, never passwords, private keys or unrelated customer correspondence.