Ubivox SPF, DKIM and DMARC setup, step by step

On Ubivox's new platform, authenticate the sender through its sender profile: verify the mailbox, retrieve the profile's current DNS instructions, publish the approved records, and run Check DNS. Use the values for your actual account. Ubivox's current public SPF explanation and embedded setup screenshots disagree on the include hostname, so there is no safe universal SPF value to copy from those examples. Current sender-profile instructions; SPF explanation.

This guide covers the new-platform newsletter workflow documented at guides.ubivox.com in 2026. It does not reuse the legacy account/list DKIM instructions, assume a transactional SMTP route works the same way, or treat tracking-domain branding as a custom Return-Path feature. No customer account, DNS or delivered email was tested.

Check the platform and sending prerequisites

Make sure you are using the new platform and can manage the sender profiles, access the sender mailbox and coordinate changes with the authoritative DNS owner. The reviewed current setup pages do not name a universal plan requirement or exact permission role. If the controls are unavailable, ask your administrator or Ubivox Support to confirm the account's access and activation state.

Migrating from the old platform adds a separate account-activation step. Ubivox's June 8, 2026 migration guide says the transfer can include sender profiles and DKIM setup, but Support must activate the new account and deactivate the old one when you are ready. The request must come from the new account administrator's email address. Imported settings alone do not prove the new sending route is active or authenticated. New-platform migration and activation.

Choose the intended From address, such as newsletter@example.com, on a domain you control. Record the existing SPF, DKIM selectors, DMARC policy and applicable inheritance before making changes. Keep your normal mailbox provider, other marketing tools and existing selectors intact. You cannot authenticate a public mailbox-provider domain you do not control by editing your own unrelated DNS zone.

Create and verify the sender profile

The current guide is Danish. The original labels below help you find the controls; the English descriptions are translations, not claimed English menu labels.

1. Open the gear menu at the top right and choose Afsenderprofiler (sender profiles).
2. Choose Opret ny afsender (create a new sender).
3. Enter Afsendernavn (sender name), keep the type as E-mail, and enter the actual sending email address.
4. Supply Reply to only if replies should go to a different mailbox. Otherwise leave that optional field empty.
5. Save using Gem afsender (save sender).
6. Open the verification message delivered to that sender mailbox and follow its confirmation link.

The sender address is then marked green. This proves completion of the mailbox-verification step, not DKIM signing, SPF alignment or DMARC success. The same guide explicitly follows it with SPF and DKIM configuration. Sender-profile creation and verification, August 13, 2026.

Keep the sender mailbox and Reply-To monitored. A friendly display name and a working reply address do not establish which domain SPF evaluates or which domain DKIM signs.

Retrieve the records from the actual profile

Open the item menu beside the intended sender profile and choose Rediger afsender (edit sender). The current guide says this view includes the profile's SPF and DKIM information. The menu also provides Send DNS, which can email DNS instructions to your technician. Use an authorized recipient and compare the current instructions rather than forwarding an old screenshot. Where to obtain the DNS information.

For each required record, capture the exact type, owner, value and applicable domain. Do not copy the sample key or sample Ubivox-owned selector hostname from a help image. The DKIM public key must belong to the current sender configuration; private keys must never be published.

Resolve the conflicting SPF examples before publication

There are three different values in the current public material:

• The January 15, 2026 SPF article recommends include:spf.ubivox.com.
• The sender guide's Send DNS screenshot shows include:send.ubivox.com.
• Its edit-sender screenshot shows include:spf.ubivox.com in one place and an existing-record instruction referring to include:send.heyloyalty.com in another.

These are conflicting source examples, not a list of records to add. Do not install all three, silently select one, or treat Heyloyalty as a documented alias for your Ubivox sending service. SPF article; sender guide and its screenshots.

Use a consistent, current instruction generated for your actual profile. If the profile and its Send DNS message disagree, if an instruction names another product, or if you cannot establish the intended include and owner, pause the SPF change and obtain confirmation from Ubivox Support. Include the account/platform, sender domain and contradictory instructions. Public DNS resolving for a hostname does not prove that it is the correct authorization for your account.

This conflict does not require inventing a different setup route: the documented process is still profile records followed by Check DNS. It does require treating universal copy-and-paste SPF recipes as unverified.

