Veeva SPF, DKIM and DMARC setup, step by step

For Vault CRM Approved Email, obtain the sending-domain DNS package from Vault CRM Support, publish its SPF TXT, DKIM TXT and tracking CNAME records, have Support validate them, and configure the verified domain in approved_email_domainv. Then test an actual Approved Email: the intended branded DKIM signature must pass and align with the visible From domain. A published key or a successful SPF result alone does not establish that outcome. Vault CRM sending-domain setup.

This is a documentary configuration guide, not a report of changes to a Veeva account, published customer DNS or tested delivery. Examples use fictional domains and contain no customer or health information.

Confirm which Veeva email workflow you use

This procedure follows Vault CRM Approved Email, Object Model. The documented prerequisites include an Approved Email license and System Admin access for domain setup; template work belongs to a Content Admin.

Do not transfer configuration labels between product families:

• Vault CRM Approved Email: use the workflow below and its v settings.
• Legacy Veeva CRM Approved Email: follow its separate instructions, including APPROVED_EMAIL_DOMAIN_vod. Similar-looking screens are not interchangeable. Legacy CRM documentation.
• Other Vault outbound email: designated application workflows use an Outbound Email Domains administration process. That feature explicitly excludes ordinary Vault notifications. It is not the Approved Email setup described here. Vault outbound-email scope.

Record the environment, licensed workflow, intended sender domain, template and user/profile combinations before requesting records. Include brand-specific and country-specific templates in that inventory. One configured default cannot certify every override.

Authentication is also separate from permission to contact a recipient, marketing consent and the accuracy of message content. Do not use patient or other sensitive information in authentication diagnostics.

Map From, Return-Path, DKIM and Reply-To first

The visible From Address is the identity readers see. The Sending Email Domain supplies the envelope domain reflected in Return-Path. In Vault CRM, the template's Sending Email Domain on approved_documentv overrides the default approved_email_domainv; a default can also differ by user profile. Reply To Address controls where replies go, not which domain DMARC authenticates. Vault CRM header behavior.

For each template, prepare four separate fields:

1. Intended visible From domain.
2. Expected envelope MAIL FROM domain and effective template/default setting.
3. Expected DKIM signing domain and the Support-issued selector.
4. Monitored reply destination.

SPF evaluates the SMTP MAIL FROM domain for ordinary non-empty-envelope messages. Publishing authorization at the corporate apex will not fix a separate child envelope domain automatically. SPF identity rules.

DMARC compares the visible From domain with a passing SPF identifier or DKIM d= domain. Relaxed alignment accepts the same Organizational Domain; strict alignment requires an exact domain match. A sibling or parent-child relationship can therefore pass relaxed alignment while failing strict alignment. p=reject is a requested disposition, not shorthand for strict alignment. DMARC alignment.

Request the domain and publish the supplied records

Veeva recommends a dedicated subdomain. Ask Support to provision the chosen domain and supply the exact SPF value, DKIM owner/public key and tracking CNAME owner/target. Veeva specifies 2048-bit DKIM keys. Have Support validate the records before activating the verified domain in the Approved Email setting. Provisioning and verification.

Treat the returned package as account-specific configuration, not a reason to reuse another tenant's selector. Do not infer an SPF include from Veeva's infrastructure provider, copy a public IP list into SPF, or generate an unrelated key pair. The sending engine must possess the private key corresponding to the public record it tells you to publish. Only the public key belongs in DNS.

Before editing, export the affected DNS records and record the previous provider settings. Name the DNS owner, application owner, approval reference and recovery window. A new child domain can reduce conflicts, but it still needs its own correctly placed authorization.

Place records at the exact DNS owner

The following illustrates name handling only. selector1 is a placeholder, not a Veeva selector:

Sending domain: mail.example.com
DKIM owner: selector1._domainkey.mail.example.com
In the example.com zone: selector1._domainkey.mail
In a separately delegated mail.example.com zone: selector1._domainkey
SPF owner: mail.example.com
In the example.com zone: mail
In the delegated mail.example.com zone: @

Use the full name if your DNS editor requires it. If it automatically appends the zone, enter the appropriate relative label. Confirm that the resulting name is not mail.example.com.example.com. Where a child zone is delegated, changes must reach its authoritative servers; adding an unused duplicate in the parent zone will not repair it.

Keep a tracking CNAME distinct from a DKIM key record. A CNAME must not share its owner with unrelated TXT, MX or other ordinary data. Do not replace the apex, mailbox-provider MX records, verification tokens or another sender's DKIM selector.

Preserve SPF and handle long DKIM keys safely

At the exact SPF owner, retain one v=spf1 record incorporating all still-authorized senders. Merge the supplied authorization into that policy before its terminal all mechanism; do not append a second SPF policy. Preserve the existing terminal qualifier unless the mail-security owner separately approves a change. Check the full nested evaluation against the ten DNS-querying-term limit, not just the visible include count. SPF publication and limits.

A long TXT value can contain multiple quoted character strings inside one TXT resource record. The strings are concatenated without added spaces. Do not publish two independent DKIM TXT records at one selector, truncate the key, or publish a private key. Confirm the DNS editor's treatment of long values rather than copying surrounding display quotes blindly. DKIM DNS key representation.

Activate the correct template identity and protect tracking

For a subdomain From identity, the documented route uses a User formula field, user read permission, template references and a Vault-to-Vault CRM sync. Validate generated addresses, especially names with spaces or special characters. Subdomain configuration.

Test actual resolved addresses rather than only reading a formula. A valid-looking template can select a different envelope domain through an override. Changing Reply-To cannot repair that mismatch.

