PowerMTA Configuration
In one of the earlier knowledgebase articles, we have learned setting up sending servers within MailCarry, where you can connect it to PHP Mail, SMTPs, ESPs and Cloud-based services like Amazon SES, SendGrid and others. But if you are looking to send using the PowerMTA mail server, we have got a specialized function for you. PMTA is probably one of the most used servers for high volume email delivery, and since a large portion of large volume senders uses it, MailCarry has made PowerMTA configuration easy with its specialized module.
In this Aritlce
- How can I configure the PowerMTA server?
- How can I use PowerMTA with MailCarry?
Click “PowerMTA” under the “Setup” menu on the main navigation to start setting up the PowerMTA server. The process is divided into several small and well-organized steps to help you learn and execute every step easily. We’ll take every step and discuss it separately in the following area.
PowerMTA Server
The first step is the general information for the internal system reference and information to establish a connection with the server having PowerMTA installed. Let’s get started.
Name
Give a name to your server entry which is the mandatory field to fill but not connect to the PowerMTA config, it is for the internal system reference only. The name will later help you identify while selecting the sending server for a drip, follow-up or regular campaign.
Server OS
Select from the available operating system options for the server where PowerMTA is currently installed at. The module currently supports both Linux distribution based operating system 1) CentOS and 2) Ubuntu. Select the right option for your current PowerMTA server. CentOS are preferably used for the PowerMTA server and it has further two OS versions to select an appropriate one. However, you’ve got an option if you are using Ubuntu.
Server IP
Provide the IP address of the server/VPS where PMTA is currently installed. This would be the main IP address of your server in most cases.
Port
The data you transfer over the internet between two systems uses SSH technology for encryption and authentication. Like in this case, we’ve MailCarry client and PowerMTA server for the transmission of necessary data. Mention the communication endpoint/ TCP port for the SSH protocol in this field. 22 is the well-known system port that you use for the SSH/secure login. But, if a port other than 22 is used for security or other reasons, mention the right port in the field.
Username & Password
The next two fields are for providing the authentication credentials to finalize the information necessary for MailCarry to establish a connection with the PowerMTA server. The username and password of the root user is required in these two fields. The root user is the default user in the Linux environment that has access to all the files and commands and also referred to as superuser or root user account.
PowerMTA
On this specific part of the process, the required set of information is organized under two headings, one for the SMTP details and the second for the general config settings of PowerMTA. Let’s start with the SMTP details first.
SMTP Details
The protocol (Simple Mail Transfer Protocol) which enables the delivery of out-going emails over the internet, this section of the process requires information to setup an SMTP for the MailCarry to connect with.
SMTP Host
If the MailCarry and the PowerMTA is installed on the same server, the value for the field will be the simple “localhost”. If the PowerMTA server is remotely located, and MailCarry is installed on a different instance, then you need to provide the qualified path to the SMTP server, i.e. smtp.yourdomain.com or can also be the IP address of the SMTP server.
SMTP Port
Fill in the port that SMTP will use for routing the email over the internet. It can be the default SMTP port 25 or alternative ports like 2525, 2526 for encrypted connection and 587 also. Some ISPs block port 25 to avoid the email spam, therefore, mention the right port to proceed.
PowerMTA Settings
Fields from here on are specific to the PowerMTA settings, preferences and controls. Let’s take each one of them to learn what information every field requires.
PowerMTA Path
PowerMTA path to the current installation directory, the suggested path etc/pmta is already filled in this field, and it required storing the config file changes which later can be reviewed at etc/pmta/config. However, if you’ve installed PowerMTA somewhere else, mention the right path in this field to proceed.
Management Port
PMTA offers a web-based interface with really useful insights from the sending and deliverability perspective, known as PowerMTA web monitor. The communication is made possible by using a TCP port for the PMTA monitor, i.e. http://server.domain.com:8080. Here in this example case, the monitor opens at 8080, the port for the HTTP. Since 8080 is largely used HTTP port, MailCarry too indicates this 8080 to fill as a port for HTTP access. But, if there is another port used for the monitor, you should mention it here in this field.
Admin IPs
IP addresses that you’ve allowed accessing the web monitor as an admin. In most of the cases, it is the main IP address of the PowerMTA installation server only, however, you can add more IP addresses for the admin access and can mention all the IPs here in this field separated by a comma, i.e. 103.0.9.12, 103.0.9.15.
Log File Paths
Four fields from here on are can generally be referred to as the logging file paths.
However, PowerMTA maintains separate files for different kinds of events and queuing. In this regard, log files are maintained for start, shutdown and error logging. When an error occurs during startup, installation, and modification, you look log files for the traces. There are two files.CSV formats, the acct (accounting) files maintain the email activity logs, i.e. bounced backs, and the diag files would maintain status notifications. And the final Spool file would store the queued messages. You can see all the fields we have been talking about are filled with the default/suggested paths for these files. If you’re planning to store the files on some other place, mention the path in the respective field to proceed.
DKIM Path
Domain key identified mail (DKIM) is the famous email authentication that is validated with a pair of public and private keys. Later in this process, we’ll learn more about creating the key pair for the sending domain, where one is for the DNS of the sending domain and the other one is to be stored in the sending server. In this field, you’ll mention the path of the file where the server key of the pair is to be stored.
VMTA Prefix
Virtual MTA is the technology PMTA uses to control IPs and Host to create several virtual gateways with one MTA server. The VMTA prefix is the value that appends with each VirtualMTA in the config file.
IP and Domains Configuration
The third step is for mentioning the sending IPs and Domains you’ve in your server. There are two separate text boxes, one for the IPs and the second is for the domains. If you are having multiple entries of sending IPs and domains, you can add them comma-separated, i.e. send.domain1.com, send.domain2.com, send.domain3.com. Using these domains and IPs, MailCarry will create the distribution scheme in the next step.
Distribution, Mapping and From Information
Based on the number of provided IPs and domains in the previous step, the system takes every domain and equally distributes IPs for the sending domains. At this step, each sending domain is being displayed separately with its number of IPs and other preferences to set.
From Information- From information has already been discussed in detail in the article “Sending Domain”. It is basically the set of routing information that goes along with every message and includes, from the name, a send from an email address, and email for replies and a return-path/ bounce email. Every domain you’ve entered as a sending domain has to be configured with this information. Provide the appropriate information and proceed to the next step.
Bounce Configuration
Unlike the regular sending server where you select from the readily configured bounce handlers, here in case of PowerMTA, you need to setup your bounce handlers with the sending domains you’ve added during the process. Just in the previous step, you added a Bounce Mailbox as part of from information, here in this step, you’ll connect to this bounce mailbox to help the system read the bounce notices and process them.
Every domain needs to be connected with its respective bounce mailbox. If you’ve added multiple domains, you’ll see all of them listed here. Clicking on any domain will expand the page and display the options and preferences to connect MailCarry as an email client with the bounce server (Bounce Mailbox) via IMAP/POP. The process of connecting to bounce mailbox has already been discussed in detail in its specific article, click the following link if you need help while connecting to bounce to account.
Validate- If you want to check the information provided with regard to the bounce mailbox before proceeding to the next step, click “Validate” to see if the connection is successfully establishing.
DNS Configuration
In this step, you would implement the provided DNS records to give the setup a final push. MailCarry automatically generates record values for every sending domain, as well as a couple of records for the DNS of your MailCarry installation domain too. You can click the domain to expand the page and see the corresponding records. Access the DNS of each domain you see the records of to implement them in their respective zone editor.
The following area briefly discusses the records you’ll need to publish.
Records for MailCarry Host Domain
Apart from the sending domain DNS update, you also need to edit the zone editor of your MailCarry host domain with a couple of records. Click the host domain entry to expand the page and view the records. The first is the “A” record type which resolves to one of the sending IP addresses you’ve provided during the process. And second is the DKIM key for the fallback domain. If the primary DKIM that we’ll discuss later for the sending domains fails, the system will automatically shift to this fallback DKIM key configured with the MailCarry DNS host. So having a fallback domain is setup with the key pair, you are likely to increase the chances of delivery, even when the primary DKIM of the sending domains fails or doesn’t match.
DKIM
We’ve talked about the DKIM and how it works in one of the earlier articles about the sending domains. Here in this article, we’ll just discuss implementing this public key record of the DKIM pair in your DNS.
Host– The host field value comprises the sending domain with a prefix/selector value as mail._domainkey. Some of the DNS zones append the domain name automatically; therefore, you may need to add just the selector value (mail._domainkey). While in other cases, you would provide the complete value with the domain name included.
Type– The text under this column is indicating that you should select the record type as TXT within your DNS zone editor.
Value– Copy the DKIM public key value from under the value column and paste it in the txt record value of your DNS editor. It completes your DKIM public key entry.
Tracking Record/CNAME
The CNAME is a type of record that maps a domain name to another domain which it points to. Using this record, you form a tracking link that will enable MailCarry to track the opens and the clicks.
Host– Host field value contains the sending domain with a selector/prefix value as “track”. Some DNS zones may append the domain name automatically and you would just add the select “track” in the host field. For other cases, you’ll add a complete value with the domain name.
Type– You’ll need to select CNAME as a type of record within your Domain Name System (DNS) to start adding this record values.
Value– For the value of CNAME, you’ll point the tracking URL towards the current MailCarry installation URL i.e. demo.mailcarry.com, in case you are learning the scenario from the demo MailCarry account. In simple, the tracking URL on your sending domain will point to the current installation domain of MailCarry to enable it to track opens & clicks.
Forward DNS
Each IP is allocated to a specific domain and in case of more than one IPs available for a single sending domain during the setup; the distribution scheme will setup the virtualMTAs by adding the VMTA prefix with the sending domain name and allocate available IPs to the VMTs. To make this configuration work properly, you’ll need to publish “A” record to indicate the domain resolves to the specific IP.
Host-The VMTA host for the host field value of the DNS is being created adding the VMTA prefix you had provided earlier during the setup appending with the sending domain.
Type– The type of record in the DNS would be “A” for this entry.
Value– The FDNS resolves a domain name to an IP address. In this case, the sending domain VMTA host resolves to the sending IP as a complete “A” record value. Copy the IP address system has allocated to the specific domain/VMTA.
Reverse DNS or PTR
The PTR in the DNS is a record that resolves an IP address to a domain/host. The reverse of what we’ve just done for the FDNS.
Host– The sender IP is the host value here
Type– The type of record will be “A” as in the case of FDNS entry
Value– As mentioned it is reverse to what we’ve just done for FDNS; the VMTA host/domain will be the value to complete the record entry in the DNS.
After you are done with the setup of validation and DNS records, you can proceed to have a final review of the configuration and finish the process.