Handling Email Authentication for Domains with Legacy Mail Servers and Non-Standard Ports

6 September 2026 · DMARC Engine · 42 min read

The Challenge of Legacy Mail Servers and Non-Standard Ports

When dealing with email authentication for domains, one of the most significant hurdles is handling legacy mail servers and non-standard ports. This issue is particularly prevalent in organisations with older infrastructure or those that have grown through mergers and acquisitions, resulting in a diverse range of mail servers and configurations. For instance, a company might have a primary mail server running on the standard port 25, but also have a legacy server running on a non-standard port, such as port 587 or 465, for specific applications or departments.

In a hosted or managed setup, such as the one we operate at DMARC Engine, we often encounter customers who are unaware of the complexity of their email infrastructure. They might have outsourced their email services to different providers over the years, each using different mail servers and configurations. This can lead to a situation where the customer is not even aware of all the mail servers sending emails on their behalf. To mitigate this, we use aggregate reporting to identify all the sources of email traffic for a domain, including those from legacy mail servers and non-standard ports.

A common issue we encounter is the use of non-standard ports for email submission. For example, some legacy mail servers might use port 465 with SSL/TLS for email submission, while others might use port 587 with STARTTLS. This can cause problems when configuring SPF records, as the standard port 25 is assumed. To address this, we recommend using a broad SPF record that includes all possible IP addresses and ports used by the organisation's mail servers. However, this approach requires careful management to avoid spam filters flagging emails as suspicious due to the broad nature of the SPF record.

v=spf1 ip4:192.0.2.1 ip4:198.51.100.1 include:_spf.example.com -all

In the above example, the SPF record includes two IP addresses and an include statement for a third-party email service. This record would need to be carefully managed to ensure it includes all the IP addresses and ports used by the organisation's mail servers.

Another challenge is handling DKIM signing for legacy mail servers. DKIM signing involves adding a digital signature to the email header, which can be verified by the recipient's mail server to ensure the email has not been tampered with. However, legacy mail servers might not support DKIM signing, or might use outdated protocols that are not compatible with modern DKIM standards. To address this, we recommend using a third-party DKIM signing service that can handle the signing process on behalf of the legacy mail server. This approach requires careful configuration to ensure the DKIM signature is correctly applied to all outgoing emails.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector;
 t=1643723900; bh=...; h=from:to:subject:date;
 b=...

In the above example, the DKIM signature includes the version, algorithm, domain, selector, and other parameters. This signature would need to be correctly applied to all outgoing emails to ensure they can be verified by the recipient's mail server.

When it comes to DMARC, the challenge is aggregating reporting data from all the different mail servers and sources. DMARC relies on aggregate reporting to provide insights into email authentication issues, but this can be difficult when dealing with legacy mail servers and non-standard ports. To address this, we recommend using a managed DMARC service that can handle the aggregation of reporting data from all sources. This approach provides a centralised view of email authentication issues, making it easier to identify and resolve problems.

In our experience, the key to handling email authentication for domains with legacy mail servers and non-standard ports is careful planning and management. This involves identifying all the mail servers and sources of email traffic, configuring SPF and DKIM records correctly, and using aggregate reporting to monitor email authentication issues. By taking a proactive approach to email authentication, organisations can improve the deliverability of their emails and reduce the risk of spam filters flagging their emails as suspicious.

Assessing the Current Email Infrastructure

When dealing with domains that have legacy mail servers and non-standard ports, it is crucial to assess the current email infrastructure to determine the best approach for implementing email authentication protocols such as SPF, DKIM, and DMARC. This assessment will help identify potential issues and inform the decision-making process for configuring these protocols.
A key aspect of this assessment is to identify all the mail servers that are sending emails on behalf of the domain. This includes not only the primary mail server but also any secondary or backup mail servers, as well as any other servers that may be sending automated emails, such as marketing or notification servers.
For example, let's consider a domain that has a primary mail server hosted on a cloud-based email service, but also has a legacy mail server hosted on-premise that is used for sending automated notifications. The primary mail server may be using a standard port 25 for SMTP, while the legacy mail server may be using a non-standard port 587.
To assess the current infrastructure, we can start by checking the DNS records for the domain. We can use tools such as dig or online DNS lookup services to retrieve the MX records, which will show us the mail servers that are configured to receive emails for the domain.

dig +short mx example.com
10 mail.example.com
20 legacy-mail.example.com

In this example, we can see that there are two mail servers configured: mail.example.com and legacy-mail.example.com. We can then use this information to investigate the SMTP ports that are being used by each server.
We can use tools such as telnet or nc to test the SMTP ports for each server. For example:

telnet mail.example.com 25
Trying 192.0.2.1...
Connected to mail.example.com.
Escape character is '^]'.
220 mail.example.com ESMTP

This shows us that the primary mail server is using the standard port 25 for SMTP. We can then repeat this process for the legacy mail server:

telnet legacy-mail.example.com 587
Trying 198.51.100.1...
Connected to legacy-mail.example.com.
Escape character is '^]'.
220 legacy-mail.example.com ESMTP

