Vtiger SPF, DKIM and DMARC setup, step by step

For Vtiger-managed sending, obtain your domain’s SPF and DKIM records in Email Settings, publish them at the authoritative DNS host, and verify them in Vtiger. Email Campaigns also have a documented bounce-domain CNAME. External SMTP and system notifications require separate route checks. Confirm the intended From address and DMARC alignment on a real received message, not only the CRM’s verification status. Vtiger Email Settings

This guide covers the hosted Vtiger CRM workflow documented for One Pilot, One Growth, One Professional, One Enterprise and One AI. It is not an installation guide for self-hosted Vtiger Open Source. Edition-specific HelpDesk address limits and other sending entitlements still apply. No customer account, DNS zone or actual delivery was tested.

Map the CRM’s different sending routes

Before editing DNS, identify one example of each workflow you use: a one-to-one message, a workflow email, a Case reply, an Email Campaign and a system notification. Record the configured outgoing server and visible From identity for each. Reply-To is a separate reply-routing address and does not supply DMARC alignment.

Vtiger lets an administrator select its own sending service or an external provider such as Google, Microsoft or another SMTP server. System mail is documented as using Vtiger infrastructure regardless of the chosen outgoing server. Do not infer the exact notification From or signing identity from a normal CRM message: inspect the notification itself. Outgoing servers and system mail

You need access to Settings > Configuration > Email Settings, control of the sending domain’s authoritative DNS and the ability to verify the email addresses used by the CRM. The official workflow requires verification of From and Reply-To addresses; that proves address control, not SPF/DKIM alignment. A provider’s own sending restrictions may also prevent overriding From even when the address is verified in Vtiger.

For externally routed mail, configure authentication at that provider. Do not add Vtiger SPF authorization to an unrelated external route merely because the message was composed in Vtiger. Keep Vtiger-managed campaigns and notifications in the inventory so their records are not accidentally removed during a mailbox migration.

Retrieve the domain’s current authentication records

Open Email Settings and locate Sender Authentication Domains and the domain’s DNS record details. Copy the full owner names, types and values for SPF and DKIM. The current official procedure specifies an SPF TXT record and a DKIM TXT record, followed by verification back in the CRM. Use the displayed selector and public key rather than constructing a universal selector from a tutorial. Sender Authentication Domains

Prepare a change sheet containing the domain, record owner, type, current value, requested value and TTL. Do not publish a private key or credentials. If the account does not display the expected record details, ask Vtiger support to confirm the supported configuration for your edition and sending route; a generic DKIM generator cannot install its private key into Vtiger’s managed signing system.

An interface’s view or verify label can change. The essential activation sequence is to obtain the tenant’s values, publish them, wait for DNS visibility and complete Vtiger’s verification, rather than stopping after saving records at the DNS host.

Add Vtiger to SPF without replacing other senders

Vtiger’s authentication documentation identifies include:vtigermails.com. Verify that this is the mechanism supplied for your managed route. Add the authorization to the existing single SPF policy at the required owner. Do not copy a complete example over a policy that also covers staff mail, billing or another application. Vtiger authentication documentation

Preserve the intended final all qualifier. The reviewed official page contains an example ending in -al; that is a typo, not valid SPF. A hard-fail all mechanism is spelled -all. Do not change a domain’s existing policy merely to match an example.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

SPF evaluates the SMTP MAIL FROM identity, normally reflected in a received Return-Path, rather than the visible From address. Each owner has its own policy. A record on the organizational domain is not inherited by every subdomain. RFC 7208

Count the evaluated DNS-querying terms across nested includes and redirects. The limit is ten, not ten top-level providers or ten total DNS packets. Multiple SPF policies or excess lookup terms can produce permerror. Remove retired authorizations only after checking ownership; do not flatten dynamic provider IPs into a static list as an unmaintained quick fix.

Publish DKIM and verify it in Vtiger

Create the DKIM TXT record using the exact selector owner and complete public-key value Vtiger provides. DNS editors often append the zone: if the zone is example.com, entering selector._domainkey may already produce the full owner. Inspect the saved name to prevent example.com.example.com duplication.

