promio.connect SPF, DKIM and DMARC setup, step by step

To authenticate native promio.connect email, register an exclusive sending domain under Settings → Domains, choose Simple or Advanced, and publish the account's Expected DNS records. Simple uses an issued CNAME at the sender domain; Advanced uses issued MX and SPF records. Both require the separately issued DKIM TXT record. Complete DNS validation and allow promio's automatic system configuration before testing a branded message.

This is a fee-based domain-registration workflow inside promio.connect, not a domain purchase. The public manual does not specify the fee or a universal SPF include, selector or key. Obtain those details from your account. This guide excludes External SMTP Relay, where your own infrastructure sends the mail and promio support configures a different route.

The [current domain manual](https://servicewiki.promio-connect.com/doku. No account registration, payment, DNS change or sending test was performed for this guide.

On this page

• Choose an unused sending domain and the right mode
• Register the domain and obtain its records
• Publish the mode-specific DNS
• Add DKIM without breaking an existing key
• Apply the current DMARC requirement safely
• Validate DNS and wait for system configuration
• Handle replies and verify a native message
• Troubleshooting and safe rollback
• Frequently asked questions

Choose an unused sending domain and the right mode

Use a dedicated company-controlled subdomain, such as news.example.com, reserved for mail sent through promio.connect. The provider warns against sharing the same sending domain with other uses. For an existing main company domain, its guidance is to reserve a subdomain rather than disrupt everyday company mail.

Also choose a separate tracking hostname, such as go.example.com, for the Redirect URL configuration. The sender and tracking domains must differ for a new setup. A historic exception involving an old A-record configuration is not a reason to combine them now.

The manual's mode choices are:

• Simple: an exclusive, unused sending subdomain, not already serving a website or another service. Its sender-domain CNAME lets the provider supply the corresponding DNS data.
• Advanced: needed for a non-subdomain, or when the sender hostname also serves a website or you need control over individual records. This is not permission to replace an occupied company's mail routing: review the issued MX requirements first.
• External: a separate, support-configured SMTP-relay arrangement using your infrastructure. Do not select it as a shortcut around a failed native authentication setup.

Have authorized access to Settings → Domains and to the authoritative DNS zones, plus approval for the registration charge and any mail-routing change. No narrower named role or plan entitlement is established by the public manual. Record existing DNS, mail flows, sender identities and reply handling before making changes.

Register the domain and obtain its records

1. Open Settings → Domains and use the green Create domain button.
2. Enter the intended sender domain and the separate Redirect URL. Confirm the spelling and which hostnames will be affected.
3. Select Simple or Advanced based on the actual DNS and mail-routing requirements.
4. Review the fee and complete the authorized registration. Adding a domain here makes it available for sending; it does not buy the domain or create a mailbox.
5. Open the resulting domain detail page. Copy the exact full owners, types, values, targets and MX priorities shown under Expected.

Keep the current account packet as the change record. Do not copy another customer's public key, a screenshot target or an old promio.mail record. Promio's 2017 relaunch announcement establishes the product lineage, not compatibility with a legacy DNS recipe.

Publish the mode-specific DNS

Simple: sender-domain CNAME

At the exact sender-domain owner, publish the CNAME shown under Expected. For the illustrative sender news.example.com, a parent-zone panel might expect relative name news; a full-name panel expects news.example.com.

Do not add an SPF TXT record or MX at that same CNAME owner. A CNAME cannot coexist there with ordinary TXT, A, AAAA or MX data. Simple does not mean “add the Advanced SPF record as well.” Its separately issued DKIM owner is a different name and must still be configured.

A sender-domain CNAME is not an instruction to replace the company's authoritative nameservers or delegate the whole parent zone. If the chosen owner is a zone apex or already has conflicting data, stop and resolve the mode and hostname with promio and the DNS administrator rather than deleting records to make it fit.

Advanced: the approved MX set and SPF policy

Publish the MX servers shown under Expected at the exact sender-domain owner. Promio requires the listed MX records to have equal priority, giving 10 as an example. Use the current account's instructions and confirm the complete approved MX set, not just that one new target appears.

Changing MX changes where incoming mail goes. Do not leave unrelated old MX records mixed with a new intended set, or remove existing MX records without an approved migration. Choose an unused sending subdomain if the company's current mail service must remain untouched.

Publish the issued SPF TXT policy at the specified sender owner. There is no universal promio include to infer. If that owner already has SPF, reconcile the proposed authorization with its administrator into one v=spf1 TXT policy, preserving every legitimate sender and the intended qualifier. An existing multi-sender policy may also mean the domain does not meet promio's exclusive-sender requirement.

Review mechanisms such as a and mx if present: they authorize the corresponding hosts, not just promio by name. Do not casually change -all to ~all or the reverse. Neither qualifier dictates guaranteed delivery or rejection. Also, adding any all mechanism makes SPF ignore an existing redirect=, potentially removing its delegated authorizations.

SPF allows 10 evaluated DNS-dependent terms, including nested terms reached through include and redirect, not simply ten visible includes. Preserve that budget when reconciling an existing policy. See RFC 7208.

Both modes: separate tracking CNAME and correct owners

Publish the CNAME - Redirect URL target shown by promio at the separate tracking owner. A DNS CNAME target is a hostname, not a URL: do not paste https://, a path or the entire user-interface URL into the DNS target field.

Map all full owners into the zone actually authoritative for them. For example:

Issued full DKIM owner: SELECTOR._domainkey.news.example.com
In parent zone example.com: SELECTOR._domainkey.news
In delegated zone news.example.com: SELECTOR._domainkey

SELECTOR is a placeholder for the issued selector. If the _domainkey namespace itself is delegated, use its authoritative service rather than creating a parent-zone shadow record. Preserve existing selectors and NS delegations; do not delete them blindly. RFC 1034 explains CNAME ownership restrictions.

Keep verification CNAMEs visible as literal DNS aliases. On Cloudflare, use DNS only and turn Flatten off for each issued alias where that per-record control is available. Also check whether whole-zone flattening, apex handling or same-zone-target behavior suppresses its CNAME answer. Ensure the applicable settings preserve the issued alias; DNS only does not establish this by itself. If a shared setting or delegated namespace is involved, coordinate a record-specific solution with the DNS administrator and promio. Preserve delegations and unrelated records rather than disabling global features blindly. See proxy status and flattening controls.

Add DKIM without breaking an existing key

DKIM is mandatory for native promio.connect sending. Publish the complete Expected public-key TXT value at its exact issued owner, including all supplied tags. Do not create a generic selector or supply a key pair generated elsewhere. The private signing key stays with the signing service.

The current manual says domains created after 1 February 2026 use 2048-bit keys. When promio instructs an existing domain to add the new 2048-bit record, it explicitly says to add it alongside the old 1024-bit record, not overwrite the old record. Use the issued distinct owner; if instructions appear to require two competing keys at the same owner, clarify them before editing.

A long public key can be stored as multiple TXT character strings of at most 255 characters within one DNS record. The strings concatenate without added spaces. Do not truncate the key, insert line-break characters into its value, or create two separate TXT records to hold its halves. RFC 6376 describes the DKIM key namespace and TXT concatenation.

If your organization actually uses TrustedDialog, promio says a 1024-to-2048-bit change must also be coordinated with UIM/TrustedDialog. That is a separate service-specific step, not something every customer must enable.

Apply the current DMARC requirement safely

The manual retains an older paragraph calling DMARC optional, but its dated rule makes DMARC mandatory for new domains from 1 July 2026. Existing domains can continue sending with a warning. Use the newer rule for a new registration.

First determine the effective DMARC policy for the intended From, including applicable ancestor policy. Preserve existing enforcement, alignment settings and authorized reports. Do not replace a working policy with a provider example or publish a second DMARC policy. If promio's validator disagrees with a valid inherited policy, resolve that discrepancy rather than silently overriding enforcement. RFC 9989 governs current policy discovery and alignment.

Only if no direct or inherited policy applies, and the domain owner approves initial monitoring with a review plan, this minimal first policy is suitable for the illustrative From domain news.example.com:

Type: TXT
Full owner: _dmarc.news.example.com
Relative name in parent example.com: _dmarc.news
Relative name in delegated news.example.com: _dmarc
Value: v=DMARC1; p=none

A timeout or SERVFAIL is not proof of policy absence. Do not add a local TXT at an owner already managed through a CNAME. The minimal policy requests no reports because it has no rua.

Before adding report destinations, approve the recipient, access and retention arrangements. Aggregate reports can expose sending infrastructure and traffic patterns. Under RFC 9990 section 4, compare the Organizational Domain where the policy was found with the Organizational Domain of the report URI's host. Different Organizational Domains require the reporting receiver to check DNS authorization; destinations within the same Organizational Domain are excepted, even with different hostnames. The external recipient normally supplies v=DMARC1 authorization at POLICY-DOMAIN._report._dmarc.REPORT-DESTINATION-HOST. Obtain the precise instruction from the reporting service. Protocol authorization does not replace your data-sharing approval.

Validate DNS and wait for system configuration

Compare authoritative DNS and public resolver answers with the account packet. Replace all uppercase placeholders in these read-only templates:

dig @AUTHORITATIVE_DNS_SERVER FULL_ISSUED_OWNER ISSUED_TYPE +noall +answer
dig @PUBLIC_RESOLVER FULL_ISSUED_OWNER ISSUED_TYPE +noall +answer
dig @PUBLIC_RESOLVER SENDER_DOMAIN MX +noall +answer
dig @PUBLIC_RESOLVER FULL_DKIM_OWNER TXT +noall +answer

Use the type actually issued. For Advanced, verify every approved MX target and its equal priority; for Simple, inspect the sender CNAME rather than adding an MX record. Check complete TXT values, alias chains and the effective DMARC policy. If answers are empty, inspect the full response without +noall +answer to distinguish negative answers from resolver errors.

Promio allows up to 48 hours for DNS changes to reach its checking nameservers. Once records are complete and correct, its detail view returns OK. Promio then performs its system-side configuration automatically, taking approximately 24 hours after successful DNS validation. These are documented estimates, not guaranteed completion times.

In Settings → Domains, green means usable, yellow means updates are needed but sending remains possible, and red means not usable. Inspect the detailed reason instead of treating every warning as the same failure. Do not invent an additional DKIM switch, and do not treat a green icon as a delivered-message result.

Handle replies and verify a native message

Registering a sending domain or creating a From address does not create a mailbox. Promio says incoming mail to the sender domain is ignored by default. Decide reply handling before using it publicly.

If the organization authorizes domain-wide forwarding, Edit system side redirect forwards mail sent to all addresses at that sender domain to the chosen destination, including replies that do not use Reply-To. Use an existing, monitored mailbox the organization controls, and approve who can receive that mail. Do not enable this optional redirect silently or confuse it with the separate tracking redirect domain.

For authentication acceptance, send a new native promio.connect message with the intended From to controlled recipients. Do not test through the excluded External SMTP route or forward an old sample. Inspect:

• The actual visible From domain, not only its display name or Reply-To.
• The intended promio signature's d= and s= from the same DKIM-Signature field.
• A trusted receiver's dkim=pass for that signature, aligned to the intended branded From.
• A trusted dmarc=pass for that From.
• The separate SPF result and actual smtp.mailfrom, including any error or lack of alignment.

SPF evaluates MAIL FROM, not automatically the visible From. Promio does not publish one universal runtime envelope identity. Under relaxed alignment, domains share an Organizational Domain; strict aspf=s or adkim=s requires exact equality for the relevant mechanism. A child envelope can relaxed-align to a parent From without strictly matching it.

Use EmailAuth's DKIM selector guide to construct the lookup from the observed s= and d=. A DMARC pass via SPF alone does not establish branded DKIM success; neither does a rewritten provider-owned From.

Use receiver-controlled authentication diagnostics, or ask the receiving mail administrator to establish which Authentication-Results fields were produced inside that service's known processing boundary. Confirm its documented handling strips or reliably distinguishes externally supplied result fields, and ignore untrusted or attacker-supplied fields. A familiar authserv-id string or header position alone cannot establish provenance. If that boundary cannot be established, the headers are insufficient evidence: repeat the controlled test at a receiver whose diagnostics can be trusted. See RFC 8601 section 7.1.

Troubleshooting and safe rollback

• Registration is incomplete: confirm the authorized fee-based registration and obtain its current record packet. Do not substitute guessed DNS values.
• Simple CNAME conflicts: check for existing TXT, A, MX or zone-apex data at that owner. Reassess the hostname or mode rather than deleting working services.
• DKIM fails after a key update: verify the full new key, exact selector and TXT concatenation. Preserve the old record until promio confirms retirement; coordinate TrustedDialog only if used.
• DNS says OK but the domain is not ready: check the system-side configuration stage and its documented post-validation delay.
• DMARC fails despite DKIM pass: compare the intended signature's signing domain with the actual From under the effective alignment mode. Fix the route, not the enforcement policy.
• SPF fails despite DMARC pass: investigate independently. fail or softfail differs from a passing but unaligned identity; temperror indicates transient evaluation trouble; permerror can indicate duplicate policies, syntax or excessive evaluated DNS terms.
• Replies disappear: check whether the optional system-side forwarding was approved and configured, and whether its destination works. DNS authentication does not create an inbox.

If a change breaks mail, pause affected campaigns and retain the packet, previous records and observed results. Restore the last approved route only after checking its current dependencies with the DNS owner and promio. Do not remove selectors still needed by queued mail, delete the new domain indiscriminately, or assume that reversing MX or CNAME changes instantly clears cached answers. Registration cancellation or refunds need separate confirmation from promio.