This shows us that the legacy mail server is using the non-standard port 587 for SMTP.
In a hosted or managed setup, such as the one provided by DMARC Engine, this assessment process can be automated and streamlined. The hosted service can provide tools and APIs to help identify the mail servers and SMTP ports that are being used, and can also provide recommendations for configuring email authentication protocols.
For instance, DMARC Engine's automated setup process can analyse the DNS records and mail server configurations to identify potential issues and provide a customised setup plan for implementing SPF, DKIM, and DMARC.
Once we have assessed the current email infrastructure, we can begin to plan the implementation of email authentication protocols. This will involve choosing the right protocol for each mail server, configuring the protocols to work with non-standard ports, and troubleshooting any issues that arise.
It is also essential to consider the impact of email authentication on email deliverability. Implementing these protocols can help improve deliverability by reducing the risk of spam and phishing attacks, but it can also introduce new challenges, such as increased complexity and potential issues with mail server configuration.
To optimise email deliverability, it is crucial to monitor the performance of the email authentication protocols and make adjustments as needed. This can involve analysing aggregate reporting data, such as that provided by DMARC Engine, to identify trends and patterns in email authentication and deliverability.
By carefully assessing the current email infrastructure and planning the implementation of email authentication protocols, organisations can help ensure the authenticity and deliverability of their emails, while also reducing the risk of spam and phishing attacks.
In the next section, we will discuss the process of choosing the right email authentication protocol for domains with legacy mail servers and non-standard ports. This will involve considering the trade-offs and benefits of each protocol, as well as the potential challenges and limitations of implementing these protocols in a legacy environment.
For example, when choosing between SPF and DKIM, we need to consider the level of control and flexibility that each protocol provides. SPF provides a high level of control over which mail servers are authorised to send emails on behalf of the domain, but it can be more complex to configure and manage. DKIM, on the other hand, provides a high level of flexibility and can be easier to configure, but it may not provide the same level of control as SPF.
Ultimately, the choice of email authentication protocol will depend on the specific needs and requirements of the organisation, as well as the capabilities and limitations of the legacy mail servers and non-standard ports.
By carefully evaluating these factors and choosing the right protocol for each mail server, organisations can help ensure the authenticity and deliverability of their emails, while also reducing the risk of spam and phishing attacks.
It is also worth noting that, in some cases, it may be necessary to use a combination of email authentication protocols to achieve the desired level of control and flexibility. For instance, an organisation may choose to use SPF to authenticate emails sent from the primary mail server, while using DKIM to authenticate emails sent from the legacy mail server.
By taking a thoughtful and nuanced approach to email authentication, organisations can help ensure the security and deliverability of their emails, while also minimising the risk of spam and phishing attacks.
In addition to choosing the right email authentication protocol, it is also essential to consider the impact of non-standard ports on email deliverability. Non-standard ports can introduce additional complexity and potential issues with mail server configuration, which can affect the deliverability of emails.
To mitigate these risks, it is crucial to carefully configure the email authentication protocols to work with non-standard ports. This may involve specifying the non-standard port in the protocol configuration, or using a workaround such as a proxy server to route emails through the standard port.
By carefully assessing the current email infrastructure and planning the implementation of email authentication protocols, organisations can help ensure the authenticity and deliverability of their emails, while also reducing the risk of spam and phishing attacks.
In the next section, we will discuss the process of configuring SPF for non-standard ports, including the potential challenges and limitations of implementing SPF in a legacy environment.
We will also provide concrete examples and real record snippets to illustrate the configuration process and help organisations implement SPF successfully.
For instance, we will show how to configure SPF to authenticate emails sent from a mail server using a non-standard port, and how to troubleshoot common issues that may arise during the configuration process.
By providing detailed guidance and examples, we aim to help organisations overcome the challenges of implementing email authentication protocols in a legacy environment and achieve the benefits of improved email deliverability and security.
In the following sections, we will also discuss the implementation of DKIM with legacy mail servers, DMARC and aggregate reporting for legacy

Choosing the Right Email Authentication Protocol

When it comes to handling email authentication for domains with legacy mail servers and non-standard ports, choosing the right protocol is crucial. The decision between SPF, DKIM, and DMARC is not a straightforward one, as each protocol has its own strengths and weaknesses. In our experience at DMARC Engine, we have seen that many organisations struggle to optimise their email authentication setup, often due to a lack of understanding of the trade-offs involved.

One of the key considerations is the type of mail server setup. For example, if you have a domain with a mix of cloud-based and on-premise mail servers, you may need to use a combination of SPF and DKIM. SPF is useful for specifying which IP addresses are allowed to send email on behalf of your domain, but it can be cumbersome to manage if you have a large number of mail servers. In this case, using a hosted SPF service can help to simplify the process.

example.com. IN TXT "v=spf1 include:_spf.example.com ip4:192.0.2.1 ip4:198.51.100.1 -all"

This SPF record, for instance, includes two IP addresses and a reference to another SPF record, which can be useful for managing complex mail server setups.

On the other hand, DKIM is useful for verifying the authenticity of email messages, but it requires a more complex setup. DKIM uses a public-private key pair to sign email messages, which can be time-consuming to set up and manage. However, using a managed DKIM service can help to simplify the process.

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt3WRxWJp1xWk5okY6tuyF69pKm+NT1hMrYm2B0Ph5/WjE2Jx3dD/QaK3 +jCRy3ec2kGn+YF9U+4iG9VwPbVZpHap6zR4gRtLfb4NY0q9VQo7GQH1j3oEzInQVQ6PjG+oJ8Q7jBk0nKQdkaNtJQx3S8Qs8xRnL9wIDAQAB"