Understand Ubivox SPF and DMARC alignment

Ubivox's current SPF explanation says that Ubivox is the envelope sender, while the customer appears in the visible From. It says Ubivox maintains SPF on its envelope domain. Adding Ubivox to the customer's From-domain SPF is described as a delivery-compatibility recommendation, particularly for Microsoft, rather than a technical prerequisite for Ubivox's own envelope-domain SPF. Ubivox's envelope-sender explanation.

That recommendation must still be reconciled with the actual new-platform profile instructions and the conflicting examples above. It does not change the SPF identity. A From-domain include cannot make an unrelated provider-controlled envelope domain align with your brand.

Do not infer the exact emitted envelope hostname from the SPF include hostname. Also do not assume a branded tracking domain changes the envelope sender. The reviewed new-platform sources do not establish a current custom Return-Path feature. Validate the actual identities in a delivered newsletter. SPF identity rules; DMARC alignment.

For the documented provider-managed envelope route, an SPF pass can be unaligned while branded DKIM provides the aligned path. A real spf=fail, temperror or permerror is still a fault to investigate, not an expected synonym for nonalignment.

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

Publish SPF and DKIM without disrupting other senders

Use the authoritative DNS service, which may differ from your registrar or website host. Save the previous records and note the TTLs before applying the account's verified instructions.

Safely merge the confirmed SPF mechanism

Publish SPF as TXT at the exact instructed owner. If a v=spf1 record already exists there, edit that policy rather than adding a second. Preserve other authorized senders and the intended terminal qualifier; insert the confirmed include before all. If the policy uses redirect=, have its maintainer review the evaluation logic. Do not overwrite the entire policy with a single-provider example.

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.

For a new owner with no SPF policy, use the complete approved account/Support instruction. This guide deliberately does not provide a universal Ubivox record while the public examples conflict. A parent domain's SPF policy does not automatically apply to its subdomains. Unrelated TXT records should remain.

Check the whole SPF evaluation against the ten lookup-causing-term limit, including nested includes and redirects. a, mx, exists and ptr also consume that budget; ip4, ip6 and all do not. Too many terms can cause permerror even when a DNS dashboard accepts the text. Do not add every competing example or replace a managed include with a static IP list as a quick fix. SPF publication and lookup limits.

Publish the profile's DKIM public key

Ubivox explains that the public key goes in DNS while the private key remains in the sending system. The current edit-sender illustration shows a TXT-based key. Copy the current profile's full owner and value, not the illustration's hostname or key. Current DKIM explanation; profile DNS view.

For illustration only, suppose your account assigns selector campaign for the domain news.example.com. Its DKIM owner would be campaign._domainkey.news.example.com. In an example.com zone, an editor that appends the zone might take campaign._domainkey.news; in a delegated news.example.com zone, it might take campaign._domainkey. Neither the selector nor this domain is a value to copy unless your own configuration matches.

At an existing delegated _domainkey.news.example.com authority, that illustrative campaign._domainkey.news.example.com owner maps to relative campaign. Use the actual issued selector and preserve existing NS delegation and other selectors. Relative names.

Do not overwrite an existing key at that owner. Resolve collisions with Ubivox and the other sender's owner. Preserve all key characters and tags; if your DNS interface splits a long TXT value into multiple strings within one record, the reconstructed value must remain identical. Follow the DNS host's actual input rules rather than adding screenshot-specific escaping universally.

A CNAME cannot coexist with an ordinary TXT key at the same owner. If your current account unexpectedly supplies a CNAME-based configuration instead, confirm that supported variant with Ubivox before substituting it for the documented TXT-style example. For that confirmed CNAME variant only, publish the alias as DNS-only where applicable and keep its per-record Flatten option off. Ensure a zone-wide flatten all CNAMEs setting does not suppress the alias or override the record setting; verify that public DNS returns the required literal CNAME. Coordinate any shared-zone change with the DNS owner and affected service owners rather than altering global behavior for one record. Preserve legitimate child-zone or _domainkey NS delegation and publish in its authoritative zone, not by deleting the delegation. These proxy/flattening instructions do not apply to the documented TXT key. DNS alias constraints; CNAME flattening behavior.

For that confirmed CNAME variant only: Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

