Vision6 SPF, DKIM and DMARC setup, step by step

Configure your domain inside Vision6, publish the issued hostname and DKIM aliases plus the account’s validation record, and check a delivered message before approving a campaign. A green DNS status is not proof that the intended branded signature is working. This guide separates domain configuration, SPF authorization, DKIM signing and DMARC alignment.

On this page

• Scope and prerequisites
• Get the account’s records
• Publish at the right DNS owners
• Understand SPF without replacing your apex policy
• Preserve DMARC protection
• Validate DNS and actual signing
• Troubleshoot and recover safely
• Frequently asked questions
• Sources and verification limits

Scope and prerequisites

Vision6 documents domain setup for Starter, Business and Pro-Marketer. Use an organization-controlled domain and an account operator with access to domain settings, together with its authorized DNS administrator. The public guide does not specify a universal role name. Personal freemail domains cannot be authenticated by your organization. This is the native Vision6 sending workflow, not instructions for configuring a separate SMTP product. Vision6 setup.

Before changing anything, record the intended From address, existing DNS owners and values, applicable DMARC policy, active campaigns and other accounts using the domain. Obtain the domain owner’s approval for the scoped changes and a recovery plan. Do not change parent nameservers, MX routes, DNSSEC or credentials merely to complete authentication.

Shared domains need coordination: configuring one account can prevent another unverified account from sending with that domain. Each additional legitimate account needs its own verification; do not replace another account’s TXT token. Vision6’s shared-domain instructions use an account-specific TXT record and a subsequent configuration check. Shared-domain setup.

Get the account’s records

Open Account → Domains → Add Domain. Enter the domain used after @ in the intended From address and choose Next. Choose a hostname, initially suggested as comms, and save. Open View Details for the domain to copy its complete records. The platform checks automatically; after publication, use the domain’s ellipsis menu … → Test and Check to force another check; the target account status is Configured. Share instructions only with an authorized administrator. Official account workflow.

The provider’s illustrated panel separates four purposes:

• Hostname: CNAME for the chosen hostname, with the instance-specific target supplied in the panel.
• Domain Keys (DKIM): CNAME at the issued selector owner. The illustrated selector is v6dk1, under _domainkey.
• Domain Validation: TXT at an account-specific owner, with the complete issued verification value.
• DMARC: a separate policy record, not another DKIM token. Preserve existing protection rather than copying the suggested monitoring value.

The illustration’s Australian target is not a universal value for every instance. Obtain your actual target and token from the account. Never generate an unrelated DKIM key online or copy a screenshot’s validation value. Official record-panel illustration.

Optional advanced branding is a separate decision. For Corporate, Agency and Pro-Marketer accounts, Vision6 describes a switch that changes product access and tracking-link branding after domain configuration. It is not a prerequisite to proving DKIM. Obtain the account owner’s approval before changing those shared access or tracking behaviors. Advanced domain settings.

Publish at the right DNS owners

Use the exact record types, owners and targets issued for your domain. In a panel that appends the zone name, enter the relative owner only. In a panel expecting a fully qualified name, use the complete owner without duplicating the zone suffix.

For an illustrative sending domain news.example.com, a DKIM owner v6dk1._domainkey.news.example.com maps as follows:

• In the parent example.com zone: v6dk1._domainkey.news.
• In a separately delegated news.example.com zone: v6dk1._domainkey.
• In a delegated _domainkey.news.example.com namespace: v6dk1, entered by the administrator of that namespace.

A hostname such as comms.news.example.com becomes comms.news in the parent zone or comms in the child zone. Apply the same full-owner comparison to the issued validation TXT. Keep existing delegations intact; do not delete a shared _domainkey delegation to make a tutorial fit. DKIM selector lookup.

At each CNAME owner, check for an existing alias, TXT, A, AAAA or MX record. Do not create a conflicting record or remove an unrelated dependency. If the hostname is already in use, stop and agree on a supported alternative with the account and DNS owners. The DKIM lookup name must include the underscore in _domainkey.

Where the DNS host offers an HTTP proxy, use DNS-only for these mail-authentication aliases. Literal CNAME answers must remain visible where the provider’s check requires them. On Cloudflare, disable the relevant per-record Flatten option when available and confirm that whole-zone flattening is not suppressing those aliases. Review any zone-wide change for other dependencies rather than disabling it blindly. Apex flattening and same-zone target behavior have separate rules; if mandatory behavior cannot preserve the required answer, coordinate a supported layout instead of inventing a switch. Cloudflare flattening behavior.

Understand SPF without replacing your apex policy

Vision6 says SPF is handled once domain configuration is complete. Its hostname supports the return path. Do not add an apex include merely because an older third-party guide presents one. First identify the actual SMTP MAIL FROM used by delivered Vision6 mail and check the records belonging to that identity. Vision6 SPF guidance.

SPF evaluates the envelope sender domain, not automatically the visible From address. The relevant HELO identity is used in applicable cases, including a null reverse path. If a separate, supported route genuinely requires an SPF TXT edit, preserve legitimate authorizations and qualifiers in one v=spf1 policy at the evaluated owner. Never add a second SPF policy or place a conflicting TXT beside a CNAME. SPF identities and record selection.

Count evaluated DNS-dependent mechanisms and modifiers, including nested lookups, against SPF’s limit of ten. This is not simply a limit of ten written include terms. An all mechanism causes redirect to be ignored. Authentication qualifiers do not guarantee inbox placement or a receiver’s final handling. SPF lookup limits, redirect processing.