This DKIM record, for example, specifies the public key used to verify the signature of email messages sent from the example.com domain.

DMARC, on the other hand, is a protocol that builds on top of SPF and DKIM to provide a more comprehensive email authentication solution. DMARC allows you to specify a policy for handling email messages that fail authentication, which can help to prevent spam and phishing attacks. However, implementing DMARC can be complex, especially if you have a large number of mail servers. In this case, using a hosted DMARC service can help to simplify the process.

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1"

This DMARC record, for instance, specifies a policy of rejecting email messages that fail authentication, and sends aggregate reports to the specified email address.

In our experience, the key to successful email authentication is to use a combination of protocols. For example, using SPF to specify which IP addresses are allowed to send email on behalf of your domain, DKIM to verify the authenticity of email messages, and DMARC to provide a comprehensive email authentication solution. By using a combination of protocols, you can help to prevent spam and phishing attacks, and improve the deliverability of your email messages.

It is also important to consider the impact of non-standard ports on email authentication. For example, if you have a mail server that uses a non-standard port, such as port 587, you may need to use a different SPF record to specify which IP addresses are allowed to send email on behalf of your domain.

example.com. IN TXT "v=spf1 include:_spf.example.com ip4:192.0.2.1:587 ip4:198.51.100.1:587 -all"

This SPF record, for instance, specifies two IP addresses and the non-standard port 587, which can be useful for managing complex mail server setups.

In addition, it is important to consider the impact of legacy mail servers on email authentication. For example, if you have a legacy mail server that does not support DKIM, you may need to use a different email authentication protocol, such as SPF. In this case, using a hosted email authentication service can help to simplify the process.

In short, choosing the right email authentication protocol is crucial for handling email authentication for domains with legacy mail servers and non-standard ports. By using a combination of protocols, such as SPF, DKIM, and DMARC, you can help to prevent spam and phishing attacks, and improve the deliverability of your email messages. It is also important to consider the impact of non-standard ports and legacy mail servers on email authentication, and to use a hosted email authentication service to simplify the process. By taking a comprehensive approach to email authentication, you can help to protect your domain and improve the deliverability of your email messages.

Configuring SPF for Non-Standard Ports

Configuring SPF for domains that utilise non-standard ports can be a complex task, particularly when dealing with legacy mail servers. The primary concern is ensuring that the SPF record correctly identifies all mail servers that send email on behalf of the domain, including those using non-standard ports. A typical SPF record snippet may look like this:

v=spf1 a mx ip4:192.0.2.1 ip4:198.51.100.1 include:_spf.example.net -all

However, when non-standard ports are involved, the situation becomes more intricate. For instance, if a domain has a mail server listening on port 587 instead of the standard port 25, the SPF record must be configured to account for this.

One approach to handle non-standard ports is to use the ip4 or ip6 mechanism in the SPF record, followed by the IP address of the mail server and the port number. For example:

v=spf1 a mx ip4:192.0.2.1:587 ip4:198.51.100.1:465 include:_spf.example.net -all

This method, however, is not without its limitations. The SPF protocol does not officially support specifying ports in the record, and some mail servers may not honour this syntax. As a result, it is crucial to test the SPF record thoroughly to ensure it functions as expected across different mail servers.

In a hosted or managed setup, such as the one provided by DMARC Engine, the process of configuring SPF for non-standard ports can be simplified. The platform allows users to input the IP addresses and ports of their mail servers, and then automatically generates the SPF record. This can help reduce the risk of errors and ensure that the record is correctly formatted. For example, the DMARC Engine interface may include a field to input the IP address and port of the mail server, like this:

Mail Server IP: 192.0.2.1
Port: 587

The platform will then generate the SPF record accordingly, taking into account the non-standard port.

Another consideration when configuring SPF for non-standard ports is the use of third-party mail services. If a domain uses a third-party mail service, such as a mailing list provider or a marketing automation platform, the SPF record must include the IP addresses of these services. This can be achieved using the include mechanism in the SPF record. For instance:

v=spf1 a mx ip4:192.0.2.1:587 include:_spf.example.net include:mailinglist.example.com -all

In this example, the SPF record includes the IP address of the domain's mail server, as well as the IP addresses of the third-party mail services.

It is also important to note that some mail servers may use non-standard ports for specific types of email, such as bulk mail or transactional email. In these cases, the SPF record must be configured to account for these different types of email. For example, a domain may use port 465 for bulk mail and port 587 for transactional email. The SPF record would need to include both of these ports to ensure that all email sent by the domain is authenticated correctly.

In terms of best practices, it is recommended to use a conservative approach when configuring SPF for non-standard ports. This means including all possible IP addresses and ports that may be used by the domain's mail servers, as well as any third-party mail services. It is also essential to regularly review and update the SPF record to ensure it remains accurate and effective.

To illustrate this, consider a real-world example. Suppose a domain, example.com, has a mail server listening on port 587 and uses a third-party mailing list provider, mailinglist.example.com. The domain's SPF record might look like this:

v=spf1 a mx ip4:192.0.2.1:587 include:mailinglist.example.com -all

