Send Email Using Multiple Sender Domains

Send email from your IBM i server using multiple sender domains

Specify sender’s email domain with CoolSpools

The CoolSpools email module provides a comprehensive email delivery service that runs natively on your IBM i server. It includes its own SMTP server and is not dependent upon IBM email products such as MSF or IBM’s SMTP service, although it can be integrated with those if you prefer.

You may have a scenario where you provide hosting or services to multiple clients from the same IBM i server, and need to generate email messages using the appropriate sender domain for each client.

Similarly, your IBM i server may operate at the corporate group level, processing data for multiple subsidiary entities, each with their own branding. Can you send email on behalf of each subsidiary using the correct domain in the sender address?

With CoolSpools email the simple answer is “yes”. When you request an email, either by using the SNDCMNMSG command or the EMAIL(*YES) parameter of one of the many CoolSpools conversion commands, you can specify the sender’s email address, including the domain.

You can also use system commands to define a default email address for each IBM i system user, so that their emails will be sent using the most appropriate domain.

Trouble with SPAM filters

There is a complication. When the SMTP communication is received by the recipient’s mail system, it may identify that the domain of the server sending the SMTP message does not match the domain used in the sender’s email address, and some mail systems will treat this as an indication that the message is spam.

In our example an email message is sent using CoolSpools from an IBM i server with the domain host-domain.com using a sender email address with the domain company-one.com. The recipient’s mail system identifies that the two domains do not match, and blocks the message as spam instead of delivering it to the intended recipient.

This is not a rule that is applied consistently by all mail systems, so you may find that your messages are successfully delivered to some recipients, but not to others.

Authenticating with an SPF record

This issue can be prevented by configuring the SPF record within the domain that you are using in the sender’s email address (company-one.com in our example) to allow delivery on its behalf by the IBM i server’s domain (host-domain.com in our example). Note that the configuration is needed in the network of the domain in the sender’s address, so if this is a customer to whom you are providing services, then you will need the customer’s network team to apply a change to allow your IBM i server to send email messages on their behalf.

SPF (Sender Policy Framework) is an email authentication method designed to detect forging sender addresses during the delivery of the email. The SPF record contains a list of the network addresses (domain names or IP addresses) that are authorised to deliver email messages on behalf of a domain.

As this is a network configuration change outside of the CoolSpools application, you should follow the recommendations of your Network Support Team or Internet Service Provider for configuring SPF. We also strongly recommend that this change is applied by a qualified networks engineer. Some basic documentation is included here to provide pointers since this configuration may be necessary to allow successful delivery of your CoolSpools email messages.

The SPF record is a text file formatted as follows (this is taken from a Google example):</>

v=spf1 ip4:192.168.0.0/16
include:_spf.google.com
include:sendyourmail.com
~all

The above example authorises the following to send emails on behalf of the domain where it is installed:

• IP addresses in the range 192.168.0.0 to 192.168.255.255
• Google workspace domain _spf.google.com
• A custom network domain sendyourmail.com
• Note the use of ~all to indicate that other domains not in the list are permitted but treated as suspicious. An alternative of -all is more likely to result in domains not in the list being blocked entirely.

For our example, sending emails as company-one.com from a server in network domain host-domain.com requires us to add the following to the SPF record for comany-one.com, or to create a new SPF record if none exists:

include:host-domain.com

The SPF record must be applied to the domain by uploading it as a DNS TXT record using the management console of the domain provider. The location and appearance of this option will vary depending upon your domain provider.

A domain should have only one SPF record, so each time you need to authorise an additional domain or IP address, you should add it to the existing SPF record, so as not to lose any authorisations that have been applied previously. Note that it can take upto 48 hours for the SPF change to take effect.

You can verify the SPF status of your domains at the MX Toolbox website. Just enter your domain name, and you will be presented with details of the SPF authorisations found on the internet. This is the same as the recipient mail servers will see when assessing the level of threat of email messages that they receive. Contact us today.