Salesforce Email Domain Key Object

Integration with the Salesforce Email Domain Key Object

FormTitan is an online web tool that allows you to create web forms and landing pages - it is a Salesforce form builder. The FormTitan form builder can easily integrate with salesforce email domain key object. Not only does this require no coding skills on your part, but the salesforce connector is seamless and powerful. Unlike other products, our salesforce connector not only writes to your salesforce email domain key object but it can also read from it and populate your online form fields instantly. Furthermore, You can read from multiple objects at a time, with or without dependencies and query your objects based on any value from your form. 



About the Salesforce Email Domain Key Object
Represents a domain key for an organization’s domain, used to authenticate outbound email that Salesforce sends on the organization’s behalf. This object is available in API version 28.0 and later.

Use this object to define a DomainKeys Identified Mail (DKIM) key, which is used to authenticate outbound email that Salesforce sends on your organization’s behalf. When you create a DKIM key, Salesforce generates a public and private key pair. You must publish the public key in the DNS, which tells recipients that you, as the owner of the domain, have authorized the use of this key to sign your mail. Salesforce uses the private key to create DKIM signature headers on your outgoing email. Then, recipients of the mail, can compare the signature header with the public key in the DNS to determine that the mail was signed with an authorized key. If your domain also publishes a Domain-based Message Authentication, Reporting and Conformance (DMARC) policy, recipients can use the DKIM signature to verify that the mail conforms to DMARC.

For each domain key you create, we recommend this sequence:

• Insert the Domain, DomainMatch, and Selector.
• Update your domain’s DNS records.
  • Locate the DNS record at selector._domainkey.domain. For example, mail._domainkey.mail.example.com.
  • Add the PublicKey value, like this: V=DKIM1; p=public_key.
• DKIM Signing Outbound Email
  • In addition, you can optionally put the record in testing mode, which instructs recipients to not make decisions based on the email signature. Add parameter t=y to the DNS entry, like this: V=DKIM1; t=y; p=public_key.
• Update the key via the API or UI to be active.

Consider the following when using domain keys.

• Make sure you add the public key to your DNS record before you make your key active in Salesforce and start DKIM signing. DKIM signing is active whenever your DKIM key is in the active state.
• You can’t have more than one active DKIM key per domain name. You might have multiple active DKIM keys if your organization mails from more than a single domain or if you use subdomains under your organizational domain and have specified domain matching at the subdomain level.
• If you want to use the same DKIM key for multiple organizations, you can. Create the key and ensure it’s working for one organization first. Then using the API or UI create the key in your other organizations by setting the corresponding fields in the new key to the same values as the original.
• When you insert or update a DKIM key, it’s possible that the change affects existing domain keys. For example, if you’ve set DomainMatch to DomainAndSubdomains for the example.com domain, and you then set DomainMatch to SubdomainsOnly for the mail.example.com domain, either key could be used. Here’s how we resolve conflicts in the case when DKIM keys overlap.
  • If two keys are equally specific about matching for the same domain, the new key replaces and deactivates the existing key.
  • If a new key is more specific about matching than an existing key, the new key is used and the existing key is modified to inactive.
  • If multiple keys have different domains that match the sending domain, the key with the longest domain name is used. In case of a tie, the most specific key is used. For example, because DomainOnly and SubdomainsOnly are more specific than DomainAndSubdomains, a new DomainOnly key would change the DomainMatch for an existing DomainAndSubdomains key to become SubdomainsOnly. In case of a tie, the most specific key is used.