Volusion SPF, DKIM and DMARC setup, step by step

For an existing Volusion-hosted mailbox, configure the documented hosted-email SPF policy and obtain DKIM records through MyVolusion. DKIM has three separate account/DNS checkpoints: enable it for the domain, publish the issued public TXT record, then return to Verify TXT. Finish by checking an actual mailbox message. A record lookup alone does not prove signing or DMARC alignment. Volusion authentication instructions

This guide covers existing hosted mailboxes, not a mailbox purchase, MX migration or blanket authentication of every email sent by a Volusion store. Store Email Templates expose a separate record packet, described below as a scope boundary.

On this page: Confirm which service actually sends the email · Prepare one SPF policy for the actual sending identity · Enable mailbox DKIM and obtain the issued public record · Publish the exact TXT record and verify it · Keep store-template authentication separate · Preserve the effective DMARC policy · Test an actual hosted-mailbox message · Troubleshooting and safe recovery · Frequently asked questions

Confirm which service actually sends the email

Volusion offers hosted mailboxes through its email service provider, Rackspace. Owning a Volusion store or using Volusion DNS does not by itself mean that your staff mailbox is hosted there. Confirm the existing service and authorized domain before applying its SPF policy or enabling DKIM. Volusion-hosted email

Before making changes, record the approved sending domain, intended From address, actual DNS authority, existing authentication records and authorized administrator. Preserve the current DNS values and account state for recovery. Confirm any delegated child zone separately: editing a parent zone will not override a different authority below it.

Use existing authorized access. This workflow does not require buying mailboxes, changing plans, moving nameservers, changing MX, altering the store's From address or creating a new administrator. If the expected controls are absent, establish the actual account/product scope with Volusion rather than using an unrelated Rackspace recipe.

Prepare one SPF policy for the actual sending identity

Volusion's hosted-mailbox documentation provides this TXT value:

v=spf1 include:volusion.email a:smtp5.volusion.com include:emailsrvr.com ~all

The middle authorization is a:smtp5.volusion.com, not include:smtp5.volusion.com. In MyVolusion's DNS editor, the documented name is the full domain with a trailing period; use TXT, not the legacy SPF record type, and do not substitute @ in that editor. Volusion hosted-email SPF fields

Treat that value as the provider's scoped starting policy, not permission to overwrite yours. At the actual policy owner:

1. Inspect every TXT record and identify policies beginning v=spf1. Other TXT records are not duplicates merely because they share the same name.
2. If a policy already exists, have the DNS administrator incorporate the required authorized mechanisms into that single policy. Preserve other legitimate senders and the approved terminal qualifier.
3. If multiple SPF policies exist, resolve them into one intentional policy rather than adding another.
4. If no policy exists, confirm this owner and the complete sender inventory before creating one.
5. Verify the resulting policy at the authoritative DNS server, then through the resolver used for testing.

SPF normally checks the SMTP MAIL FROM domain, not the visible From address. Inspect the actual envelope identity on a message instead of assuming that publishing a record at your website domain guarantees SPF alignment. A HELO identity may be relevant when MAIL FROM is empty. SPF identity and evaluation

An all mechanism terminates matching; mechanisms placed after it cannot authorize additional senders. Any all mechanism also suppresses redirect, so a redirect-based policy needs deliberate review rather than a pasted suffix. The ten DNS-lookup-causing-term limit includes nested evaluation, not just visible includes. Do not flatten live addresses manually or delete other providers to make a lookup warning disappear. Retain an unresolved SPF evaluation issue as a blocker for that path.

On an external DNS host, use its full-name or relative-name convention. Volusion's trailing-period and no-@ instructions describe its own editor, not every DNS service. Confirm the final fully qualified owner instead of mechanically applying one host's interface rules elsewhere.

Enable mailbox DKIM and obtain the issued public record

In MyVolusion, open Manage Email > Mailboxes > Advanced Setting. Under Domains, open Sender Authentication (DKIM), select the domain, then choose Enable DKIM for that domain. Copy the issued record data. Volusion DKIM issuance

Do not copy a selector or key from a screenshot. The illustrated control uses a generic domain, and the DNS example is visibly truncated. Your account's complete owner and public key are the authority for this deployment. The key published in DNS is public; private signing keys, login credentials and recovery tokens do not belong in DNS or a support message.

Before publication, compare the domain and selector with the approved mailbox scope. If DKIM is already enabled, inspect the existing configuration rather than disabling it or initiating unnecessary replacement. If an issued name collides with another service's key, stop and obtain a supported distinct selector or coordinated rotation plan. Never overwrite an active key just because a setup guide says to add one.

Publish the exact TXT record and verify it

For Volusion-hosted authoritative DNS, open Manage DNS, add the issued record using TXT, place its owner in Record Name and its value in the rightmost Hostname field, then save. The vendor warns that copying can omit the domain from the owner. Check the complete name; do not omit or double-append the domain. After DNS publication, return to Manage Email > Advanced Setting > Sender Authentication (DKIM) > Verify TXT. Volusion allows roughly 24–48 hours for propagation; this is not a guarantee. Publication and Verify TXT

For externally hosted authoritative DNS, publish the same account-issued public record through that host's approved interface. Confirm the final owner, type and full value. Do not put the key into a CNAME field, add an HTTP proxy, or create an unrelated record just because the mailbox is managed elsewhere.