However, if the domain also uses a marketing automation platform, market automation.example.com, that sends email on behalf of the domain, the SPF record would need to be updated to include the IP address of this platform. The updated record might look like this:

v=spf1 a mx ip4:192.0.2.1:587 include:mailinglist.example.com include:marketautomation.example.com -all

By including all possible IP addresses and ports, as well as any third-party mail services, the domain can ensure that its SPF record is comprehensive and effective.

In conclusion to this section, configuring SPF for non-standard ports requires careful consideration of the domain's email infrastructure and the use of third-party mail services. By using a conservative approach and including all possible IP addresses and ports, domains can ensure that their SPF records are accurate and effective. Hosted or managed setups, such as DMARC Engine, can simplify the process and reduce the risk of errors. Regular review and updates of the SPF record are also essential to ensure it remains effective in preventing spam and phishing attacks.

Implementing DKIM with Legacy Mail Servers

Implementing DomainKeys Identified Mail (DKIM) with legacy mail servers can be a complex task, especially when these servers do not support standard DKIM signing or verification processes. One of the primary challenges is that legacy mail servers may not have the capability to handle the cryptographic functions required for DKIM, or they may not be able to integrate with external signing services. In our experience at DMARC Engine, where we manage and host DMARC, SPF, DKIM, MTA-STS, and BIMI for our customers, we have encountered numerous instances where legacy mail servers required custom solutions to implement DKIM effectively.

When dealing with legacy mail servers, the first step is to assess the server's capabilities and determine the best approach for implementing DKIM. This may involve working with the server administrators to configure the server to use an external signing service or to integrate a third-party DKIM signing tool. For example, we worked with a customer who was using a legacy Lotus Notes server, which did not have built-in support for DKIM. We were able to configure the server to use an external signing service, which allowed us to generate a DKIM signature for outgoing emails. The configuration involved setting up a DNS record, such as the following:

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB"

This record specifies the public key used for DKIM verification and is a critical component of the DKIM signing process.

Another challenge when implementing DKIM with legacy mail servers is ensuring that the server can handle the DKIM signature correctly. This may involve configuring the server to include the DKIM signature in the email header or to verify the DKIM signature on incoming emails. In some cases, it may be necessary to use a third-party tool or service to handle the DKIM signing and verification processes. For instance, we use a hosted DKIM signing service that can integrate with a variety of mail servers, including legacy systems. This service allows us to generate DKIM signatures for outgoing emails and verify the signatures on incoming emails, regardless of the mail server's capabilities.

When selecting a DKIM signing tool or service, it is essential to consider the trade-offs between different solutions. For example, some tools may offer more advanced features, such as the ability to sign emails with multiple domains or to handle large volumes of email traffic. However, these tools may also be more complex to configure and manage. In contrast, simpler tools may be easier to use but may not offer the same level of functionality. At DMARC Engine, we have found that a balanced approach is often the most effective, where we use a combination of tools and services to meet the specific needs of our customers.

In addition to the technical challenges, there are also organisational considerations when implementing DKIM with legacy mail servers. For example, it may be necessary to coordinate with multiple teams or departments to configure the mail server and implement the DKIM signing process. This can be a time-consuming and complex process, especially in large organisations with multiple stakeholders. To mitigate these challenges, we recommend establishing clear communication channels and project plans, as well as providing training and support to ensure that all teams are aware of the changes and can effectively manage the new DKIM signing process.

To optimise the DKIM signing process, it is also crucial to monitor the email traffic and adjust the configuration as needed. This may involve analysing the email logs to identify any issues with the DKIM signature or adjusting the signing parameters to improve the deliverability of emails. At DMARC Engine, we use a combination of tools and services to monitor the email traffic and provide real-time feedback to our customers. This allows us to quickly identify and resolve any issues with the DKIM signing process, ensuring that our customers' emails are delivered effectively and efficiently.

In terms of best practices, we recommend the following when implementing DKIM with legacy mail servers:

• Use a hosted or managed DKIM signing service to simplify the configuration and management process.
• Ensure that the mail server can handle the DKIM signature correctly and that the signature is included in the email header.
• Monitor the email traffic and adjust the configuration as needed to optimise the DKIM signing process.
• Establish clear communication channels and project plans to coordinate with multiple teams or departments.
• Provide training and support to ensure that all teams are aware of the changes and can effectively manage the new DKIM signing process.

By following these best practices and considering the trade-offs between different solutions, organisations can effectively implement DKIM with legacy mail servers and improve the deliverability of their emails. At DMARC Engine, we have seen firsthand the benefits of implementing DKIM with legacy mail servers, and we are committed to helping our customers navigate the complex process of email authentication and deliverability.

For example, one of our customers, a large financial institution, was experiencing issues with email deliverability due to the lack of DKIM signing on their legacy mail server. We worked with them to configure the server to use an external signing service, which improved the deliverability of their emails and reduced the risk of spam filtering. The configuration involved setting up a DNS record, such as the following:

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB"

This record specifies the public key used for DKIM verification and is a critical component of the DKIM signing process. By implementing DKIM with their legacy mail server, our customer was able to improve the deliverability of their emails and reduce the risk of spam filtering.