This sender-profile process does not establish a need to move your incoming mail. Do not replace your mailbox-provider MX records or redirect unrelated website records to make an authentication indicator change.

Retain DMARC policy and reporting safeguards

Find the policy applicable to the visible From domain, including inherited protection. Preserve existing enforcement, alignment modes, subdomain decisions and reporting destinations. Do not copy the public Ubivox DMARC example's reporting addresses: those belong to an illustrative reporting setup, not your organization. Ubivox DMARC guidance.

Only if no direct or inherited policy applies, and the domain owner approves an initial observation policy for example.com, publish a TXT record at _dmarc.example.com with:

Before that first policy is published, the domain owner must approve a monitoring and review plan. A bare p=none value does not itself collect reports or provide monitoring; agree how results will be observed and reviewed without forcing an unapproved rua recipient.

v=DMARC1; p=none

This requests neither enforcement nor reports. It is not a delivery guarantee. To collect aggregate reports, add your approved rua destination after deciding access, retention and processing arrangements. A destination outside the applicable organizational domain requires appropriate receiving-domain authorization. Failure-report collection can expose more message-specific information and should not be enabled by default. DMARC policy; external aggregate-report authorization.

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.

Keep strict adkim or aspf decisions intact. Strict alignment needs an exact domain match; relaxed alignment follows the applicable organizational-domain relationship. Resolve unsupported sender designs with the domain owner and Ubivox, not by quietly weakening policy. Before moving toward quarantine or reject, inventory and validate all legitimate senders, including normal business mail.

Run Check DNS and inspect a delivered newsletter

After publication, inspect the exact records at authoritative nameservers and a recursive resolver. With the illustrative DKIM domain above, read-only queries would be:

dig +short TXT news.example.com
dig +short TXT campaign._domainkey.news.example.com
dig +short TXT _dmarc.news.example.com

Replace every example with the actual owner. Check the approved SPF mechanism, complete DKIM key, applicable DMARC policy and any inheritance. If resolvers disagree, consider delegation, TTL and negative-cache timing before making another edit.

Return to Afsenderprofiler, open the intended profile's item menu and run Check DNS. Ubivox says updates can take up to 24 hours, usually less than an hour. That is a provider allowance, not proof that a bad record will eventually become valid. Its current guide says the profile is ready to send when this check succeeds. Current validation step.

Then use the intended profile on a representative newsletter and deliver a fresh message to controlled test inboxes. Confirm that the account itself is activated if you migrated. Test the real newsletter route, not only a message sent manually from the sender's ordinary mailbox. Ubivox's testing guide also distinguishes preview/test messages from real list sends: for example, unsubscribe behavior requires a real send to a suitable internal list. Ubivox test guidance.

What counts as a successful authentication test

Use original headers or a receiving-server trace from infrastructure you control or trust. The receiver must distinguish its own Authentication-Results from fields supplied by an outside sender. An attacker can insert a convincing field or authserv-id; matching the text of the name is insufficient. If provenance is uncertain, use a separate trusted mailbox or trace. Authentication-Results trust boundary.

Establish the actual receiver’s known processing boundary and its documented removal, ignoring or reliable distinction of externally supplied Authentication-Results before relying on the result. Require the intended active sender-profile signature, matched by its d= and s=, to pass and align under effective adkim with the unchanged intended visible From, plus trusted receiver dmarc=pass. Receiving boundary, alignment.

Record these outcomes together:

1. The delivered From matches the intended sender profile's brand domain.
2. The intended Ubivox sender-profile DKIM signature verifies, its d= aligns with From, and its s= resolves to the expected profile key.
3. The trusted receiver reports DMARC pass for that From domain. A pass supplied by an unrelated second signature or SPF does not establish that the intended DKIM setup works.
4. SPF's actual envelope identity and result are recorded separately. Provider-domain SPF pass without alignment can fit the documented route; SPF errors still need investigation.
5. The selected reply destination works and no unrelated sender was broken by the DNS change.

For multiple signatures, EmailAuth's raw DKIM versus aligned DKIM guide explains how to keep each selector, signing domain and result together. A green mailbox-verification badge, a successful Check DNS result and a delivered-message authentication result are three different observations.

Troubleshooting the new Ubivox workflow