A DNS host may split a long TXT value into multiple quoted strings within one TXT record. That is different from creating several competing TXT records at a DKIM owner. Compare the reconstructed value with the complete issued key; avoid smart quotes, inserted whitespace or a truncated clipboard value.

Track four outcomes separately:

• The intended domain's DKIM account control was enabled or already enabled.
• The correct public key resolves at the exact authoritative owner.
• The provider's Verify TXT check has been run and its actual result recorded.
• A new intended mailbox message has the expected verifying signature.

Do not invent a success label or an additional activation button. If the provider cannot verify the correct published record, retain the error and ask its support team to confirm the account-side state. Waiting longer is not a remedy for a wrong owner or incomplete key.

Keep store-template authentication separate

For a store already configured with an approved domain-based Email Address From, the store admin exposes a separate packet at Design > Email Templates > three-dot menu > View Spam Prevention Records. The popup contains SPF and DKIM TXT hostnames and values. Do not copy its blacked-out illustrative values, restore a template, edit message content or change the sender just to expose records. Store Spam Prevention Records

This packet is not the hosted-mailbox DKIM key. Mailbox Verify TXT does not establish store-template signing. The current store instructions do not specify a separate signing switch or verification status; do not manufacture one. If this route is needed, coordinate its exact issued records and account-side signing requirements with Volusion, and validate it independently. Do not count an untested store route as complete because a staff-mailbox test passed.

An authorized existing store message can provide evidence. Do not place, pay, refund, ship or resend an order, or disclose customer records, simply to create an authentication sample. If no harmless approved sample exists, leave store acceptance pending.

Preserve the effective DMARC policy

Check the policy that actually applies to the From domain, including any inherited policy. Do not add a second DMARC record or replace an existing enforcement policy with a setup example. The account's DNS state, not an assumption that a platform created a generic record, determines what is currently published.

DMARC can pass through aligned SPF or aligned DKIM. It does not universally require both to pass, and rua is an aggregate-report destination rather than a mailbox to which quarantined messages are forwarded. Keep the approved policy, alignment modes and reporting destinations intact. If no applicable policy exists, design the initial policy separately with the domain owner rather than silently deploying quarantine or reject. DMARC policy and alignment

Reporting can disclose operational information. Add a reporting recipient only when its destination and purpose are approved. Where external report authorization is required, compare the destination with the domain where the DMARC policy was found, including inherited policy. A different Organizational Domain normally requires authorization; the same-Organizational-Domain exception uses that policy-found domain too. DMARC aggregate reporting

Test an actual hosted-mailbox message

Use the existing intended mailbox route to send an explicitly authorized, harmless message to a controlled receiving mailbox. Use a neutral subject/body, with no customer information, order content or attachments. Do not use a store notification, an unrelated relay or another provider's mailbox and call it a Volusion-hosted-mailbox test.

Obtain the original received message and the receiving system's authentication results. Establish the trusted receiving boundary with its administrator: which gateway evaluates the message, and how externally supplied Authentication-Results headers are removed or segregated. Neither a familiar authserv-id nor a header's position proves trust by itself. Authentication-Results trust model

For the tested route, record:

For DKIM alignment, compare d= with the From domain; for SPF alignment, compare MAIL FROM with the From domain. Relaxed alignment permits the same Organizational Domain, while strict alignment requires an exact domain match. A child envelope domain does not automatically meet strict alignment with its parent From. DMARC alignment rules

An unrelated gateway's DKIM pass is not proof that the intended mailbox signed correctly. An SPF-only DMARC pass cannot validate this DKIM setup: the intended hosted-mailbox signature must itself pass and align with the approved From under the effective adkim mode, alongside a trusted DMARC pass. Likewise, a DMARC pass carried by DKIM does not make an SPF fail, temperror or permerror disappear. Record each layer's result. See raw DKIM results versus aligned DKIM policy results.

DNS publication, account verification, message authentication and inbox placement are separate outcomes. Authentication success is not a guarantee of delivery or freedom from phishing.

Troubleshooting and safe recovery

Verify TXT fails. Check authoritative DNS, the exact owner, missing or repeated domain suffix, record type and complete public value. A record saved in the wrong DNS provider is not effective publication. Preserve the provider's actual error instead of claiming activation succeeded.

DKIM is missing. Confirm the message originated from the intended hosted mailbox after setup, not from a store template or third-party mailbox. Ask Volusion to establish signing state if the correct key is published and verified but the intended signature is absent.

DKIM fails. Compare the observed selector and signing domain with the corresponding published key. Consider stale or replaced keys and message modification along the delivery path. Do not rotate or delete keys blindly.

SPF errors persist. Resolve duplicate policies, syntax, nested lookup exhaustion or temporary DNS failure at the evaluated envelope owner. Do not add another policy, change a:smtp5.volusion.com into an include, or authorize every sender indiscriminately.

Authentication passes but DMARC fails. Check alignment with the actual From domain. Raw passes for unrelated provider identities do not satisfy that requirement.

Recovery is necessary. Pause rollout and coordinate restoration of only the changed records from the approved prior state. Preserve active selectors needed by other senders and queued mail. Do not reset templates, move MX or weaken DMARC as a shortcut. Retest after the approved correction.