The key components to optimising email delivery (the percentage of emails received by mail servers) and deliverability (the percentage that make it to an inbox) are:
- SPF Record
- DKIM
- DMARC
- Return Path/From alignment
- PTR (reverse DNS)
- Bounce Management
- Content
SPF - Sender Policy Framework
This is a DNS TXT record that specifies the systems authorised to send mail on behalf of the domain. Inbound mail systems perform SPF checks to determine that the mail has come from an authorised source.
"v=spf1 include:spf.protection.outlook.com ip4:57.128.187.107 ip4:57.128.189.44 -all"
v=spf1Declares thsi is an SPF version 1 record (the only version currently in use)include:spf.protection.outlook.comAuthorises all IPs that Microsoft publish for Office365/Exchange Onlineip4:57.128.187.107 ip4:57.128.189.44Explicitly authorises these two IP addresses to send mail for the domainallHard fail for mail that comes from any other source.
SPF records should include no more than 10 IP addresses as SPF lookups are limited. Exchange includes a range which should not include so many that the lookups impact other entries. SPF does not survive forwarding because the origin server is replaced with the forwarding server.
All domains under our control have SPF records set up, specifying the two dedicated servers and Outlook Online.
DKIM - Domain Keys Identified Mail
This is a digital signature that is added to outbound mail by the app that sends the mail - Exchange or MailEnable. It must be configured and a DNS record added that contains the public key of the signature. At the moment, it is not configured for our Office 365 service. CHS Networks charge for enabling this across all domains. Inbound mail systems use the public key to validate the signature to verify that the message has not been tampered with in transit and that it orginated from the domain stated.
DKIM survives forwarding.
DMARC - Domain-based Message Authentication Reporting and Conformance
This a DNS TXT record that specifies a policy for managing mail that fails SPF or DKIM checks. Typically, an email must pass SPF or DKIM checks to be considered valid. If they fail both, the DMARC record includes a p attribute specifying none, quarantine or reject. It should also specify at least one reporting email address (rua) for aggregate reports to be sent to. Our DMARC records specify [email protected], and make use of the DMARC reporting service offered by CloudFlare.
Return Path/From alignment
The RETURN PATH is a hidden email header that specifies where non-delivery reports (bounce messages) should be sent. This does not need to be the same address as in the From header, but the domain should align with the sending domain. When using MailKit to generate mail, the MailMessage.Sender property sets the ENVELOPE FROM value which in turns sets Return Path. Most often we set it to the same address as the From field.
PTR/Reverse DNS
The reverse DNS or PTR record specifies the host name for the sending IP address. The host name should be the same as the default mail domain name configured for the SMTP service. This is how the mail server identifies itself (SMTP banner) when it communicates with other servers (HELO/EHLO)
This is configured by whoever controls the IP address of the server. Ideally, a hosting company should provide tools for us to configure this. Fortunately, OVHCloud do. It's in Network -> IP.
The PTR record needs a corresponding A record for the domain which points back to the IP address of the server. The PTR record and the A record together form forward-confirmed reverse DNS (FCrDNS).
The format of the host name for the sending server is server_name.domain.com e.g. ns3236533.stepcomms.com for the database server. This is what is added to the PTR record for the IP address, and what is set in the Default Mail Domain Name (SMTP Banner) field of MailEnable (Servers -> localhost -> Services and Connectors -> SMTP -> Right click -> Properties -> General). This creates a virtuous circle where the PTR record, A record and SMTP banner all align.
- Receiving mail server checks that the sending IP address has a valid hostname (the PTR record) and that it matches that presented in the HELO/EHLO command (or at least is in the same domain)
- Often, they check that the host name resolves forward to the IP address of the sending server (the A record)
So:
- PTR (set in OVHCloud): IP address
57.128.187.107resolves to host namens3236533.stepcomms.com - A record (set in CloudFlare): host name
ns3236533.stepcomms.comresolves to IP address57.128.187.107 - HELO/EHLO (issued by MailEnable):
EHLO ns3236533.stepcomms.com
Bounce Management
Bounce management relies on timely removal of recipients from the mailing lists if a non-delivery report specifies a permanent error. The bounce.stepcomms.com app using MS Graph to connect to the central bounce mailbox, and then processes mail based on its text content. This will be updated to process based on the content of DSN fields which provide structured details of the reason for delivery failure.
Removing hard bounces from mailing lists is important as it helps to maintain sender reputation scores.
Configure DKIM in MailEnable
These are the steps required to configure DKIM for a domain within MailEnable. This will ensure that all outgoing mail is cryptographically signed.
- Go to Messaging Manager -> Post Offices -> StepComms -> add a new domain
- Enter the name of the domain
- Click No on the Add Emails option that appears
- In the Properties dialog that appears, leave the General tab as is, and got to the DKIM (DomainKeys) tab
- Click Configure
- Tick "Sign Outgoing messages" (right at the top)
- Under the Selectors field, click New
- Enter a name for the selector. I use the abbreviation of the domain plus the final part of the server IP address and then the year to uniquely identify this selector, and to manage key rotation, e.g. abc-123-2025.
- Change the key size to 2048 and click OK
- In Cloudflare, add a new DNS TXT record, copying the name of the selector + "._domainkey" e.g. "abc-123-2025._domainkey" as the name of the DNS record, and the text that begins "v=DKIM1;" as the content. This should ideally be placed within double quotes in the DNS record. Note, you can copy the whole field from Mailenable which includes the domain. Cloudflare will strip the domain part off, leaving
{selectorname}._domainkeyas the name of the record. - Restart the SMTP service within Mailenable so that Outgoing mail will be signed using the new key.
- Send a test email from the domain you just configured and check to see that it was delivered and that SPF and DKIM both passed by popping the message out so that you can access File -> Properties and examine the Internet Headers:
Authentication-Results: spf=pass (sender IP is 57.128.187.107)
smtp.mailfrom=clinicalservicesjournal.com; dkim=pass (signature was verified)
header.d=clinicalservicesjournal.com;dmarc=pass action=none
header.from=clinicalservicesjournal.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of
clinicalservicesjournal.com designates 57.128.187.107 as permitted sender)
receiver=protection.outlook.com; client-ip=57.128.187.107;
helo=ns3236533.stepcomms.com; pr=C
Received: from ns3236533.stepcomms.com (57.128.187.107) by
CW2PEPF000056BD.mail.protection.outlook.com (10.167.240.20) with Microsoft
SMTP Server id 15.20.9388.8 via Frontend Transport; Wed, 3 Dec 2025 10:39:44
+0000
DKIM-Signature: v=1; c=relaxed/relaxed; h=from:date:subject:message-id:to:sender:mime-version:content-type:content-transfer-encoding;
d=clinicalservicesjournal.com; s=csj107; a=rsa-sha256;
bh=2+HNjF6ItLDWzVMpps41EBkA8m4rgD4akjQ6+WXXTbI=;
b=gieG03qtetuyfXYk8OvPU0q7ss/iavP8S1Rnukba2R3XrxISutKlA7566CccPN35S
xHwhe5y8OpO3Bf+4KLrtQP6Adkfwdnq9/sKapkAAtSyq8njZve0WMcQ6uDfPvRLqvPC
b7QgMPetLUVovMizHXSWg+2qbF47dITJ0Q0hj1W7NI+3mxfS1uUi5iiuWfUBS1qAqIM
6xh5+ecgbqO/2LTXjMw1+MjAB9QpQv36kSX58RmVAyEZLiZwAVhY3lEqAnZryC1QtV/
prgstFeGCto9MV6RVPmITcMo58jfyJcMZC/wQTBrE+W+/LZ52njBdd4zZlf72QGIYE+
67EnwtB+Q==;
Received: from ns3241178 ([192.168.0.2]) by stepcomms.com with
MailEnable ESMTPA; Wed, 3 Dec 2025 10:39:43 +0000
You can also test configuration by sending a mail to a Gmail account. Gmail provides the option to "View original", which shows whether SPF, DKIM and DMARC passed or failed.
Key Rotation
It is good practice to rotate the keys, i.e. replace them periodically with new ones. This is typically done annually, which is why the year is included in the selector name. At rotation time, create a new key with the year incremented by one and set it as active. Add a corresponding DNS entry. After a suitable time to alow any in transit emails signed with the old key to be processed - usually a couple of weeks - retire (delete) the original DNS entry.