The email capability is used for a variety of use cases from sending notifications, 2FA emails, to powering workflows that enable data uploads. To that end, the platform exposes configuration options in Control Panel to configure email infrastructure and email deliverability to provide assurance to an Organization that email is only sent to expected destinations.
The platform primarily uses email to notify existing users. Sending emails to email addresses that are not associated with a user is restricted to specific, narrow usecases that have no possibility of leaking data (for example, user onboarding).
Email relies on a protocol called Simple Mail Transfer Protocol (SMTP). With SMTP, email messages are sent in plaintext and transferred from the platform to an SMTP relay, and then through one or more intermediary servers before it is delivered to your organization’s SMTP delivery host. Depending on how your organization has set up its mail configuration, there may be additional third parties that receive and process mail on your behalf (such as security scanning) before delivery.
To protect against emails being inspected in-transit by unauthorized parties, Palantir requires the use of Transport Layer Security (TLS), a cryptographic protocol for securing the confidentiality of email contents during transit. This ensures that any mail delivered from the platform to Palantir's SMTP relay is encrypted. Palantir's SMTP relay then tries to enforce TLS on any new connections outbound to other SMTP delivery hosts.
Unfortunately, most mail servers rely on opportunistic encryption which falls back to unencrypted plaintext delivery if they cannot enforce TLS. Depending on your network architecture, email delivery paths, mail servers, and other variables, this could lead to emails containing sensitive customer data being sent without network encryption. Additionally, even with TLS encryption, any hop in the mail delivery process grants the mail server owner plaintext access to the contents of the email message. This is especially important if your organizational risk tolerance does not allow for your email service provider(s) to have access to sensitive message contents.
Lastly, once an email message containing sensitive information has left the Foundry platform, it relies on controls in the mail server of the recipient. Depending on how the mail server has been configured, these messages could potentially be forwarded, downloaded, sent externally, or inappropriately shared outside of the platform. Strong platform security primitives and protection such as mandatory access controls or markings do not apply once data leaves the platform.
To retain strong access controls, we generally recommend that sensitive data is shared within the platform rather than being shared by by email.
Email is inherently opportunistic meaning it can be blocked by the platform, any of the mail servers in the email delivery path, the reciepient's firewall or even classified as spam or deleted based on email rules in the recipient's inbox. We recommend that critical workflows depend on mechanisms with better deliverability guarantees, such as webhooks or push notifications.
Several factors can impact email deliverability, including but not limited to:
By default, the platform uses Amazon (AWS SES) to send email.
Learn more about how to control where email can be sent.
Learn more about how to redact the contents of emails.
Learn more about how to understand why emails may have failed to send.