Vivantio SPF, DKIM and DMARC setup, step by step

To authenticate email sent through Vivantio's built-in SMTP service, preserve your existing SPF policy while adding the documented include:_spf.vivantio.com authorization where applicable, then configure the instance-issued DKIM TXT or CNAME record under Admin → Setup → Outgoing Email → SMTP Settings. Generate keys only if the instance has none, enable DKIM, publish the exact public record and save the configuration. Finish with a delivered-message test of each intended From address. A saved setting or an SPF pass alone does not prove that branded DKIM works.

This guide covers Vivantio's native outbound service, not your own SMTP server, Microsoft OAuth setup or incoming email-to-ticket routing. The newer SMTP Settings documentation, documents both native and own-server choices. Do not migrate a working route simply to follow this guide.

Before you change anything

You need administrative access to Outgoing Email and authorized access to the DNS zone that actually serves your sending domain. Vivantio's public instructions do not establish a universal plan entitlement. If Enable DKIM is unavailable, ask Vivantio Support to confirm feature access rather than creating speculative records. See its DKIM instructions.

Record the current SMTP choice, System Email Address, enabled mailbox/user From options, existing SPF policy, current DKIM selectors and applicable DMARC policy. Agree which actual sender domains this change should authenticate. Preserve a recoverable record of existing settings and records before an authorized change.

Vivantio distinguishes automated system messages from ticket-related messages. The From Address documentation explains that System Email Address supplies automated mail; ticket messages can use configured mailbox-related addresses or Mail Service settings. The current interface also exposes a user-address option. Do not assume authenticating one domain covers every address users can select.

When the mailbox-address option derives From from an incoming message's original To address, the official guide warns that a message addressed to another party with your mailbox copied can produce an unintended From. Restrict and test the permitted identities. A reply must not impersonate an unapproved domain. If you need to change From behavior, get that change approved separately and save the appropriate From Address settings; it is not a side effect of publishing DKIM.

1. Confirm that the native SMTP route is intended

Open Admin → Setup → Outgoing Email → SMTP Settings. Confirm that the approved configuration uses Use Vivantio's SMTP Server. If it uses Use your own SMTP Server, stop this native-service procedure and follow the actual sending service's authentication and authorization requirements instead.

The March 2026 DKIM page contains older migration advice concerning Microsoft authentication. The April 2026 SMTP page documents a Microsoft OAuth option for own-server connections. Neither is permission to switch routes, change credentials or alter security settings. Also, the native DKIM checkbox not applying to external SMTP does not mean that externally sent mail needs no DKIM.

2. Add the Vivantio SPF authorization safely

Vivantio's Sending Email guide gives the SPF mechanism include:_spf.vivantio.com for its native servers. This is an authorization component, not a second complete SPF record to paste alongside your current policy.

SPF evaluates the actual SMTP MAIL FROM domain, or HELO in the relevant empty-envelope case, rather than automatically the visible From address. Inventory the expected route and later inspect the actual delivered envelope identity. The public instructions do not establish a universal customer Return-Path. Do not manufacture a custom bounce domain or modify a provider-owned envelope domain.

At a customer-controlled owner where this authorization is required:

1. Read the existing TXT records and identify the single v=spf1 policy. Preserve unrelated TXT records.
2. Have the policy owner merge include:_spf.vivantio.com into that existing policy while retaining all legitimate senders and the approved terminal qualifier. Do not replace the apex policy indiscriminately.
3. Check the complete evaluated SPF dependency graph. The maximum is ten evaluated DNS-dependent terms, including nested processing, not ten visible includes. An apparently short policy can still exceed the budget.
4. Preserve deliberate redirect behavior. An all mechanism causes redirect to be ignored, so inserting all into a redirect-based policy is not a harmless edit.
5. Publish one resulting SPF TXT policy at the exact evaluated owner and verify it at authoritative and recursive resolvers.

For example, if the evaluated customer domain is support.example.com, its full SPF owner is support.example.com. In the parent example.com zone the relative owner is support; in a separately delegated support.example.com zone it is the zone apex, usually @. Do not put that policy at example.com merely because your DNS account opens the parent zone first.

The multiple SPF records guide explains why publishing another v=spf1 policy is not a valid way to add a sender. SPF's result and lookup rules are defined in RFC 7208. Neither ~all nor -all guarantees a particular receiving server's delivery decision.