For an illustrative issued full owner SELECTOR._domainkey.news.example.com, use relative SELECTOR._domainkey.news in the parent example.com zone, SELECTOR._domainkey at a delegated news.example.com authority, or SELECTOR at an existing delegated _domainkey.news.example.com authority. Full-name editors take the complete owner. Use the actual account-issued selector and preserve NS delegation and other selectors. Relative DNS names.

A long public key may be represented by several quoted character strings in one TXT record. Those strings concatenate. Do not split the key into multiple independent TXT records, truncate it, or add formatting characters. Keep other providers’ selectors intact. If a requested owner already contains a CNAME or another key, resolve the collision with the service owners before overwriting it.

Return to Vtiger and verify SPF and DKIM after public DNS reflects the intended values. Then check a real message for a passing signature under your domain. The existence of a key does not establish that the sending system selected it. Verification workflow

DKIM uses a signature and public key to verify signed content; it is not encryption. The signature’s d= and s= identify the domain and selector used for lookup. DKIM specification

Configure the campaign bounce CNAME separately

For Vtiger Email Campaigns, the official CNAME instructions document:

Type: CNAME
Host: ecm-bounces
Target: ca.vtiger.email

Confirm the intended sending domain and current account requirements before creating it. In an example.com zone, that relative host becomes ecm-bounces.example.com. Use DNS-only mode when the DNS platform offers HTTP proxying, and avoid a CNAME collision at the same owner.

Before creating or changing the campaign bounce alias, obtain the sending/routing owner’s separate approval of the exact full owner and target and its bounce-handling consequences. Compare the issued configuration with that approved design and verify the complete alias at authoritative and recursive DNS before activation. A record packet alone is not routing approval; stop on a mismatch and preserve normal mailbox routing.

Keep the verification alias unflattened as well as DNS-only. Cloudflare warns that flattening can suppress the CNAME answer required by a third-party verifier; inspect both zone-level and per-record settings. Cloudflare CNAME flattening

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

This record supports campaign bounce handling and a branded envelope identity. It does not abolish SPF’s lookup limit or prove that every CRM workflow now uses that return-path. Verify the actual campaign’s smtp.mailfrom. A return-path under ecm-bounces.example.com can align with example.com under relaxed SPF alignment, but those names do not match under strict alignment. An aligned passing DKIM signature can still provide DMARC success.

Do not put the campaign bounce target at the domain apex or replace its MX records. Bounce routing and ordinary mailbox reception are different functions.

Preserve the effective DMARC policy

DMARC passes with either aligned SPF pass or aligned DKIM pass. Relaxed alignment compares organizational domains; strict alignment requires an exact match with the visible From domain. A provider-owned SPF pass and a provider-owned DKIM pass can both be valid yet fail to align with your brand. Current DMARC standard, RFC 9989

Inspect the existing policy at _dmarc for the From domain and applicable parent policy. Do not publish a second policy, erase reporting destinations, change strict alignment casually or downgrade p=reject to make a CRM warning disappear. A suggested record in an application is not authority to replace a domain-wide policy.

For a domain with no established policy, the domain owner may adopt a monitored initial policy after checking inheritance and legitimate senders. An illustrative record is:

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. Use the illustrative TXT value only if no direct or applicable inherited policy exists and the domain owner approves the monitoring and review plan. Provision and approve the report destination before publication; preserve existing protections.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example reporting address with an approved destination. p=none requests no DMARC-based enforcement but cannot ensure acceptance or inbox delivery. Do not copy the obsolete pct tag from older examples; RFC 9989 removed it.

RFC 9989 section 7.4 requires valid DKIM for domains publishing p=reject and cautions about indirect and mailing-list delivery. Review all legitimate routes before changing enforcement; a passing CRM sample is not domain-wide readiness. Interoperability requirements.

Use aggregate reports under RFC 9990 to examine the actual sources and authentication identities. External reporting destinations may need authorization. Failure reports under RFC 9991 can include sensitive message information and require deliberate handling.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Run independent DNS and message checks

Substitute your exact domain and generated selector in these read-only examples:

dig TXT example.com +short
dig TXT selector._domainkey.example.com +short
dig CNAME ecm-bounces.example.com +short
dig TXT _dmarc.example.com +short