In short, implementing DKIM with legacy mail servers requires careful consideration of the technical and organisational challenges involved. By using a hosted or managed DKIM signing service, ensuring that the mail server can handle the DKIM signature correctly, monitoring the email traffic, and establishing clear communication channels, organisations can effectively implement DKIM with legacy mail servers and improve the deliverability of their emails. At DMARC Engine, we are committed to helping our customers navigate the complex process of email authentication and deliverability, and we have seen firsthand the benefits of implementing DKIM with legacy mail servers.

To illustrate this point, let us consider a real-world example. Suppose we have a customer who is using a legacy mail server that does not support DKIM signing. We can configure the server to use an external signing service, which will generate a DKIM signature for

DMARC and Aggregate Reporting for Legacy Domains

Handling DMARC and aggregate reporting for domains with legacy mail servers and non-standard ports can be a complex task, requiring careful consideration of the trade-offs between security, deliverability, and compatibility. In our experience, one of the biggest challenges is configuring DMARC to work effectively with legacy mail servers that may not support standard ports or authentication protocols.

For example, a customer may have a legacy mail server that only supports SMTP over port 2525, rather than the standard port 25. In this case, we need to configure the DMARC record to take into account the non-standard port, while also ensuring that the record is compatible with the majority of mail servers that use standard ports.

One approach to this problem is to use a DMARC record with a relaxed policy, such as p=none, which allows us to monitor authentication results without affecting deliverability. This can be particularly useful for domains with legacy mail servers, as it allows us to gather data on authentication results without risking email delivery issues.

Here is an example of a DMARC record with a relaxed policy:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"

In this example, the p=none policy specifies that we are not enforcing DMARC authentication, while the rua and ruf tags specify the email addresses to which aggregate and failure reports should be sent.

When configuring DMARC for legacy domains, it is also important to consider the impact of non-standard ports on SPF authentication. For example, if a legacy mail server is using a non-standard port, it may not be included in the SPF record, which can lead to authentication failures.

To mitigate this issue, we can use a hosted DMARC solution that provides automated SPF configuration and management. For example, our hosted DMARC solution at DMARC Engine can automatically detect and configure SPF records for non-standard ports, reducing the risk of authentication failures.

In addition to configuring DMARC records, it is also important to monitor aggregate reporting data to identify potential issues with email authentication. Aggregate reports provide valuable insights into authentication results, including data on passing and failing messages, as well as information on the sources of authentication failures.

Here is an example of an aggregate report:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
 <version>1</version>
 <report_metadata>
 <org_name>example.com</org_name>
 <email>example@example.com</email>
 <extra_contact_info>https://example.com</extra_contact_info>
 <report_id>1234567890</report_id>
 <date_range>
 <begin>2022-01-01T00:00:00Z</begin>
 <end>2022-01-07T23:59:59Z</end>
 </date_range>
 </report_metadata>
 <policy_published>
 <domain>example.com</domain>
 <adkim>r</adkim>
 <aspf>r</aspf>
 <p>none</p>
 <sp>none</sp>
 <pct>100</pct>
 </policy_published>
 <record>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>10</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>pass</dkim>
 <spf>pass</spf>
 </policy_evaluated>
 </row>
 <row>
 <source_ip>192.0.2.2</source_ip>
 <count>5</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>fail</dkim>
 <spf>fail</spf>
 </policy_evaluated>
 </row>
 </record>
</feedback>

In this example, the aggregate report provides data on the number of passing and failing messages, as well as information on the sources of authentication failures. By monitoring this data, we can identify potential issues with email authentication and take corrective action to improve deliverability.

In our experience, one of the most common issues with DMARC and aggregate reporting for legacy domains is the failure to properly configure the DMARC record to account for non-standard ports. This can lead to authentication failures and deliverability issues, particularly if the domain has a strict DMARC policy.

To mitigate this issue, we recommend using a hosted DMARC solution that provides automated configuration and management of DMARC records, as well as monitoring and analysis of aggregate reporting data. By using a hosted solution, domains with legacy mail servers can ensure that their DMARC records are properly configured and that they are receiving accurate and actionable data on email authentication results.

In terms of best practices, we recommend the following:

• Use a relaxed DMARC policy, such as p=none, to monitor authentication results without affecting deliverability.
• Use a hosted DMARC solution to automate configuration and management of DMARC records.
• Monitor aggregate reporting data regularly to identify potential issues with email authentication.
• Use automated tools to analyse aggregate reporting data and identify trends and patterns.
• Consider using a third-party service to handle DMARC and aggregate reporting, particularly if the domain has a large volume of email traffic.

By following these best practices and using a hosted DMARC solution, domains with legacy mail servers can ensure that their email authentication is properly configured and that they are receiving accurate and actionable data on email authentication results. This can help to improve deliverability, reduce the risk of email delivery issues, and provide a better overall email experience for users.

It is also worth noting that, when implementing DMARC for legacy domains, it is essential to consider the colour of the organisation's branding, as this can impact the overall user experience. For example, if an organisation's branding features a specific colour scheme, it may be necessary to adjust the DMARC record to ensure that the organisation's emails are properly authenticated and displayed in the correct colour scheme.

In addition, when optimising email deliverability with DMARC, it is crucial to centre the organisation's email strategy around the user experience. This can involve using data and analytics to understand user behaviour and preferences, as well as testing and optimising email campaigns to ensure that they are properly authenticated and delivered to the user's inbox.