Preserve DMARC protection

Inspect both a direct policy and any applicable inherited policy before creating a record. Retain existing enforcement, alignment modes and authorized reporting destinations. Only if no applicable policy exists, the domain owner approves and an appropriate monitoring plan is in place, this minimal example can start monitoring:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none;

Replace example.com with the approved policy domain. In the example.com zone, its relative owner is _dmarc. For news.example.com, the full owner is _dmarc.news.example.com; use _dmarc.news in the parent zone or _dmarc in a separately delegated child zone. Do not create a duplicate policy or downgrade an existing policy to match this example. The example does not itself configure report collection. DMARC policy discovery and syntax.

If collecting aggregate reports, the owner must approve the recipient and data-sharing purpose; provision that recipient and monitor report receipt. Compare the report URI’s destination-host Organizational Domain with that of the domain where the DMARC policy was discovered, not automatically the visible From domain. A destination in a different Organizational Domain requires the report-generating receiver to check DNS authorization; destinations within the same Organizational Domain are excepted. This is not simply a test for different hostnames. Protocol authorization does not replace the owner’s privacy decision. Do not copy a vendor’s reporting address into your policy. RFC 9990, section 4.

Do not move to enforcement based on one successful test. Inventory legitimate senders and review representative reports, forwarding and mailing-list paths before approving a stronger policy. RFC 9989 section 7.4 warns that p=reject can disrupt indirect flows and requires valid DKIM rather than reliance on SPF alone. For general-user domains whose users post to Internet mailing lists, assess that specific interoperability risk before considering rejection. Avoid obsolete pct rollout advice. DMARC deployment considerations.

Validate DNS and actual signing

First compare authoritative DNS and a public resolver against the account’s exact packet. These are structural examples, not measured results:

dig +short CNAME comms.example.com
dig +short CNAME v6dk1._domainkey.example.com
dig +short TXT VALIDATION-OWNER-FROM-ACCOUNT.example.com
dig +short TXT _dmarc.example.com

Substitute actual owners before running a lookup. An alias answer should match the issued target; the TXT response should retain the full issued value. Missing or stale results require checking delegation, caching, owner spelling, record type and flattening. A public key can exist while the application still uses another signing identity.

Next have the authorized account operator send harmless test content to controlled, valid recipients through the actual intended campaign or automation path. No test sends were performed for this guide. Inspect original headers in the receiving service, not only a forwarded copy.

Use authentication results generated inside that receiving service’s known processing boundary and its documented treatment of externally supplied Authentication-Results. A familiar authserv-id string or topmost header position alone is not proof of origin. Ignore attacker-inserted result fields; involve the receiving administrator when the boundary is unclear. Authentication-Results trust model.

Record and compare:

1. The intended visible From address, unchanged in the delivered message.
2. The intended Vision6 signature’s d= signing domain and s= selector, with the receiver’s dkim=pass for that signature.
3. Alignment of that passing signature with From under the applicable adkim mode.
4. Trusted receiver dmarc=pass for the intended From domain.
5. The actual smtp.mailfrom identity and SPF result, investigated separately even when DKIM supplies DMARC pass.

Strict alignment requires an exact domain match; relaxed alignment can use the same Organizational Domain. A child envelope domain does not prove strict SPF alignment with its parent From domain. A generic DMARC pass via SPF does not prove the intended DKIM configuration. For multiple signatures, keep each domain, selector and result together. See raw DKIM versus aligned DKIM results.

Troubleshoot and recover safely

• From was rewritten: do not accept a provider-owned authenticated address as successful brand authentication. Vision6 documents rewriting for incomplete or unavailable domain configuration, including Australian and US instance addresses. Resolve configuration for the approved domain and retest. Rewrite scenarios.
• Configured domain, wrong campaign From: verify the intended domain and approved sender selection. Do not silently change the visible From just to obtain a pass.
• DKIM missing or failing: distinguish a wrong selector, unavailable key, disabled/unaccepted configuration and content modification after signing. Recheck the exact signature’s DNS owner and provider status rather than adding unrelated keys.
• SPF fail: examine authorization for the actual envelope identity. Temperror indicates a transient evaluation problem; investigate DNS availability and retest. Permerror calls for correcting structural problems such as duplicate policies or excess evaluated lookups. Do not dismiss these because DKIM passes. SPF result definitions.
• Another account stopped sending: compare per-account validation tokens and shared hostname/key dependencies before deleting anything. Coordinate recovery with all affected owners.

If a change disrupts a campaign or automation, obtain its owner’s approval to pause the affected flow and restore only the last known-good, authorized configuration. Do not remove active selectors or validation records while other accounts or queued messages depend on them. Preserve the failed sample, then retest the failed path and a known-good path after recovery. Keep existing DMARC protection intact while diagnosing.

Sources and verification limits

Primary setup, shared-account and advanced-setting instructions and three official DNS-panel illustrations were read. The setup page shows November 2025; the advanced-settings page shows July 2026. These are provider dates, not customer test dates.

This guide does not establish your account’s permissions, issued values, live DNS, actual signing, mailbox delivery or website implementation. Follow the validation steps with your own authorized operators before rollout. Provider instructions govern the account packet; current protocol standards govern interpretation of authentication and alignment.