Tracking needs its own acceptance check. Veeva documents DNS-only treatment for its tracking CNAME in Cloudflare and Let's Encrypt compatibility for HTTPS. Older domains and previous CDN arrangements may require Support coordination. Removing a configured domain can break links in earlier messages. Tracking and domain-retirement warnings.

Do not disable certificate controls, downgrade HTTPS or delete the sending domain as a quick authentication repair. Ask the security owner and Support to resolve the particular dependency. Keep a historical-link check separate from the DKIM verdict.

Verify DNS, then verify an actual Approved Email

Replace the fictional names below with the exact package values. These commands read DNS; they do not publish changes. Query the authoritative nameserver for the relevant zone, then compare a recursive resolver after caching has expired.

dig +short NS example.com
dig +short NS mail.example.com
dig @ns1.example.net TXT mail.example.com +noall +answer
dig @ns1.example.net TXT selector1._domainkey.mail.example.com +noall +answer
dig @ns1.example.net CNAME tracking.mail.example.com +noall +answer
dig TXT mail.example.com +noall +answer
dig TXT selector1._domainkey.mail.example.com +noall +answer
dig TXT _dmarc.mail.example.com +noall +answer
dig TXT _dmarc.example.com +noall +answer

Expect one SPF policy at the intended owner, a complete public key at the supplied selector and the exact tracking alias. An empty child NS answer does not alone prove broken DNS: the child may not be delegated. Establish which zone actually answers. NXDOMAIN, unexpected names, missing targets or SERVFAIL need investigation, not repeated arbitrary edits.

After Support confirms activation, have an authorized administrator send a harmless Approved Email from the actual template and user/profile to a controlled mailbox. A test sent from an unrelated desktop mail client cannot certify the Vault CRM route.

Save the receiver's original message source and record:

• Visible From and Reply-To, including the domains after template substitution.
• Trusted receiver-added Authentication-Results, not an untrusted header copied into message content.
• spf= and smtp.mailfrom, plus the sending IP where available.
• Each dkim= result, its header.d/signature d= and selector s=.
• dmarc= and header.from, the applicable alignment modes, account state and timestamp.

Acceptance requires the intended branded DKIM signature to pass and align, together with the expected From, a DMARC pass and an explained SPF result. Do not accept a provider-domain signature as the branded result or let aligned SPF conceal broken branded DKIM. This is a commissioning criterion, not a claim that DMARC requires both mechanisms to pass. DKIM verification.

A provider-owned envelope that passes SPF but does not align is different from spf=fail, softfail, none, temperror or permerror. Investigate actual errors even if DKIM makes DMARC pass. For the expected customer envelope, a failure can mean missing authorization, the wrong owner, duplicate SPF, excessive nested lookups or a DNS outage. A forwarder can also alter SPF's sending IP, so compare direct delivery before changing authorization.

Keep DMARC policy and reporting intact

Retain an existing DMARC policy and its reporting destinations. Do not publish a second policy or weaken enforcement to hide a sender defect. Determine the policy effective for the actual From domain, including any applicable parent policy and subdomain controls.

If neither a direct nor an inherited policy exists and a monitored rollout is appropriate, this is a fictional starting example, not a replacement for an established policy:

For the apex example.com, the full DMARC owner is _dmarc.example.com, usually entered as _dmarc in that zone. For a From domain of mail.example.com, the full owner is _dmarc.mail.example.com: enter _dmarc.mail in the parent example.com zone, or _dmarc in a separately delegated mail.example.com zone. Use the full owner instead where the editor requires it, and never create a new child policy merely to override an inherited policy without the domain owner's approval.

Owner: _dmarc.mail.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use an approved, monitored report destination. An external reporting service may need destination-side authorization; use its supplied instructions. Aggregate reports help identify source volumes and alignment failures but are not real-time delivery receipts. DMARC aggregate reporting.

Review all legitimate senders before tightening enforcement. RFC 9989's reject-policy guidance includes valid DKIM and indirect-mail considerations. One successful template test is not a domain-wide enforcement decision. DMARC operational guidance.

Troubleshoot by the failing layer

• DNS exists, DKIM is absent: confirm Support activation, the precise workflow and the emitted selector. A public key cannot make an inactive sending path sign.
• DKIM fails: compare the exact key, owner and selector; then investigate post-signing footer or gateway modifications. Do not rotate or delete keys before understanding queued-message dependencies.
• DKIM passes but does not align: compare the template From, effective Sending Email Domain and signing domain. Inspect strict versus relaxed alignment before changing settings.
• Only some users fail: compare profile defaults, template overrides, formula output and permissions. Retest the affected cohort using non-sensitive content.
• Authentication passes but links fail: investigate tracking DNS, certificate policy and domain retirement separately.
• SPF reports an error: repair the actual policy or DNS failure. A DKIM pass is not evidence that an SPF permerror is harmless.

Fictional example: From is sender@example.com, while a passing signature uses d=mail.example.com. It aligns under relaxed mode but not strict mode. Without the SPF result and other signatures, that fact alone cannot determine DMARC's overall result. The next step is to inspect the effective policy and template, not declare every message blocked.

If a change must be reversed, restore only the approved affected configuration. Preserve unrelated senders and retain old selectors while pending signed messages need them. Do not delete an Approved Email domain without addressing old links.

Related route guidance

If the organization also sends application mail through Microsoft 365, review that separate route using the Microsoft 365 connectors, SMTP relay and direct-send guide. Those Microsoft 365 settings do not configure Vault CRM; the distinction helps preserve the other legitimate senders sharing a domain.