Veeva has distinct email surfaces. This procedure follows current Vault CRM Approved Email documentation, not generic Vault application notifications or an assumed equivalent legacy CRM screen. Identify the licensed workflow and the exact template From identity before changing a domain. Authentication alone does not establish healthcare marketing consent or legal compliance.
Provision the sending domain with Support
Define a sending domain, preferably a dedicated subdomain under the vendor's recommendation, and open a Vault CRM Support ticket to provision it. Publish the specific records Support supplies: SPF TXT, DKIM TXT and a tracking CNAME. The guide specifies 2048-bit DKIM keys. If your DNS interface requires chunking, keep the chunks within one TXT resource record, not competing key records. Have Support validate the entries. After verification, configure approved_email_domain__v in the Approved Email Custom Setting. Vault CRM domain setup
When using a subdomain, coordinate template From addresses with the user formula field and permissions described in the guide, then sync the content. A subdomain relationship may satisfy relaxed DMARC alignment, but strict alignment requires exact matching domains for the mechanism relied on. Do not assume a Reply-To change fixes From alignment.
Preserve tracking and prior content
Keep authentication records distinct from the tracking CNAME. The vendor documents DNS-only treatment for that CNAME when using Cloudflare, and CAA compatibility for HTTPS certificate issuance. Resolve certificate-policy questions with the security owner rather than disabling protections casually. Removing a sending domain from Approved Email can break access to links in previously sent messages. Plan retirement around old content as well as new sends; deleting the domain is not a routine rollback.
Check the generated user address for names with spaces or special characters; a formula can yield an invalid address even when DNS is correct. Grant read access to the field, reference it in each applicable template and sync Vault with Vault CRM. For domains registered before 12 January 2022, the guide directs administrators to Support for HTTPS enablement. A former third-party CDN path also needs Support coordination. Do not downgrade to HTTP or change certificate policy merely to get a green DNS check.
Verify DNS and a real receiving result
Before changing Vault CRM Approved Email, export the existing DNS values, record the approved diff and name the rollback owner. Confirm whether the DNS editor expects a relative label or a fully qualified name; doubling the domain suffix creates a record that no intended verifier will find. Query the actual owner name after saving, including any CNAME target, rather than relying on the editor's success banner.
SPF must remain one policy at the relevant domain and stay within the DNS-querying-term limits in RFC 7208. Adding an include does not itself establish alignment. Under RFC 9989, DMARC passes when at least one successful SPF or DKIM result aligns with the visible From domain under the applicable mode. Do not require both mechanisms to align as a condition imposed by the standard, and do not mistake a provider-domain pass for an aligned customer-domain pass.
Send an Approved Email generated with the relevant template and user identity to a mailbox you control. Save the receiving system's trusted authentication results, visible From, envelope identity, DKIM d= and s= values, timestamp and provider status. A DNS lookup only shows the available key; RFC 6376 verification also evaluates the signature over the received message. Use non-sensitive content and avoid exposing full customer messages to public checkers.
Use a bounded acceptance and rollback decision
Fictional written diagnostic case only: VE-01 assumes From alex@clinic.example and a valid DKIM signature with d=mail.clinic.example. This signature aligns in relaxed mode but not strict mode. SPF and other signatures are unknown, so strict-mode DMARC failure is not established. The Vault CRM owner must compare the effective alignment mode and template formula, check generated addresses for affected users and sync approved content before retesting. No patient data is needed. No account, DNS, relay or message was tested for this example.
If the test fails, separate missing DNS, wrong selector, inactive provider configuration, unexpected routing and message modification before making another change. Retest the same workflow after each approved correction. Do not weaken the whole domain's DMARC policy to hide a single sender problem. Where rollback is needed, restore the approved prior routing or sender configuration and retain key records while queued signed messages still need them. Keep the test evidence and unresolved exceptions with the domain inventory. No tenant access, DNS change or real sending was performed in preparing this guide.
Keep an accountable acceptance record
Create one row per account, domain and materially different route. Record the business owner, DNS owner, change reference, intended From, observed From, envelope domain and SPF result, each DKIM d= and s= with its result, applicable alignment mode, trusted receiver and timestamp, provider activation state, placement observation, unresolved question and next action. Mark missing values unknown rather than treating them as pass or fail. The owner accepts only the intended route and identity supported by the recorded evidence; otherwise hold that route and follow the approved recovery plan.
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.