Creating a Sending Domain

To be compliant with both industry standard email authentication technologies and USA CAN-SPAM and EU Directive laws regarding domain spoofing, companies must allow Approved Email to send emails on behalf of their registered domain. To do this, users must properly configure and authenticate at least one domain and create DNS (Domain Name System) entries.

Configuring a domain accomplishes the following:

  • Technically segregates a customer’s outbound corporate email from Approved Email. This protects the sending IP addresses used by corporate email servers
  • Ensures outbound Approved Emails are properly authenticated and have a valid <return-path> header not spoofed
  • Ensures Approved Emails pass industry-standard email authentication protocols widely used by MS Exchange and public webmail providers. These standards include the following: 
  • SPF (Sender Policy Framework) - An email-validation system designed to detect email spoofing by ensuring incoming mail from a domain is sent from a host authorized by that domain's administrators
  • DKIM – A Google standard widely adopted by email providers and Exchange servers designed to detect email spoofing
  • SenderID – Anti-spoofing protocol derived from SPF and pioneered by Microsoft. Used by all MSFT webmail services
  • Preserves the outbound branding and appearance of Approved Emails so recipient email clients do not display messages indicating emails are sent from third party systems

IP Addresses Used by Approved Email

Approved Email uses the following IP addresses when sending emails:

  • 166.78.71.146
  • 23.253.183.59
  • 69.72.45.59
  • 69.72.45.60
  • 69.72.38.129
  • 69.72.38.253
  • 69.72.38.86
  • 69.72.45.19
  • 69.72.45.45
  • 146.20.112.28
  • 146.20.112.29
  • 161.38.198.122
  • 161.38.198.132
  • 161.38.198.50

Customers who receive emails only from an allowed list of IP Addresses should update the list with these addresses.

Domain Types

When creating a sending domain, users have the following options:

  • Domain – An identification string defining a realm of administrative control by an organization within the Internet. Domains are best if the customer wants emails to be from the user’s email address, assuming the format is user@company.com
  • Subdomain – A domain that is part of a primary domain. An example of a subdomain is @promotions.company.com, where @company.com is the primary domain
  • Brand Domain – Reinforces product branding, but may also limit the ability to use the user's email addresses in the "from" header. An example of a customer sending domain is @cholecap.com, with a from header of promo@cholecap.com

It is recommended to configure Approved Email using a Subdomain rather than a Domain. This ensures that there are no conflicting DNS records within the primary Domain.

While this functionality may still work if you use a corporate domain, it is not a recommended configuration. Corporate domains may be used by other services, which can impact the delivery of emails. Because SPF records are created against the corporate domain, they may break existing integrations and affect email deliverability.

The following images display different email headings depending on email address and domain combinations in different email clients.

Example 1

  • From Address: sarah.jones@mail.verteobiopharma.com
  • Email Domain: mail.verteobiopharma.com

Email header from Gmail:

Email header from Yahoo:

Email header from Outlook:

Example 2

  • From Address: sarah.jones@verteobiopharma.com
  • Email Domain: mail.verteobiopharma.com

Email header from Gmail:

Email header from Yahoo:

Email header from Outlook:

Example 3

  • From Address: sarah.jones@veeva.com
  • Email Domain: mail.verteobiopharma.com

Email header from Gmail:

Email header from Yahoo:

Email header from Outlook:

Configuring Sending Domains

To set up a sending domain or subdomain:

  1. Define the sending domains or subdomains. For example, company.com or subdomain.company.com.
  2. Create a CRM Support Ticket to create the domains in the enterprise email engine.

  3. Create the specific DNS entries provided by CRM Support to authorize the domain. Three DNS records are required per domain:

    • One TXT record for SPF and SenderID authentication

    • One TXT record for DKIM and DomainKeys authentication. A DKIM DNS record is required to prevent customer emails from being placed in the Spam folder

      For security reasons, Veeva provides customers with 2048-bit DKIM keys. If this key is too long for the domain host to process as a single entry, it may need to be split into two records in the DNS management tool.

    • One CNAME record used for URL redirects. This is used to track recipient opens and click-throughs

    See Domain Verification Walkthrough on MailGun's Online Help for more information.

    When creating records for subdomains, some DNS providers will append the domain to the entered subdomain. For example, entering mail.domain.com as the subdomain may result in the DNS provider setting up the subdomain as mail.domain.com.domain.com. Customers should be aware of the behavior of their specific DNS provider.

  4. CRM Support validates the customer supplied DNS entries, either with a standard dig (on Unix) or nslookup (on Windows). For example:

    • dig CNAME email.customer-domain.com
    • dig TXT customer-domain.com

Configuring Subdomains

Additional configuration for subdomains:

  1. Create a custom formula text field on the User object with the following value:

    FirstName & '.' & LastName & '@subdomain.com'

    Replace subdomain.com with the newly created subdomain.

    Veeva recommends creating a formula field. If the domain has DMARC enabled and the policy requires that the subdomain used to send the email and the domain of the From Address must match, the formula field matches the two.

    An invalid email address is generated with this formula if the user's first or last name contains special characters, or if the user has more than one first or last name. Adjust the formula accordingly if any of the mentioned criteria applies to one or more users.

  2. Grant all users at least FLS read permission to this field.

  3. Use the {{ObjectAPIName.FieldAPIName}} token to reference the new custom formula field in the From Address field in all appropriate Email Templates.

    The Reply To Address field can still use the {{userEmailAddress}} token.

  4. Sync Vault with CRM.

Verifying Domains

To verify an email domain is setup correctly, Veeva recommends using Port25. To receive the results for an email address, users must send a sample email message to the check-auth address. For example, to check the results for jsmith@yourdomain.com, users need to send a sample message to check-auth-jsmith=yourdomain.com@verifier.port25.com

A reply email is sent with an analysis of the authentication status. The report performs the following checks:

  • SPF
  • SenderID
  • DomainKeys
  • DKIM
  • Spamassassin

After the domain is verified, Admin users enter it into the APPROVED_EMAIL_DOMAIN_vod Approved Email Custom Setting. See Approved Email Custom Settings for more information.

Emails from unverified domains are not sent. Unverified domains include, but are not limited to, those not having the required DNS records or those where the required DNS records were modified or deleted after they were created.

Requesting Veeva to delete or remove a domain from Approved Email configuration prevents recipients from accessing any links sent in emails using the domain. The recipient will not be able to view the content if they select the link.

HTTPS Tracking

HTTPS tracking is enabled for any domain registered for Approved Email. The service utilizes Let’s Encrypt with HTTP-01 challenges via the existing tracking CNAME record to issue a TLS certificate. The domain must fulfill at least one of the following conditions:

  • Have no CAA DNS records for the parent domain

  • Have CAA DNS records, with one record pointing to Let's Encrypt

    In this case, the domains must allow Let’s Encrypt to generate the TLS certificate appropriately

If domains are unable to meet the above requirements, contact Veeva Support to switch to HTTP tracking.

If a domain was registered for sending Approved Email before January 12, 2022, contact Veeva Support to enable HTTPS tracking for the domain. The above two conditions are still applicable for enabling HTTPS tracking in existing domains. Links created before HTTPS is enabled are still tracked.

Cloudflare Proxy

If Cloudflare is used to manage DNS, admins must disable Cloudflare’s proxy for the CNAME record and ensure it's set to DNS only. This is because the CNAME record is used to generate the certificate, renew the certificate, and terminate TLS whenever an https link is selected.

CDN solution

If a third party CDN solution was previously used, admins must update the CNAME record to point to mailgun.org. Contact Veeva Support so that a TLS certificate can be generated for the tracking domain.