By taking a user-centric approach to email deliverability and using a hosted DMARC solution, organisations with legacy mail servers can improve the overall email experience for their users, reduce the risk of email delivery issues, and increase the effectiveness of their email marketing campaigns.

In our experience, the key to successful DMARC implementation for legacy domains is to take a careful and considered approach, taking into account the specific needs and requirements of the organisation. This can involve working with a hosted DMARC solution provider to configure and manage DMARC records, as well as monitoring and analysing aggregate reporting data to identify potential issues with email authentication.

By working with a hosted solution provider and following best practices, organisations with legacy mail servers can ensure that their DMARC records are properly configured, their email authentication is accurate and effective, and their users receive a better overall email experience.

To organise the implementation of DMARC for legacy domains, we recommend the following steps:

• Conduct a thorough review of the organisation's email infrastructure and authentication protocols.
• Configure the DMARC record to account for non-standard ports and legacy mail servers.
• Monitor aggregate reporting data regularly to identify potential issues with email authentication.
• Use automated tools to analyse aggregate reporting data and identify trends and patterns.
• Consider using a third-party service to handle DMARC and aggregate reporting, particularly if the domain has a large volume of email traffic.

By following these steps and using a hosted DMARC solution, organisations with legacy mail servers can ensure that their email authentication is properly configured, their email deliverability is optimised, and their users receive a better overall email experience.

Troubleshooting Common Issues with Email Authentication

Troubleshooting email authentication issues can be a complex and time-consuming process, particularly when dealing with legacy mail servers and non-standard ports. At DMARC Engine, we have encountered a wide range of issues, from misconfigured SPF records to DKIM key management problems. In this section, we will discuss some of the most common issues we have encountered and provide practical advice on how to troubleshoot and resolve them.

One of the most common issues we see is SPF record misconfiguration. For example, a customer may have a legacy mail server that uses a non-standard port, such as port 587, but their SPF record only includes the standard port 25. This can cause email authentication failures and lead to deliverability issues. To troubleshoot this issue, we recommend using a tool like dig to check the SPF record for the domain:

dig +short txt example.com

This will return the SPF record for the domain, which can be checked for correctness. In this case, the SPF record might look like this:

"v=spf1 ip4:192.0.2.1 include:_spf.example.com -all"

To fix the issue, the customer would need to update their SPF record to include the non-standard port, like this:

"v=spf1 ip4:192.0.2.1:587 include:_spf.example.com -all"

However, Notably, using non-standard ports in SPF records can be problematic, as not all mail servers support them. A better approach might be to use a separate SPF record for the legacy mail server, like this:

"v=spf1 ip4:192.0.2.1 include:_spf.example.com -all"

And then use a ptr record to point to the separate SPF record for the non-standard port:

legacy-mail-server.example.com. IN PTR example.com._spf.legacy

Another common issue we see is DKIM key management problems. For example, a customer may have a legacy mail server that uses a DKIM key that is not properly configured or is no longer valid. To troubleshoot this issue, we recommend using a tool like openssl to check the DKIM key:

openssl rsa -in example.com.private -text

This will return the DKIM key in text format, which can be checked for correctness. In this case, the DKIM key might look like this:

Private-Key: (2048 bit)
modulus:
 00:aa:bb:cc:dd:ee:ff:gg:hh:ii:jj:kk:ll:mm:nn:oo:
 pp:qq:rr:ss:tt:uu:vv:ww:xx:yy:zz:11:22:33:44:55:
 66:77:88:99:00:11:22:33:44:55:66:77:88:99
publicExponent: 65537 (0x10001)
privateExponent:
 12:34:56:78:90:ab:cd:ef:01:23:45:67:89:0a:bc:de:
 ff:00:11:22:33:44:55:66:77:88:99:00:11:22:33:44:
 55:66:77:88:99

To fix the issue, the customer would need to update their DKIM key to a valid and properly configured key. In a hosted or managed setup, this process is typically automated, with the provider generating and rotating DKIM keys on behalf of the customer.

DMARC aggregate reporting can also be a useful tool for troubleshooting email authentication issues. At DMARC Engine, we provide our customers with detailed aggregate reports that show email authentication failures and successes. For example, a customer may receive a report that looks like this:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
 <report_metadata>
 <org_name>example.com</org_name>
 <email>postmaster@example.com</email>
 <extra_contact_info>https://example.com</extra_contact_info>
 <report_id>1234567890</report_id>
 <date_range>
 <begin>2022-01-01T00:00:00Z</begin>
 <end>2022-01-31T23:59:59Z</end>
 </date_range>
 </report_metadata>
 <policy_published>
 <domain>example.com</domain>
 <adkim>r</adkim>
 <aspf>r</aspf>
 <p>reject</p>
 <sp>reject</sp>
 <pct>100</pct>
 </policy_published>
 <record>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>100</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>pass</dkim>
 <spf>fail</spf>
 </policy_evaluated>
 </row>
 </record>
</feedback>

This report shows that the customer's email authentication policy is set to reject emails that fail DMARC authentication, and that there were 100 emails from the IP address 192.0.2.1 that failed SPF authentication but passed DKIM authentication. To fix the issue, the customer would need to update their SPF record to include the IP address 192.0.2.1, or update their email authentication policy to use a more permissive disposition.