3. Obtain the instance's DKIM record

In native SMTP Settings, inspect the DKIM section. If it explicitly says keys have not yet been generated, use Generate Keys. The official screenshot states that the page reloads to display them. Do not regenerate existing keys as a troubleshooting shortcut.

Select Enable DKIM to expose the instance-specific DNS information. Copy the complete owner and the chosen supported record type and content. Vivantio documents TXT or CNAME; these are alternatives, not instructions to publish both at the same owner. Use the actual record issued for your instance, not the example selector or target in a screenshot. If the intended sender domain is not represented in the issued information, resolve that with Support before activation.

For TXT, copy the entire public value, including its tags and complete p= key. Never publish a private key. For CNAME, copy the complete target hostname without turning it into an SPF include or a TXT value. Public DKIM keys verify signatures; they do not encrypt message contents. See RFC 6376.

The screenshot's vivantio1 selector and target ending in dkim.vivantio.zone illustrate an account, not universal values. Keep a change record pairing the exact issued selector, domain, type and full content with the instance you are configuring.

4. Publish at the correct DNS owner

The following is an owner-mapping example, not a usable Vivantio key. Suppose your actual packet names SELECTOR._domainkey.support.example.com:

• In the parent example.com zone, the relative owner is SELECTOR._domainkey.support.
• In a separately delegated support.example.com zone, it is SELECTOR._domainkey.
• If _domainkey.support.example.com is itself delegated, its authoritative child zone uses the relative owner SELECTOR.

Determine which zone is authoritative before editing. Preserve existing NS delegations, working selectors and shared dependencies. Do not remove delegation simply because a parent-zone editor cannot display the child records. DNS interfaces that append the zone suffix can turn an incorrectly entered full owner into a duplicated name; inspect the resulting full public owner.

For a TXT route, publish the full issued TXT value and compare its reconstructed value, including any presentation-level quoted strings. Do not add CNAME controls to a TXT-only setup.

For a CNAME route, the exact owner must not also contain TXT, A, AAAA, MX or a second CNAME. Resolve conflicts with their owner before changing them; do not delete a working signing record blindly. Use DNS-only resolution rather than an HTTP proxy. If your DNS service flattens aliases, ensure it preserves the literal issued CNAME answer: disable the applicable per-record flattening option when available and check whether whole-zone, apex or same-zone behavior also suppresses it. Change only the approved setting relevant to this record. If mandatory behavior cannot preserve the required answer, stop and coordinate a supported configuration instead of disabling unrelated zone features.

No MX change, inbound forwarding, nameserver migration or DNSSEC change is part of this native authentication procedure.

5. Save, then verify DNS and actual signing

The native configuration screen has a Save control. After the approved record publication and Enable DKIM configuration, save the settings. Do not confuse ticking the box with a persisted setting. The official flow does not establish a separate Verify button, so do not search for or invent one. If DNS is not ready, postpone the sending change rather than accepting an unauthenticated interval.

Use actual values in place of the uppercase placeholders below:

dig @AUTHORITATIVE_NS ACTUAL_SPF_OWNER TXT
dig @AUTHORITATIVE_NS ACTUAL_DKIM_OWNER TXT
dig @AUTHORITATIVE_NS ACTUAL_DKIM_OWNER CNAME
dig @RECURSIVE_RESOLVER ACTUAL_SPF_OWNER TXT
dig @RECURSIVE_RESOLVER ACTUAL_DKIM_OWNER TXT
dig @RECURSIVE_RESOLVER ACTUAL_DKIM_OWNER CNAME

Use the DKIM query type appropriate to the chosen route. A successful query exit or any nonempty response is not sufficient. Compare the exact owner, type and complete issued public key or CNAME target at authoritative and recursive resolvers. For CNAME, also check that resolution reaches the intended public DKIM key. Follow delegation when choosing the authoritative server, and allow documented TTL/cache effects before diagnosing disagreement.

With permission, send controlled tests through the actual native Vivantio workflows to valid recipients you control. Include an automated system message and relevant ticket/mailbox/user From variants. Inspect complete received headers and recipient-side evidence, not only a sent icon in Vivantio.

