LTG/PeopleFluent SaaS Email Practices
AntiSpam Technologies used at LTG
Important Changes to prior SPF References
Getting Help with LTG Anti-SPAM configurations
Whitelisting LTG Mail Server Addresses
Anti-Spam Protocol Configuration
Domain Keys Identified Mail (DKIM)
Domain-based Message Authentication, Reporting & Conformance (DMARC)
Many of the LTG/PeopleFluent SaaS applications may be configured to send using your company’s domain as the originator (FROM field). The PF Hosting team makes every effort to reduce SPAM, improve the delivery of messages from our email systems on your behalf, and maintain a solid email reputation for our mail servers. If your company has configured your SaaS product to use your domain name, we need to partner with your IT team to ensure the highest level of delivery and greatest level of anti-spam protection.
Please note that while LTG/PeopleFluent can provide guidance on email configurations, we cannot guarantee that email will always be delivered in a timely manner. Email standards are designed to use multiple delivery techniques, redundant or intermediate email servers, and may result in delays when reattempting message delivery. In some circumstances, systems outside our control may outright refuse delivery based on SPAM policies, system configurations or temporary server issues.
LTG utilizes SPF, DKIM and DMARC Anti-SPAM standards for most of our products. The steps on this page will ensure that mail from our SaaS systems are seen as SPF/DKIM/DMARC compliant. Configuring your systems to validate email via these technologies is highly recommended and the preferred method to ensure email delivery.
If you are unable to utilize one of these standards, our secondary recommendation is to whitelist our servers. Recipients outside your organization may not have mail delivered successfully from our SaaS services if you rely on whitelisting alone.
Also, while we may use a specific group of servers in most circumstances, our disaster recovery and load balancing practices may send mail using any of our email systems listed on this page. Whitelisting will only be successful if it includes all our current email system addresses.
This page’s configuration recommendations were last updated on 8 June 2023. Please check your email system configuration to ensure your company is leveraging our most recent practices.
You may also set up an automated DNS TXT query to obtain the date of our most recent best practice changes:
nslookup -type=txt last-updated.ltg.email.
OR
host -t txt last-updated.ltg.email.
spf.hire.com Immediate Deprecation
As of 1 June 2022, LTG/PeopleFluent retired the use of spf.hire.com. After 1 August 2022, any references to this record may not contain accurate PeopleFluent SPF data.
spf.peopleclick.com and spf.ltghost.io Transition Period
The spf.peopleclick.com and spf.ltghost.io records will continue to function for a transition period, but should not be used after 1 January 2023.
If you or your IT teams have any questions about how SPF/DKIM/DMARC are implemented at LTG/PeopleFluent or need help setting up appropriate records please contact our support team or your account representative and we can exchange emails and/or schedule a call to answer your questions.
LTG/PeopleFluent uses a number of email servers to send messages from our SaaS systems. If you are unable to configure your mail servers to use SPF/DKIM/DMARC, you may whitelist our mail server addresses.
Please note that this only helps recipients within your own organization. Individuals using other email systems (like job applicants, individuals using personal email addresses or even other domains in your own company) may still have messages marked as SPAM or outright rejected; we recommend you do not count on whitelisting alone and set up both whitelisting for your systems if you are unable to support other standards AND also the necessary Anti-SPAM protocol records to ensure the greatest chance of email delivery to all recipients.
The current list of hostnames and IP addresses of our outgoing email systems may be queried by doing a DNS lookup for spf.ltg.email and is as follows:
150.105.185.150
150.105.217.150
165.193.101.141
165.193.101.49
165.193.56.42
205.217.12.155
208.2.164.108
38.225.210.141
Email sent from LTG/PeopleFluent SaaS applications with a FROM address using your company’s domain may not be successfully delivered or may be marked as SPAM by both your company’s email systems and/or a third party’s email system.
The best way to solve this is to designate all LTG/PeopleFluent email servers as authorized to send email on your company’s behalf.
A number of email anti-spam protocols have been defined to help address this problem.
Sender Policy Framework (SPF) DNS records allow the recipient’s email system to validate that the sending email system is permitted to send emails for a particular domain. For LTG/PF to send messages on your behalf, SPF records are added to your company’s public DNS and allow the recipient’s email server to query the DNS record to validate the LTG/PeopleFluent server is authorized to send mail that appears to originate from your company’s domain.
Public SPF records are added by your company’s DNS administrator. Please review http://www.openspf.org/ for more information about how SPF (Sender Policy Framework) is used and configured.
PeopleFluent maintains a public DNS record called spf.ltg.email that contains the entire set of IP addresses that we use to send emails for our SaaS applications. To avoid the need to stay current on our current list of IP addresses, and to limit the number of DNS queries required for SPF validation, we recommend adding the spf.ltg.email hostname to your SPF record.
Examples:
If you don’t currently use SPF for your company but configure it to include LTG servers:
company.com IN TXT "v=spf1 a:spf.ltg.email ?all"
This example would allow a company that currently does not restrict the origination of email from their domain, but wants to explicitly permit LTG/PeopleFluent email servers to send messages on their domain’s behalf. In this case, the “?all” qualifier at the end of the SPF record indicates that the domain does not have a SPF policy in place to prohibit other addresses from sending email, but explicitly authenticates servers from LTG.
If you currently use SPF for your company, and update it to include LTG servers, you may see a record similar to:
company.com IN TXT "v=spf1 MX a:spf.ltg.email -all"
In this example, your company says only mail from MX systems (mail servers) defined by other records in your domain AND the spf.ltg.email servers may send email. The “-all” states that mail from any other sender not listed must be rejected.
Advanced SPF Topics:
At one time two types of DNS resource records were permitted by the SPF standard. The first is a TXT resource record, which is the current RFC standard and is what LTG/PeopleFluent recommends. The second resource record is a SPF resource record type. If your company still uses a SPF resource record, or both a SPF and TXT resource record please consider updating to the current best practice of using a TXT record or consult the most recent RFCs for guidance. (RFC 7208 https://tools.ietf.org/html/rfc7208) and RFC 4408 https://tools.ietf.org/html/rfc4408)
There are also multiple mechanisms that can be used to authenticate the list of sending servers. Your DNS administrator should take several factors into consideration when updating your SPF record to include our systems. These include (but are not limited to) what your current SPF policy contains, and the number of DNS queries necessary to resolve the entire list of authorized IPs.
The easiest mechanism is to list each IPv4 or IPv6 address that is authorized to send email, but is difficult to intuitively read and maintain. It also quickly becomes very long and inefficient to query.
Using DNS canonical records (A or AAAA) to match the hostname to IP address has the advantage of being easy to read but can cause a problem if too many DNS lookups are required. The SPF specification in RFC 7208 section 4.6.4 (https://tools.ietf.org/html/rfc7208#section-4.6.4) limits the number of DNS queries necessary to produce the entire SPF list to ten.
An inefficient SPF record could result in a greater number of queries and will cause errors during SPF validation. Section 10.1.1 of RFC 7208 (https://tools.ietf.org/html/rfc7208#section-10.1.1) offers some guidance and examples for the creation of new records.
Domain Keys Identified Mail (DKIM) DNS records enable email servers to use a public key to validate that an incoming email message was properly signed by an authorized sender using one of your email server’s private keys. By having your company publish the corresponding public key, you are authenticating the legitimacy of the email message.
When setting up DKIM for your SaaS application, LTG/PeopleFluent generates a private key for your domain that we use to sign all outgoing email. We will provide you with the corresponding public DKIM key to put in your DNS records.
To enable DKIM, first set up SPF allowing us to send email on your behalf, and then submit a support case with the email domain(s) you are requesting we sign on your behalf. PeopleFluent will first validate that the domains have properly added us to your SPF records and then will generate a public/private key for each domain. We will provide you with the public DNS key to be added to your DNS records. PeopleFluent usually uses the DKIM selector “pf” but can use a different value upon request if it’s in use by your domain.
Example of a DKIM record (formatted for BIND):
pf._domainkey 14400 IN TXT "v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtZU05bUP7EnS
7FpNuJ7d0HMMw+89op9YDFSDU1ehYQmyVCyhr9z42uq7V8yxUHQ0GsK
oAqQK+esJTUfnE4p3FUkgK+ZfhfVrpp+1sZh8p0T+FlkSiTBm7D6NrHfFg05P
tXP3ez3814NaZNPXVKkQRX8LwcnZxnh6FAJNLtT7E8QIDAQAB" ; -----
DKIM key pf for peoplefluent.com
This example is a DKIM record for pf._domainkey.peoplefluent.com where “pf” is the selector, _domainkey indicates this is a DKIM record, and peoplefluent.com is the domain. The remaining part of the TXT record contains the public key that recipients can use to validate the signed message headers.
As before, your DNS administrator will have to add these records to your public DNS.
Please review http://dkim.org/ for more information on DKIM.
Domain-based Message Authentication, Reporting & Conformance (DMARC) policies allow domains to publish a policy for accepting mail from their domain. The policy allows recipient mail systems to decide what to do when emails are not passing SPF or DKIM but still originates from a known system.
SaaS customers wishing to have emails originated from LTG/PeopleFluent systems sent as DMARC compliant should first complete SPF and DKIM setup. Please let us know you would like to complete DMARC configuration when submitting your DKIM support ticket.
For more information on DMARC, please visit https://dmarc.org/