Confirm one SPF policy, the complete expected DKIM key, the campaign alias when applicable and the intended DMARC policy. Empty output is not proof of a missing record: rerun without +short and distinguish no data, NXDOMAIN, SERVFAIL and timeout. Compare an authoritative answer with a public resolver if cached data differs. Wait out the previous TTL after a correct change.

Next, send harmless examples through each selected workflow to an external mailbox you control. Do not use a customer list for configuration tests. For every received message, inspect the final trusted receiver’s Authentication-Results, not an untrusted header that happens to share that name.

Use approved synthetic CRM records and controlled events for those samples, not real customer case replies, reminders or campaign recipients. If a safe representative event is unavailable, keep that acceptance check pending with the workflow owner rather than causing a real business action.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Record these acceptance conditions:

1. The visible From address is the intended sender for that workflow.
2. SPF identifies the actual smtp.mailfrom and passes without permerror or unresolved temporary errors.
3. DKIM passes with the intended signing domain and selector. Vtiger-managed custom-domain mail should not be accepted as branded DKIM success solely because an unrelated provider signature passes.
4. DMARC passes for the intended header.from, supported by at least one aligned passing mechanism under the effective policy.
5. Campaign bounce routing and expected reply handling work independently of authentication.

For custom-domain completion, require the intended branded DKIM signature to pass and align with the visible From under the effective adkim mode, as well as receiver-confirmed dmarc=pass. DMARC success carried only by SPF does not prove that DKIM setup is complete. Investigate the actual envelope identity and sending IP if SPF returns fail, permerror or temperror, even when aligned DKIM allows DMARC to pass. Distinguish a forwarding-related SPF failure from an incorrect original-sender policy, and distinguish persistent syntax/lookup errors from temporary DNS failures. Authentication-Results trust boundary

Match the intended active Vtiger signature, or the intended signer on the separately selected external route, using its configured d= and s=. The branded From must remain the unchanged intended identity. Do not accept a rewritten provider From or another aligned signer as completion of that route’s DKIM setup. EmailAuth’s selector diagnostic guide explains keeping each actual pair together, not generating Vtiger account values.

A Vtiger-origin system notification may intentionally use a provider identity. Evaluate it against its actual documented From instead of forcing every message to resemble a campaign. Keep results per route; one successful campaign cannot certify external SMTP, Case replies or internal alerts.

Resolve failures without masking their cause

The CRM will not save email settings. Check the required address-verification steps for From and Reply-To before treating the problem as DNS failure. A link sent to an address proves control, while TXT verification proves a different configuration property. Email verification requirements

SPF passes but campaigns fail DMARC. Inspect the actual return-path and effective aspf. Confirm the bounce CNAME, route selection and DKIM alignment. Publishing a CNAME without the intended envelope identity being used is insufficient.

SPF returns permerror. Look for multiple v=spf1 records, the -al typo, invalid syntax and excess evaluated lookup terms. A long waiting period will not repair any of these.

The key is published but DKIM uses another domain. Confirm the selected transport, domain verification and From identity. Some third-party tutorials recommend disabling the Email Footer to change signing identity. The current official Email Settings page describes that control as message content, not as a DKIM activation switch. Do not remove a required disclaimer based on that unverified rule; inspect the signature and ask Vtiger support about your route.

A workflow never sends. Check the event, eligible recipients and the CRM’s Outgoing Email failure details. Required opt-in settings can affect campaigns, autoresponders and workflow messages; do not weaken consent controls as a delivery workaround. Outgoing Email and opt-in controls

External SMTP fails while Vtiger notifications arrive. Separate credential, connection and provider Send As problems from DNS. System notifications using Vtiger infrastructure do not prove the external connection works.

Everything authenticates but spam placement persists. Review bounce codes, complaints, recipient engagement and message content. Authentication is necessary infrastructure, not an inbox guarantee.

If a change breaks sending, preserve the failed message and relevant logs, pause the affected workflow where appropriate, and restore only the changed records after checking newer edits. Do not disable DMARC globally or delete unrelated senders to hide one failing route.

With the workflow owner’s approval, pause only the affected automation or restore its prior approved sender/transport settings as well as the narrowly changed DNS when appropriate. Do not silently bypass authentication. Retest the failed route and a known-good control after recovery, preserving queued-message keys and unrelated workflows.