Use Authentication-Results produced inside the actual receiving service's known processing boundary. Establish from that service's documented handling whether externally supplied result fields are removed or ignored before its own results are relied upon. A familiar authserv-id, a topmost header or text saying pass is not proof of origin. Ignore attacker-supplied or otherwise untrusted results; if the boundary cannot be established from headers, use the receiving service's trusted message trace or equivalent authenticated diagnostic. See RFC 8601.

Accept the branded DKIM setup only when the intended Vivantio signature passes: reconcile its observed d= signing domain and s= selector with the instance-issued setup, verify alignment with the unchanged intended visible From under the actual DMARC policy, and obtain trusted receiver dmarc=pass. An unrelated passing signature or DMARC pass through SPF alone does not prove the new DKIM route works. A provider-rewritten From is not successful authentication of your intended brand.

Also inspect the actual envelope/SPF result. Relaxed alignment generally compares Organizational Domains; strict alignment requires exact domain equality. A child envelope domain does not automatically strictly align with the visible From. Apply the published adkim and aspf policy, not a presumed universal Return-Path. Current DMARC alignment is specified in RFC 9989.

DMARC: retain existing protection

Read any direct policy and applicable inherited policy before adding anything. Keep existing enforcement and authorized reporting destinations. Do not downgrade a working policy to p=none, publish a duplicate policy or treat monitoring as proof that mail is authenticated.

Only when no applicable policy exists, the domain owner approves and there is an appropriate monitoring plan, a first monitoring policy can be considered. For the example From domain support.example.com, its TXT owner is _dmarc.support.example.com: relative _dmarc.support in the parent zone, or _dmarc in a separately delegated support.example.com zone. For an apex From domain example.com, the TXT owner is _dmarc.example.com, entered as relative _dmarc in an example.com zone editor that appends the zone suffix. A minimal illustrative value is v=DMARC1; p=none. This is not a recommendation to replace existing protection or a complete reporting rollout by itself.

Add reporting destinations only after the owner approves the data-sharing and privacy implications. If a report destination is in a different Organizational Domain from the Organizational Domain of the domain where the policy was discovered, the report-generating receiver must check DNS authorization. Destinations within that same Organizational Domain are excepted; a different hostname alone does not make it external. See RFC 9990, section 4. Protocol authorization does not replace the owner's permission to share reports. Do not copy another company's reporting address.

Troubleshooting Vivantio authentication

Enable DKIM is missing. Confirm that this is native SMTP and that your administrator has the appropriate feature access. Ask Vivantio Support about the instance. Do not solve this by switching SMTP services without authorization.

DNS looks correct but DKIM fails or is absent. Check the actual issued selector and domain, complete key, authoritative zone, DNS type, saved Enable DKIM setting and real outgoing route. For CNAME, inspect conflict/proxy/flattening behavior. A matching key for a different selector is not enough. If the native service still does not sign as issued, escalate with sanitized headers and exact public record evidence, not private credentials.

SPF fails even though DKIM gives DMARC pass. Diagnose independently at the observed envelope identity. fail or softfail indicates that the connecting sender is not authorized by the evaluated policy; inspect route and preserved authorizations. temperror indicates a transient evaluation/DNS availability problem. permerror indicates a permanent policy problem such as invalid syntax, multiple SPF policies or an exceeded lookup budget. DKIM-based DMARC success does not make those faults harmless.

Some ticket replies pass and others fail. Compare actual From, envelope and DKIM identities for each workflow. Mailbox-derived or user-selected addresses may not belong to the authenticated domain. Restrict unintended identities and correct approved settings instead of loosening the organization's DMARC policy.

The interface offers Regenerate DKIM Keys. The official page describes an upgrade from older 1024-bit keys to 2048-bit keys. Coordinate that as a key transition, obtaining the new complete records and understanding activation and cached-key effects before changing an active signer. Do not assume a documented overlap window or retire a working key prematurely. Ask Support when the transition behavior is unclear.

Official references

• Vivantio SMTP Settings: native versus own-server route and configuration interface.
• Vivantio DKIM: feature access, issued TXT/CNAME records, key generation and upgrade screenshots.
• [Vivantio Sending Email](https://support.vivantio.
• [Vivantio From Address](https://support.vivantio.

Use the current instance's records and controls if screenshots differ. Resolve material differences with Vivantio before activation rather than guessing selectors, targets or product entitlement.