Separate the CRM's delivery paths
A CRM can send through its own infrastructure or submit to a separately configured mailbox provider. Begin with a route inventory: a one-to-one CRM message, an automated workflow, a case reply and a system notification. Record the intended From identity for each and the administrator responsible for its configuration. Do not infer that a single successful message covers them all.
Vtiger's Email Settings documentation distinguishes outgoing server configuration from sender authentication domains. It also states that system emails continue through Vtiger servers regardless of the configured outgoing server. That distinction should drive the test matrix, rather than an assumption that selecting an external server moves every message. Vtiger Email Settings.
Use the tenant's authentication values
Open Settings > Configuration > Email Settings and identify the outgoing server and sender authentication configuration. For Vtiger-managed domain authentication, obtain the SPF and DKIM records provided for your domain, publish them at authoritative DNS, then return to Vtiger to verify them. Keep the tenant's record values with the change request. Sender authentication domains.
The public authentication article contains a malformed SPF example ending in -al. Do not deploy it. Use the current account-provided configuration and validate the finished policy independently; an invalid example is not permission to guess replacement values. If the tenant's instruction is ambiguous or conflicts with its documented route, obtain clarification before editing DNS. Vtiger authentication article.
Publish without losing other senders
Back up the existing SPF, DKIM and DMARC records. Merge a required SPF mechanism into the single existing SPF policy at the evaluated domain, preserving approved senders and the intended terminal qualifier. Check the complete evaluation tree rather than just counting visible includes. Publish the account-specific DKIM public record at the supplied selector name, and inspect the public answer for an accidentally duplicated domain suffix. SPF.
For a separately selected SMTP provider, use that provider's domain authentication instructions. Do not add Vtiger permissions merely because the CRM is the composition interface. Also avoid assuming that a changed Reply-To changes the authenticated sender identity. Reply routing and DMARC alignment answer different questions.
Test each workflow with a harmless event
Use controlled recipients and synthetic CRM records. Do not trigger real customer reminders or support replies solely to test authentication. Capture the CRM event time, message ID where available, configured route and received original.
- Workflow: One-to-one CRM message; What to compare: Selected outgoing server and actual envelope; Failure to investigate: A different route than expected
- Workflow: Automated workflow; What to compare: From identity and all DKIM signatures; Failure to investigate: A sender domain not covered by the configured key
- Workflow: Case reply; What to compare: Approved From and separate Reply-To; Failure to investigate: Mistaking reply routing for authentication
- Workflow: System notification; What to compare: Observed Vtiger route and sender identity; Failure to investigate: Assuming external SMTP settings apply universally
This is an acceptance design, not executed evidence. For each original, use trusted receiver results to pair a successful SPF evaluation with its envelope domain and each successful DKIM result with its d= domain. Compare these identities with the visible From under the effective DMARC alignment mode. One aligned passing method can satisfy DMARC; an unrelated passing provider signature alone cannot. DMARC.
Resolve discrepancies and retain recovery
If the panel cannot verify a record, compare its exact hostname, type and value with authoritative DNS. If the DNS is correct but a workflow remains unsigned, inspect that workflow's route and From domain rather than rotating unrelated keys. For an external SMTP rejection, preserve the server response and review the selected account's permitted sender identity. For system emails, confirm the observed identity against the documented exception rather than forcing the external configuration onto them.
Pause only the affected automation if necessary and restore its previous approved sender or transport setting. Keep other working routes active. After repair, repeat the failed case and a known-good control case. Save the redacted evidence, DNS snapshots and owner approvals so a later CRM or mailbox-provider change can be checked against the baseline. This draft used public documentation only; no CRM tenant, message send or DNS update was performed.
Confirm the provider boundary
The current settings guide also requires verification of configured From and Reply-To addresses before settings can be saved and mail sent. Address ownership verification is separate from domain DNS verification and DMARC alignment. Review the Outgoing Email failure details before changing DNS. Its authentication article contains oversimplified DKIM body-coverage language; use RFC 6376, not a claim that an ordinary signature can simply omit the body. A configured DMARC status is not a received-message result.
Work through a fictional diagnostic case
Fictional written case only: VT-01 assumes a one-to-one CRM message uses From support@studio.example and passes DKIM with d=studio.example through external SMTP. A system notification uses a different provider route; its From, envelope and signatures have not been captured. The first message cannot close the system-notification row. The CRM owner must collect that separate controlled notification and verify whether its actual identity is the intended one. No account, DNS, CRM, invoice, campaign or delivery was tested for this case.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.