There is never any guarantee that email you are sending out will not be blocked on the basis of IP reputation or blacklisting or that email you are sending end up in spam/junk mail folders. However to minimise the chance this happens a few things can be done to make your domain and mail servers as trustworthy as possible.
In this article I will discuss 3 techniques that can go a long way to enable more reliable delivery of your email to other email systems. These are:
- SPF - Sender Policy Framework
- DKIM - Domain Keys Identified Mail
- DMARC - Domain-based Message Authentication, Reporting, and Conformance
When using the Micro Focus Secure Messaging Gateway you can use DKIM and SPF for inbound and outbound email traffic. The Gateway is recommended for all GroupWise systems as support by the Micro Focus GroupWise GWIA (internet agent) is limited to outbound SPF only. The GWIA does not support SPF checks for inbound email, DKIM either inbound or outbound and consequently DMARC is not an option as this depends on both SPF and DKIM to work.
SPF
SPF is a way for a receiving mail server to verify that the sending server is actually allowed to send mail for a specific mail domain. (The mail domain is the part after the @ sign so for example microfocus.com). If the receiving mail server supports SPF checks it might deny messages when the sending server IP number is not in the SPF record, as IP number or one of the IP numbers in the included lists. The way this is handled by the receiving email server is also determined by the SPF record, which can be set to a hard fail - so it will be denied - or a soft fail in which the email is accepted but is flagged in the header as SPF failed.
SPF works with DNS records of the type TXT for the mail domain used, so you can create for example the following record for your domain in DNS.
Host: company.com
Type: TXT
value: v=SPF1 MX A ~all
This record is the most basic form you can create and indicates that the version of SPF is 1 with the v= parameter. Next the MX and A records defined for company.com are allowed to send email for the company.com mail domain. The ~all indicates a soft fail so the receiving server should always accept email from any server sending email for company.com regardless if this is a MX or A record. When a message is sent by a host that doesnt have a MX or A record defined for the mail domain company.com the message will be flagged in the email header as SPF failed so other subsequent spam checks making use of this parameter may move the email to a spam folder or even quarantine the email.
From this point onwards you can make the SPF record more specific and/or stricter. The options you have are to define specific IP numbers that are allowed to send mail with the command format ip4:x.x.x.x so if there is only one server allowed to send mail for company.com the SPF record value would look like
v=SPF1 ip4:x.x.x.x ~all
This is still specifying a soft fail however and if the receiving server must deny the email from any other server sending the mail other than the IP defined, you can set a hard fail by using the value of the record like this (notice the ~ is now - )
v=SPF1 ip4:x.x.x.x -all
The next option that can be used is to include SPF records of other mail domains you already have setup or a SPF record that is setup by a relay host you are using for outbound email. You need to get this info from your mail provider. For example, this would be the value of the SPF record when all outbound email goes through AWS ses (the AWS simple mail service).
v=SPF1 include:amazonses.com ~all
With this you tell the receiving email server that all IP numbers defined by the SPF record for amazonses.com are allowed to mail out for your email domain. Again you can set the hard or soft fail with the -all or ~all.
Finally SPF records can be setup with macros so it is easier to have multiple IP numbers without having to specify them all, a common macro used is
v=SPF1 exists:%{i}.SPF.company.com ~all
This is interpreted by the receiving host that based on the variable I (IP number) all servers with an A record like x.x.x.x.SPF.company.com are allowed to send email for the company.com mail domain. So for example if a server with IP number 1.1.1.1 is sending the mail out the receiver must be able to resolve the 1.1.1.1.SPF.company.com A record that has the value 127.0.0.2.
There are a lot more options in macro's and things related to SPF. A good starting point for more information is http://www.open-SPF.org/
Checking and Verifying SPF records
You can check and verify DNS records defined by using one of the many SPF verify websites out there or just use the command line tool dig like
dig -t txt company.com
This will result in output similar to this, the value can be anything as described above.
company.com. 299 IN TXT "v=SPF1 MX A -all"
As you have seen SPF records are able to provide the information to receiving mail servers about which servers are or not allowed to send mail for your domain. However this does not mean all email systems in the world will use the SPF record you have defined. Even when this is possible with software such as Micro Focus Secure Messaging Gateway, Postfix or other mail servers it always depends on the system administrator of the server if SPF is enabled and configured to actually check SPF records. If it is not setup or configured correctly all you do will be ignored . We do see however more and more systems starting to use SPF. Google and Microsoft for example use it and it can help to make email transfers more trustworthy.
DKIM
Domain Keys Identified Mail (DKIM) is a mail authentication method to detect forged sender addresses in emails. DKIM allows the receiving mail system to check if an email from a specific domain was indeed authorised by the owner of that domain. This is done by a digital signature thats linked to a domain name and is part of each outgoing email message.
The receiving system can verify this signature by looking up the sender's public key thats available in DNS. This signature also guarantees that the email (including attachments) have not been modified since the signature was added.
When you run Micro Focus Secure Messaging Gateway you are able to setup DKIM for inbound and outbound traffic so outgoing messages are signed with the private key generated by SMG, and inbound mail can be checked to see if the sending system used DKIM. SMG will act on this and will verify the messages are authenticated. The Micro Focus GroupWise GWIA has not implemented DKIM.
The DKIM setup in SMG is one part of the configuration you need to do. DKIM signing needs to be configured under the domain in Secure Messaging Gateway. After this a public key needs to be created or configured in the domain. This key must be entered into your public DNS record so that recipients may verify the signature. The DKIM setup in SMG under Domain Management has two required options "Domain" and "Selector" and when this is set you can use the "Generate keys" button to have the public and private key generated.
To create the DNS record click on the button "Public key". This will show the actual DNS record you need to create in you DNS environment. For example in my test system this would show as:
20201015._domainkey IN TXT ( "v=DKIM1; k=rsa; s=email; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsSlUwSezPMp2HdRsWYhu9ItTANPlq/cbUmL0reZgB+nfc9/WrePRa95gMxlshFCtPeQaort1ev5VNAP58Z4PJ1u5JagvEU3pRcHHbq2BEqWSsxY1XbHK2ZxSUjBzNPe77CXupoIC0d904ebmzzmmtpHbcjRx8WweCoUrdRw3uQm/AlzoxinbyH7jsTMwNroQbIcnn0b2Ylmrgv"b5u+RSbuiIiw2ajlqSzIulWcJO3V0PyQMfckA3UIjGNcXFUz+JTlblzq9ZeMzKX4tTPTQfsYqANWiRimrzdusPAXR5jP5FTE+3iBtgNIrOJCm3Om/I+dbawvZHBpZem8nVWxM6JQIDAQAB" ) ; ----- DKIM key 20201015 for company.com
In your DNS environment you need to create a new record
Host: 20201015._domainkey.company.com
Type: TXT
value: p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsSlUwSezPMp2HdRsWYhu9ItTANPlq/cbUmL0reZgB+nfc9/WrePRa95gMxlshFCtPeQaort1ev5VNAP58Z4PJ1u5JagvEU3pRcHHbq2BEqWSsxY1XbHK2ZxSUjBzNPe77CXupoIC0d904ebmzzmmtpHbcjRx8WweCoUrdRw3uQm/AlzoxinbyH7jsTMwNroQbIcnn0b2Ylmrgv""b5u+RSbuiIiw2ajlqSzIulWcJO3V0PyQMfckA3UIjGNcXFUz+JTlblzq9ZeMzKX4tTPTQfsYqANWiRimrzdusPAXR5jP5FTE+3iBtgNIrOJCm3Om/I+dbawvZHBpZem8nVWxM6JQIDAQAB
By doing this you make the public key available to the world, so any mail server that you send mail to is now able to verify and authenticate the message thats signed with your private key. It only needs to get the selector and domain as specified in the header of the received message. When you check the email header you will see that, when DKIM used, the following is there
DKIM-Signature:
followed by a lot of data including the public key is there but the part that is used to lookup the DNS record by the receiving mail server is :
s=20201015;
d=company.com;
You can verify this with the dig command as well, as the DNS record always has the name <selector>._domainkey.<domainname> so with the 2 parameters the record for company.com should be 20201015._domainkey.company.com
This can now be used with the dig command line like
dig -t txt 20201015._domainkey.company.com
The result should be a TXT record with the public key as you see above thats generated in SMG.
For SMG to use DKIM inbound and/or outbound the "DKIM Verification" must be set andconfigured in the Policy filter. When this is all done the outbound messages will have information included but again, like SPF, it always will depend on the receiving system if it will be used. Many mail servers are not yet using DKIM to authenticate inbound mail.
For further information on DKIM start by looking at http://dkim.org/.
DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a protocol that when configured for a domain controls what happens if a message fails authentication tests for SPF and DKIM. This is like SPF and DKIM done with a DNS record.
You as owner of the domain publish a DMARC DNS Record in you DNS environment so when an email is sent out by you or someone spoofing your domain, the receiving mail server checks to see if the domain has a DMARC record. This receiving mail server then first checks DKIM and SPF to verify if the sender is really the domain it says it is. With the DKIM and SPF results, the receiving mail server then applies the sending domain's DMARC policy as defined in the DNS record. This policy determines if the message is quarantined, rejected, or do nothing to the message if the message has failed DKIM/SPF checks.
Finally the receiving mail server (for example Gmail) will send a report (DMARC Aggregate Report) to the email address specified in the domain's DMARC record.
The setup of the DNS record is similar to:
Host: _DMARC.company.com
Type: TXT
value: v=DMARC1; p=none; rua=mailto:postmaster@company.com;
This means the version defined with the v= is set for DMARC1, the action thats taken for failed SPF/DKIM tests is set as p= parameter and can be "none", "quarantine"or "reject" and finally who should get the reports generated by the receiving mail system with the rua= parameter.
Further information on DMARC is available at https://dmarc.org/.
I have added DMARC to complete the full story but neither the Micro Focus GroupWise GWIA nor Micro Focus Secure Messaging Gateway yet support DMARC for inbound email. However you may still define it for your mail domain as receiving mail servers that support DMARC can still make use of your settings.