Volgistics does not document a customer-domain DKIM setup in its current own-domain Sender ID instructions. Its recommended native-mail configuration uses the provider's sender identity and VolunteerMail@volgistics.com as the From address, while replies can still go to your organization. That is a provider-domain sending route, not authentication of your organization's branded From domain. Volgistics own-domain policy guidance
This guide explains that boundary, the two account settings involved, and how to verify a real message. It does not give you invented DKIM selectors or a DNS recipe that promises unsupported branded authentication. Account controls, DNS and message delivery have not been tested in a customer account.
On this page: Decide whether the provider-owned From is acceptable · Why the DKIM documentation is not a contradiction · Configure the two recommended controls separately · Keep replies reaching the right team · Why this route does not require new organizational DNS · Test a real native message without using volunteer data · Troubleshoot without weakening protection · Frequently asked questions
Decide whether the provider-owned From is acceptable
Start with the identity your organization actually requires. If recipients must see an address on your own domain in the message's From header, the recommended provider-owned From route does not satisfy that requirement. Do not quietly substitute it and call the branded-domain project complete. Ask your Volgistics administrator and the team responsible for email identity to approve the scope or obtain a supported alternative from Volgistics.
If a provider-owned From with an approved organizational Reply-To is acceptable, this guide covers native messages delivered by Volgistics' servers. It does not cover another mail provider, an external SMTP integration, SMS, or a promise that all recipients will accept the message.
Record these before changing anything:
- The existing Email Authentication and From address selections.
- The approved new visible sender identity, if a change is needed.
- The monitored reply mailbox for each message type in use.
- Which existing operator is authorized to change the account settings.
- The approved test route, controlled recipient and expected acceptance evidence.
The settings affect more than one individual message. Treat them as an account-level change, not a harmless experiment on a single volunteer email. If the account already uses the approved configuration, inspect it without toggling settings unnecessarily.
Why the DKIM documentation is not a contradiction
Volgistics' March 8, 2021 release note says its mail-server software added DKIM and describes DMARC protection for volgistics.com. That is evidence about the provider's domain. It does not issue a public key for your domain or establish that Volgistics will sign with your domain in the DKIM d= field. Volgistics email-server release note
Meanwhile, its current own-domain guidance states a limitation on using DKIM and DMARC with the organization's domain. Read these statements together: provider-domain signing and customer-domain signing are different capabilities. There is no reason to invent a customer selector from the provider's domain, copy another tenant's DNS, or publish a key taken from an unrelated service.
Also separate product limitations from protocol rules. DMARC does not universally require DKIM: a message can pass through aligned SPF or aligned DKIM. A successful SPF result for a provider-owned envelope domain, however, does not authenticate an unrelated organizational From domain. Neither a Reply-To address nor a friendly display name fixes that mismatch. DMARC authentication and alignment
Configure the two recommended controls separately
Proceed only with the account owner's approval for the identity and account-wide effect. If Setup is unavailable, ask the existing Volgistics administrator to perform the authorized change; do not expand operator rights just to follow this article.
- Open Setup, expand Messages, and choose Ground Rules.
- In Email Authentication, select Let Volgistics handle Sender ID (recommended) if this is the approved choice.
- In the separate From address section, select Use VolunteerMail@volgistics.com as the from address (recommended) if the provider-owned identity has been approved.
- Preserve the approved Reply-To values and all unrelated fields. Review the two selections, then use Save.
- Reopen or inspect the saved settings before testing. A clicked button without a confirmed saved state is not completion.
Volgistics documents immediate Sender ID behavior after saving its recommended authentication selection. That statement does not turn the setting into a customer-domain DKIM switch. The From control is a separate part of the configuration. Sender ID controls and Save, recommended From configuration
Do not change opt-out wording, message preferences, SMS options, failure thresholds or other settings visible on the same page. Do not use Reset All or reset invalid recipient addresses as part of an authentication change. Those operations affect recipient eligibility and can obscure the actual reason for earlier failures. Likewise, allowlisting is not evidence of valid SPF, DKIM or DMARC.
Keep replies reaching the right team
A provider-owned From and an organizational Reply-To serve different purposes. From identifies the message's author domain for DMARC. Reply-To tells the recipient's mail client where to address a reply; it is not an authentication identity.
Volgistics has several reply-address sources. An operator's default, an automatic-message setting, an application confirmation and a schedule-copy message can use different values. Do not assume that checking one manual email proves every automated reply route is correct. Inspect the routes actually used by your organization, and retain their approved monitored addresses. Volgistics Reply-To locations
Do not replace every reply address simply to make them match the provider's From. If an address is wrong or unmonitored, obtain approval for its correction independently. In particular, an operator's login address and their Reply-To field are not interchangeable. Authentication work is not a reason to alter account access, billing contacts or every application form.
For automatic messages, the Ground Rules page has distinct volunteer and Coordinator reply fields. Keep valid approved values even when a particular automated-message feature is not currently used. Ground Rules email properties
Why this route does not require new organizational DNS
The recommended provider-owned identity uses records administered by Volgistics. This guide therefore does not ask you to add a Volgistics SPF include, IP range, customer DKIM record or new DMARC policy to your organization's DNS. Do not copy Volgistics' own-domain Sender ID alternative into this different route.
Keep existing organizational SPF, DKIM and DMARC records intact. They may still protect staff mail, fundraising systems and other legitimate senders. A change to this application's From does not authorize removing those records, weakening p=reject, or replacing inherited policy with a new p=none record.
If you need to diagnose SPF on a separate branded route, first identify the actual SMTP MAIL FROM domain rather than assuming it equals Reply-To or the visible From. SPF is evaluated at that identity. Multiple v=spf1 records at one owner are invalid; editing mechanisms is not the same as publishing an additional policy. None of that establishes support for a customer-domain route absent provider evidence. SPF specification
Test a real native message without using volunteer data
Use an existing, explicitly authorized test identity and controlled mailbox. The test should contain a neutral subject and body only: no volunteer names, schedules, application details, attachments, personalized placeholders or private information. If a suitable test recipient does not already exist, coordinate an approved test arrangement with the administrator rather than creating a production volunteer record or contacting real volunteers by default.
Volgistics' manual email path starts at Mailbox > Out Box > Send a Message. Select email only and inspect the complete recipient selection before sending. Do not leave all-volunteer, tagged, status, set or all-Coordinator selections active. Leave unrelated CC recipients out, and preserve the approved Reply-To. A saved draft or scheduled message is not a completed transport test. Use an explicitly approved immediate test, not an unattended future campaign. Native message composition and sending
At the controlled receiving mailbox, obtain the original message and results from the receiving system you administer or trust. Ask its administrator which gateway produces authentication results and how it removes or segregates externally supplied Authentication-Results headers. A familiar authserv-id, a header's position, or text that says pass is not enough by itself to establish that trusted provenance. Authentication-Results trust boundaries
Record these distinct checks:
| Check | What counts as useful evidence |
|---|---|
| Saved controls | The approved provider-owned From and authentication selections remain saved. |
| Actual From | The delivered message uses the intended volgistics.com identity, not an unexpected organizational From. |
| Reply-To | Replies are addressed to the approved monitored mailbox; an authorized harmless reply can verify delivery. |
| SPF | The trusted receiver reports the actual MAIL FROM identity and SPF result. Do not assume its domain. |
| DKIM | The intended Volgistics signature verifies, with its actual d= and s= recorded; an unrelated gateway signature is not proof. |
| DMARC | The trusted result is a pass aligned with the actual From domain, not merely an unaligned SPF or DKIM pass. |
Under relaxed alignment, the authenticated domain and From domain share an Organizational Domain. Under strict alignment, they must match exactly. This applies separately to DKIM's d= and SPF's MAIL FROM domain. A child envelope domain is not automatically strictly aligned with a parent From. DMARC alignment rules
If the intended provider signature is missing or fails, stop treating the signing check as complete, even if aligned SPF happens to produce a DMARC pass. Conversely, investigate SPF fail, temperror or permerror separately even if DKIM carries DMARC. A delivered message can still reveal a broken authentication path. See raw DKIM results versus aligned DKIM policy results.
A single successful manual test establishes only the tested path. Repeat a harmless authorized test for a materially different automated path before claiming it is covered; do not trigger genuine applications, reminders or schedule changes just to generate email.
Troubleshoot without weakening protection
The From is still organizational. Recheck the separate From selection and saved account state. Verify that the sample came from the expected Volgistics route after the change. Do not repair this by weakening organizational DMARC.
The recipient sees “on behalf of.” The provider's documentation notes that mail clients can display Sender information differently. Inspect the actual headers rather than judging authentication from the inbox label alone. A cosmetic display difference is not proof of either failure or success.
Replies go to the wrong place. Inspect the particular message's Reply-To and its originating setting. Correct only the authorized route. Do not change the operator's login identity to solve a reply-routing issue.
The message never arrives. Distinguish a message that was not eligible to send from one rejected downstream. Review the relevant sent-message information and rejection reason without resetting recipient preferences or invalid-address flags. A provider “sent” state is not proof of receiving-server acceptance.
Provider-domain authentication fails. Give Volgistics a sanitized timestamp, route description, actual authentication identities and trusted receiver error. Do not send passwords, login cookies, private keys or volunteer content. Preserve the original privately if the authorized support process later requires it.
Branded From remains mandatory. Stop here and request a documented supported solution that names the customer domain, record issuance, signing activation, actual envelope identity and acceptance test. Do not label this provider-owned route as equivalent.