Emails sent using RMail services route through the RMail Cloud which is located outside the sender’s email network. The RMail Cloud is used for processing and delivery or RMail messages and receipt generation. The recipient’s email system will identify an RMail message as being sent from a mail service that is different than the sender’s standard emails.
When a sender and recipient share the same company email server, in some cases, the mail filtering software may filter the email since it will see an internal email address sending to another internal email address but coming from an external mail server, the RMail Cloud. Depending on the mail filtering settings, the filtering software may falsely flag the email.
If a mail system is providing false alerts such as “Unknown sender”, or similar, when receiving RMail messages from people within the sender/receiver domain, it is recommended to set the RMail Cloud as a safe sender in the filtering software.
RMail Message Pathway
Diagram of RMail the pathway in and out of the RMail Cloud.
If whitelisting is required, please have the network administrator set the following domains and/or IPs as safe senders ensure proper sender authorization for RMail messages.
Outbound from the RMail Cloud
The following domains and IPs should be whitelisted for RMail messages and receipts that are being improperly filtered, including RMail messages falsely flagged when sent to recipients inside the same company/domain.
- Domains: RMail outbound sending domains.
- Outbound IPs: RMail IPs used for sending emails to senders and recipients.
Inbound to the RMail Cloud
RMail IPs used for receiving emails and API calls from customers. If API calls are blocked, these IPs should be whitelisted.
- Inbound IPs:
Some RMail services transmit data to and from RMail API systems using an HTTPS connection. If your company routinely blocks some HTTPS or API connections, RPost recommends whitelisting the RMail HTTPS and API domains/servers in your firewall or other similar systems.
- API URL for RMail: webapi.r1.rpost.net
- API URL for RMail bulk: webapi.r2.rpost.net
SPF & DKIM Email Authentication
In addition to whitelisting, RPost recommends that customers implement the SPF and DKIM authentication mechanisms. These technologies utilize DNS TXT records to store their information. This information is used along with IP address and SMTP header information to establish authorization for the sender of the message.
To implement SPF & DKIM, the customer administrator must have access to a tool that can create and modify DNS records for the sender domain as well as the authorization to do so. For additional information, please see this article Setting up DKIM with RMail.
SPF – Sender Policy Framework
Typically, customer email sending domains will already have an SPF record configured. The SPF record provides authorization for a list of IP address and/or MX records to send on behalf of a domain.
SPF records can authorize the domain in the envelope from header (the Return-Path header) or the message from header (preferable). In order to utilize the message from header, customers must authorize RPost in their SPF record.
- The following wizard can be used to create SPF records: https://www.spfwizard.net
- Visit this website for a comprehensive source of SPF information: http://www.openspf.org
To authorize RPost as a sender the following text should be included in the sender SPF record.
Example of an SPF record: mydomain.com. IN TXT "v=spf1 include:spf.rpost.net ~all"
DKIM – Domain Keys Identified Mail
DKIM uses asymmetric encryption and hash algorithms to authenticate the message sender and validate the integrity of message content.
The authentication system verifies the validity of the message sender in the message from header.
To set up a DKIM record to authorize RPost as a sender, customers must contact RPost. RPost will configure the customer domain(s) on RPost sending servers send a unique public key to be included in the customer's DKIM DNS record.
Contact your RMail representative for a DKIM setup request form.