In addition to these common issues, there are several other potential pitfalls to watch out for when troubleshooting email authentication issues. For example, it is essential to ensure that the email authentication protocols are correctly configured and aligned with the customer's email infrastructure. This includes ensuring that the SPF record is correctly formatted and includes all the necessary IP addresses, that the DKIM key is properly configured and valid, and that the DMARC policy is set to the correct disposition.

It is also crucial to monitor email authentication failures and successes regularly, using tools like DMARC aggregate reporting, to identify potential issues before they become major problems. In a hosted or managed setup, this process is typically automated, with the provider monitoring email authentication failures and successes on behalf of the customer and providing regular reports and alerts.

In terms of best practices, we recommend that customers use a separate SPF record for each legacy mail server, and that they use a ptr record to point to the separate SPF record for non-standard ports. We also recommend that customers use a valid and properly configured DKIM key, and that they update their DMARC policy to use a more permissive disposition if necessary.

By following these best practices and being aware of the potential pitfalls, customers can optimise their email deliverability and ensure that their emails are properly authenticated and delivered to the recipient's inbox. At DMARC Engine, we have seen firsthand the importance of proper email authentication configuration, and we recommend that all customers take the time to properly configure and test their email authentication protocols to ensure optimal deliverability.

Optimising Email Deliverability with Authentication

To optimise email deliverability with authentication, it is crucial to centre your strategy around the unique requirements of your domain, taking into account the colour of your email traffic, including transactional, marketing, and user-generated content. A key aspect of this process is to organise your email authentication protocols, such as SPF, DKIM, and DMARC, in a way that maximises their effectiveness.

For instance, when configuring SPF, it is essential to consider the non-standard ports used by your legacy mail servers. A typical SPF record might look like this:

v=spf1 a mx ip4:192.0.2.1 include:_spf.example.com -all

However, if your mail server uses a non-standard port, such as port 587, you will need to modify your SPF record accordingly. In a hosted or managed setup, such as the one we use at DMARC Engine, this can be handled automatically, but it is still important to understand the underlying mechanics.

One common trade-off when optimising email deliverability is the balance between security and usability. For example, implementing DMARC with a strict policy can help prevent spoofing, but it may also block legitimate email if not configured correctly. A more permissive policy, on the other hand, may allow more email to be delivered, but it may also increase the risk of spoofing.

To illustrate this point, consider the following DMARC record:

v=DMARC1; p=reject; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1

This record specifies a strict policy, where all email that fails DMARC validation will be rejected. However, this may not be suitable for all domains, particularly those with complex email infrastructures. In such cases, a more permissive policy, such as p=none, may be more appropriate, at least initially.

Another important aspect of optimising email deliverability is monitoring and analysis. By regularly reviewing aggregate reports, such as those provided by DMARC, you can gain valuable insights into your email traffic and identify potential issues before they become major problems. For example, a high rate of DMARC failures may indicate a problem with your SPF or DKIM configuration, while a large number of complaints may suggest a issue with your email content or sender reputation.

In a hosted or managed setup, such as the one we use at DMARC Engine, these reports can be automatically collected and analysed, providing a clear picture of your email deliverability and highlighting areas for improvement. However, even in a self-managed setup, it is still possible to collect and analyse these reports, using tools such as the dmarc-parser library.

When it comes to implementing DKIM, there are several factors to consider, including the size of your email traffic, the complexity of your email infrastructure, and the level of security you require. One common approach is to use a third-party service, such as Amazon SES or Sendgrid, which can handle DKIM signing on your behalf. However, this may not be suitable for all domains, particularly those with high-volume email traffic or complex security requirements.

In such cases, it may be more appropriate to implement DKIM in-house, using a library such as OpenDKIM or dkim-milter. This can provide a higher level of control and flexibility, but it also requires a greater level of technical expertise and resources. For example, the following code snippet shows how to configure OpenDKIM to sign email with a custom selector:

import opendkim

# Set the selector and domain
selector = "example"
domain = "example.com"

# Set the private key file and canonicalisation method
private_key_file = "/etc/opendkim/private.key"
canonicalisation_method = "relaxed/relaxed"

# Create a new OpenDKIM object
odkim = opendkim.OpenDKIM(selector, domain, private_key_file, canonicalisation_method)

# Sign an email message
message = "Hello World!"
signed_message = odkim.sign(message)

Ultimately, the key to optimising email deliverability with authentication is to understand the unique requirements of your domain and to be prepared to adapt and evolve your strategy as needed. By centreing your approach around the specific needs of your email traffic, and by using a combination of technical expertise and monitoring and analysis, you can maximise your email deliverability and minimise the risk of spoofing and other security threats.

In our experience at DMARC Engine, a hosted or managed setup can provide a number of benefits, including automatic configuration and monitoring, as well as access to expert technical support and resources. However, even in a self-managed setup, it is still possible to achieve high levels of email deliverability and security, with the right combination of technical expertise and attention to detail.

By taking a proactive and adaptive approach to email authentication, and by staying up-to-date with the latest developments and best practices, you can help ensure the security and deliverability of your email traffic, and provide a better experience for your users. Whether you are using a hosted or managed setup, or a self-managed approach, the key is to be flexible, responsive, and committed to ongoing improvement and optimisation.

