Source: https://vaultcrmhelp.veeva.com/doc/Content/CRM_topics/Multichannel/ApprovedEmail/ConfiguringAE/CreateSendingDomain.htm ## 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 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](https://www.cyber.nj.gov/guidance-and-best-practices/email-security/sender-policy-framework-spf-guide) (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](https://dkim.org/) – A Google standard widely adopted by email providers and Exchange servers designed to detect email spoofing * [SenderID](https://datatracker.ietf.org/doc/html/rfc4406) – 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 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. **Who can use this feature?** * System Admin Users — Browser * [Setting Up Sending Domains or Subdomains](#Configure_Domains) * [Verifying Domains](#Verify_Domains) * [HTTPS Tracking](#HTTPS_Tracking) * Users require an Approved Email license ### Configuring Sending Domains To configure sending domains, admins must complete the following tasks: * [Update lists of IP addresses](#IP_Addresses) from which the organization can receive email to include those used by Approved Email * [Consider what domain types to configure](#Domain_Types) (domain, subdomain, brand domain) * [Setting up sending domains or subdomains](#Configure_Domains) used to send approved emails * [Verify domains](#Verify_Domains) are set up correctly * [Configure HTTPS tracking](#HTTPS_Tracking) for any necessary changes [![Closed](../../../../../Skins/Default/Stylesheets/Images/transparent.gif)IP Addresses Used by Approved Email](#) Approved Email uses the following IP addresses when sending emails: * 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 * 161.38.198.122 * 161.38.198.132 * 161.38.198.50 * 198.244.56.164 * 198.244.56.157 * 198.244.56.154 * 198.244.56.148 * 198.244.56.147 * 198.244.56.146 * 198.244.56.145 * 198.244.56.144 * 198.244.56.139 * 198.244.56.138 * 198.244.56.136 Customers who receive emails only from an allowed list of IP Addresses should update the list with these addresses. [![Closed](../../../../../Skins/Default/Stylesheets/Images/transparent.gif)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: sender.name@mail.company.com * Email Domain: mail.company.com Email header from Gmail: ![](../../../../Resources/Images/Multichannel/ApprovedEmail/Config/EmailEngine.jpg) Email header from Yahoo: ![](../../../../Resources/Images/Multichannel/ApprovedEmail/Config/EmailEngine1.jpg) Email header from Outlook: ![](../../../../Resources/Images/Multichannel/ApprovedEmail/Config/EmailEngine2.jpg) #### Example 2 * From Address: sender.name@company.com * Email Domain: mail.company.com Email header from Gmail: ![](../../../../Resources/Images/Multichannel/ApprovedEmail/Config/EmailEngine3.jpg) Email header from Yahoo: ![](../../../../Resources/Images/Multichannel/ApprovedEmail/Config/EmailEngine4.jpg) Email header from Outlook: ![](../../../../Resources/Images/Multichannel/ApprovedEmail/Config/EmailEngine5.jpg) #### Example 3 * From Address: sender.name@veeva.com * Email Domain: mail.company.com Email header from Gmail: ![](../../../../Resources/Images/Multichannel/ApprovedEmail/3Gmail.jpg) Email header from Yahoo: ![](../../../../Resources/Images/Multichannel/ApprovedEmail/3Yahoo.jpg) Email header from Outlook: ![](../../../../Resources/Images/Multichannel/ApprovedEmail/3Outlook.jpg) [![Closed](../../../../../Skins/Default/Stylesheets/Images/transparent.gif)Setting Up Sending Domains or Subdomains](#) 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 Vault CRM Support Ticket to create the domains in the enterprise email engine. 3. Create the specific DNS entries provided by Vault 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](https://help.mailgun.com/hc/en-us/articles/32884702360603-Domain-Verification-Setup-Guide) 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. Ensure Vault 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 #### Setting Up Subdomains Additional configuration steps for subdomains: 1. Create a custom formula text field on the User object that generates valid email addresses. For example, see the following recommendations: ``` first_name__sys & '.' & last_name__sys & '@subdomain.com' ``` ``` Left(email__sys,Find("@",email__sys)-1) & '@[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 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. When referencing the field, capitalization should be based on the [target platform](../CreatingContent/SettingTargetPlatform.htm). For example: User.Verteo\_Email\_Subdomain\_\_c The Reply To Address field can still use the {{userEmailAddress}} token. 4. Sync Vault with Vault CRM. [![Closed](../../../../../Skins/Default/Stylesheets/Images/transparent.gif)Verifying Domains](#) Veeva recommends admins use dkimvalidator.com to verify an email domain is set up correctly. Anyone with the ability to send email from the new domain can send a sample email message to [any.email.prefix]@dkimvalidator.com using any email client. Then they can visit [dkimvalidator.com](https://dkimvalidator.com/), enter the dkimvalidator.com email address the message was sent to, and select View Results. The report performs the following checks on the sending domain: * SPF * SenderID * DomainKeys * DKIM * Spamassassin After the domain is verified, Admin users enter it into the **approved\_email\_domain\_\_v** Approved Email Custom Setting. See [Approved Email Custom Settings](../InitialConfig/Components.htm#Approved) for more information. Requesting Veeva to delete or remove a domain from Approved Email configuration prevents recipients from accessing any links sent in emails using the domain. Recipients will not be able to view the content when they select the link. [![Closed](../../../../../Skins/Default/Stylesheets/Images/transparent.gif)HTTPS Tracking](#) HTTPS tracking is enabled for any domain registered for Approved Email. The service utilizes [Let’s Encrypt](https://letsencrypt.org/) 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 ### Related Topics [Composing Approved Emails](../SendAE/ComposingAEs.htm) [Configuring Approved Email](../InitialConfig/ConfiguringAE.htm)