Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Resolve the domain instructions before publishing
Hellodialog sender activation and domain authentication are separate controls. A confirmation link establishes access to a mailbox; it does not prove that a newsletter will pass DMARC at its destination. This guide covers customer-domain newsletters sent through Hellodialog. It does not establish a separate transactional API route or a supported custom Return-Path feature.
There is an important documentation conflict. Hellodialog’s sender-addition article describes a support-issued DKIM CNAME, while its authentication article describes two TXT selectors named hellodialog1 and hellodialog2. Neither example is a safe substitute for tenant-specific instructions. Ask support to confirm the complete owners, record types, values and activation requirements for the intended sending domain before making a DKIM change. Do not publish both designs as a hedge. Sender setup and authentication setup.
Assign a campaign owner and a DNS owner. Record the current From address, reply destination, domain policy and scheduled campaigns. If this is a rebrand, retain the working sender until the replacement passes the acceptance test. Avoid introducing the new domain into every automation at once: a single controlled campaign gives a much clearer diagnostic result.
Activate the address and reconcile DNS
In Hellodialog, open Instellingen > Verzenders, add the sending address and complete its emailed confirmation. Both first-party pages identify include:spf.hellodialog.com as the SPF authorization; merge it into an existing policy rather than creating another SPF record. The authentication page says to allow a day before its domain-record check. Domain authentication instructions.
For the approved DKIM design, write out each complete DNS owner before entering it. A DNS host that appends the zone can accidentally create a doubled domain. Check for existing data at every proposed owner and preserve unrelated selectors. A CNAME and TXT record cannot simply be stacked at the same owner. Never copy a truncated public-key example or another company’s example domain into production.
Keep one SPF policy per owner and apply RFC 7208 §4.6.4: at most ten evaluated DNS-causing terms, including nested evaluations, rather than ten packets or ten visible includes. Publish DMARC as a separate TXT record at the applicable _dmarc name. Do not adopt a quarantine or reject example solely because it appears in a vendor article: the policy also affects legitimate senders outside Hellodialog. Inventory those senders, inspect reports and follow an approved enforcement plan. A monitoring policy is not, by itself, proof that a message must go to spam. SPF and DMARC.
Prove the newsletter identity at the receiver
Original acceptance worksheet, not a completed test: send a harmless newsletter through the intended campaign workflow to controlled external recipients. For each received copy record the timestamp, workflow, visible From domain, Return-Path, trusted SPF result and evaluated domain, every DKIM d= and s= pair, and the trusted DMARC result. Retain the message source securely; redact personal content in any shared report.
Evaluate the domain relationship as well as each pass result. An SPF pass for an unrelated provider envelope is not an aligned SPF pass. A valid signature must use an appropriately aligned signing domain to satisfy DMARC through DKIM. A reply reaching the expected mailbox is another acceptance condition, but it cannot replace authentication evidence. Inspect the actual message rather than inferring its identities from the DNS configuration screen.
Recover without disrupting working campaigns
If address activation fails, check mailbox access and the confirmation flow. If a key cannot be found, compare the published owner, type and value against the support-approved instructions before changing the campaign. If DKIM passes but DMARC fails, compare signing and From domains, including the domain’s alignment settings. Stop the new sender rollout while investigating; use the previous verified route only if it remains approved and operational.
This is a documentary procedure. No tenant setup, DNS publication or received-message test was performed. Close the change only after the conflicting DKIM instructions are resolved for the account and real-message evidence is attached to the change record.
Route acceptance record
Complete this proposed worksheet with real evidence; blank fields are not passes.
- Account, sender domain, exact workflow and responsible owner: ____.
- Provider-approved record design and dated instructions: ____.
- Existing SPF/DMARC policy and preserved selector dependencies: ____.
- Authoritative owner/type/value answers and observation time: ____.
- Actual From, envelope, all signing domains/selectors and receiver results: ____.
- Reply destination and controlled functional result: ____.
- Unresolved scope, rollback trigger and human approval: ____.
Live account and message checks, visual inspection and owner/SME approval remain open publication gates.