Real-World Examples and Case Studies

Handling email authentication for domains with legacy mail servers and non-standard ports can be a complex task, requiring careful consideration of the trade-offs involved. At DMARC Engine, we have encountered numerous real-world examples that illustrate the challenges and opportunities of implementing email authentication in such scenarios.

One such example is a large financial institution that uses a legacy mail server running on a non-standard port 2525. The institution's IT department was concerned about the potential impact of implementing SPF on their existing mail flow, particularly with regards to mail sent from their CRM system, which uses a third-party service provider. To address this concern, we worked with the institution to configure their SPF record to include the IP addresses of the CRM system's service provider, as shown in the following example:

v=spf1 ip4:192.0.2.1 ip4:198.51.100.1 include:_spf.example-crm.com -all

In this example, the include directive is used to include the SPF record of the CRM system's service provider, _spf.example-crm.com, which is hosted on a separate domain. This allows the financial institution to maintain control over their own SPF record while still authorising mail sent from the CRM system.

Another example is a university that uses a legacy mail server running on port 587, which is a non-standard port for mail submission. The university's IT department wanted to implement DKIM signing for their outgoing mail, but were concerned about the potential impact on their existing mail flow. To address this concern, we worked with the university to configure their DKIM signing to use a separate selector for mail sent from the legacy mail server, as shown in the following example:

selector1._domainkey.example-university.ac.uk. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4mVfK+YRtHC1jH/7K3ZmZr2hV1y0zRpa3HwIDuvZgZx2oSlTtQ4WbDxQqV2Kj2Nlz0VZ2uCAz4R1l5Q9vG4P0R4zP6QnN0ZK+YRtHC1jH/7K3ZmZr2hV1y0zRpa3HwIDuvZgZx2oSlTtQ4WbDxQqV2Kj2Nl"

In this example, the selector1 directive is used to specify a separate selector for mail sent from the legacy mail server, which allows the university to maintain control over their DKIM signing while still allowing mail to be sent from the legacy mail server.

In a hosted or managed setup, such as the one provided by DMARC Engine, the process of handling email authentication for domains with legacy mail servers and non-standard ports is often simplified. For example, our platform provides a user-friendly interface for configuring SPF and DKIM records, which can help to reduce the complexity and administrative burden associated with implementing email authentication. Also, our platform provides real-time monitoring and reporting of email authentication issues, which can help to identify and troubleshoot problems quickly.

However, even in a hosted or managed setup, there are still trade-offs to be considered. For example, the use of non-standard ports can require additional configuration and troubleshooting, particularly if the mail server is not properly configured to handle mail sent on those ports. In such cases, it may be necessary to use a mail relay or proxy server to forward mail from the non-standard port to the standard port, as shown in the following example:

mail-relay.example.com. IN A 192.0.2.1
example.com. IN MX 10 mail-relay.example.com

In this example, the mail-relay.example.com server is used to forward mail from the non-standard port 2525 to the standard port 25, which allows the mail to be delivered to the recipient's mail server.

In terms of optimising email deliverability with authentication, there are several best practices that can be followed. One such best practice is to use a consistent naming convention for SPF and DKIM records, which can help to simplify the process of configuring and troubleshooting email authentication. For example, using a naming convention such as selector1._domainkey.example.com for DKIM records and spf.example.com for SPF records can help to reduce confusion and errors.

Another best practice is to use a separate subdomain for email authentication, which can help to isolate email authentication issues from other DNS-related issues. For example, using a subdomain such as mail.example.com for email authentication can help to simplify the process of configuring and troubleshooting email authentication.

In addition to these best practices, it is also important to consider the potential impact of email authentication on mail flow and deliverability. For example, the use of strict SPF and DKIM policies can help to prevent spam and phishing attacks, but can also block legitimate mail if not properly configured. In such cases, it may be necessary to use a more permissive policy, such as ~all instead of -all, to allow mail to be delivered while still providing some level of protection against spam and phishing attacks.

In terms of troubleshooting common issues with email authentication, there are several tools and techniques that can be used. One such tool is the dig command, which can be used to verify the existence and correctness of SPF and DKIM records. For example, the following command can be used to verify the existence of an SPF record:

dig +short txt example.com

This command will return the SPF record for the specified domain, which can be used to verify its existence and correctness.

Another tool that can be used for troubleshooting email authentication issues is the openssl command, which can be used to verify the validity of DKIM signatures. For example, the following command can be used to verify the validity of a DKIM signature:

openssl dgst -sha256 -verify example-university.ac.uk.pem -signature signature.txt message.txt

This command will verify the validity of the DKIM signature in the signature.txt file, which can be used to troubleshoot issues with DKIM signing and verification.

Overall, handling email authentication for domains with legacy mail servers and non-standard ports requires careful consideration of the trade-offs involved, as well as a thorough understanding of the underlying technology and best practices. By following the best practices and using the tools and techniques outlined in this section, it is possible to implement email authentication in a way that is both effective and efficient, while also minimising the potential impact on mail flow and deliverability.

Related reading

• Mitigating Email Deliverability Issues Due to DNS Zone Transfer Delays
• DMARC and Subdomain Delegation for Franchise Networks with Centralised Email Infrastructure
• Optimising BIMI for Domains with Multiple Brand Identities