Why does MTA-STS require port 443 for policy lookup?

MTA-STS requires port 443 because it relies on HTTPS for securely fetching its policy file. HTTPS ensures the policy's integrity and authenticity, preventing attackers from tampering with it or conducting downgrade attacks on email traffic. This standard port leverages existing web security infrastructure.

What happens if my MTA-STS policy isn't accessible on port 443?

If your MTA-STS policy isn't accessible on port 443, sending mail servers will not be able to retrieve it. This means your domain's MTA-STS protection will fail, and emails to your domain will revert to opportunistic TLS, or potentially unencrypted delivery, making them vulnerable to attacks. What happens if an MTA-STS policy file is not found? explains this further.

Does MTA-STS use the same port as SMTP for email delivery?

No, MTA-STS uses port 443 (HTTPS) for policy lookup, while standard SMTP email delivery typically uses port 25, 465 (SMTPS), or 587 (submission). MTA-STS's role is to ensure that SMTP connections for mail exchange are then secured with TLS, it doesn't replace the SMTP ports.

Is an SSL certificate required for the MTA-STS policy hosted on port 443?

Yes, a valid, trusted SSL/TLS certificate is absolutely required for the web server hosting the MTA-STS policy. Without a proper certificate, the HTTPS connection cannot be established securely, and the policy will be rejected by sending MTAs, negating the security benefits of MTA-STS.

What is the default port for the MTA-STS policy lookup? - MTA-STS - Email authentication - Knowledge base

Stylized illustration of an envelope with a padlock, representing secure email communication through MTA-STS.

Mail Transfer Agent Strict Transport Security, or MTA-STS, is a crucial email security standard designed to ensure that emails are always sent over secure, encrypted connections. It helps prevent downgrade attacks and Man-in-the-Middle (MITM) attacks by requiring mail servers to use TLS (Transport Layer Security) when exchanging mail with domains that have an MTA-STS policy.

The primary goal of MTA-STS is to specify that a domain's mail exchange (MX) hosts must support TLS, and to enforce certificate validation for those connections. Without it, opportunistic TLS might be downgraded, leaving email traffic vulnerable to eavesdropping and tampering. By publishing an MTA-STS policy, a domain declares its commitment to secure email transport.

When a sending mail server (MTA) wants to deliver mail to a domain, it first looks for an MTA-STS policy. This policy lookup mechanism is designed to be secure and reliable. To answer the question directly, the default port for the MTA-STS policy lookup is 443, which is the standard port for HTTPS traffic.

Understanding MTA-STS policy fetching

The MTA-STS policy fetching process begins when a sending MTA queries a special DNS TXT record for the recipient domain. This TXT record indicates that an MTA-STS policy exists and provides a policy ID. After discovering this, the sending MTA then attempts to retrieve the actual policy file from a specific URL on the recipient's web server.

For the MTA-STS policy to be successfully retrieved, it must be served over HTTPS. This is a critical security requirement, as it ensures the integrity and authenticity of the policy file itself. Any attempt to retrieve the policy over an unencrypted connection, or from a server with an invalid SSL certificate, will result in the policy being rejected. You can learn more about how MTA-STS policy fetching works in our other guides.

The use of port 443 for HTTPS is non-negotiable for MTA-STS. This standardization simplifies implementation and ensures that MTAs know exactly where to look for the policy. It also leverages the robust security infrastructure already in place for web traffic, reducing the attack surface. This is why MTA-STS uses HTTPS for policy retrieval instead of SMTP.

Key components of an MTA-STS policy file

Version: Currently, this should always be STSv1.
Mode: Defines the policy's enforcement level (e.g., testing, enforce). There are three possible mode values.
Max_age: Specifies how long the policy should be cached, in seconds.
MX: Lists the mail exchange hosts that are authorized to receive mail for the domain. The 'mx' field is crucial for validation.

The critical role of HTTPS and port 443

The strict requirement for HTTPS on port 443 ensures that the MTA-STS policy itself cannot be tampered with during transmission. If the policy could be fetched over an insecure connection, an attacker could intercept it, modify it to disable TLS enforcement, and then conduct a downgrade attack on email traffic. By enforcing HTTPS, MTA-STS adds a vital layer of trust and security to the policy discovery process.

Furthermore, the web server hosting the MTA-STS policy must use a trusted SSL/TLS certificate. Self-signed certificates or certificates issued by untrusted Certificate Authorities (CAs) will cause the policy lookup to fail. This aligns with the broader goals of email authentication standards like DMARC, SPF, and DKIM, which collectively aim to build a more secure email ecosystem.

For those looking to implement or configure their MTA-STS policy, understanding this specific requirement is paramount. Detailed steps for setting up MTA-STS, including the HTTPS requirement on port 443, are often provided in official documentation, such as this guide on configuring MTA-STS and TLS reporting for your domain using Apache on Ubuntu. Additionally, Cisco offers configuration steps for secure email gateways which emphasize this standard.

Stylized illustration of a server rack highlighting Port 443 HTTPS connections for MTA-STS policy retrieval.

Setting up your MTA-STS policy web server

To host your MTA-STS policy, you need a web server (or a virtual host on an existing one) configured to listen on port 443 and serve the policy file. The policy file itself, often named mta-sts.txt, must be placed in a specific directory path: /.well-known/mta-sts/ of a special mta-sts subdomain. This ensures consistent lookup for all recipient MTAs.

Example Nginx configuration for MTA-STSnginx

server {
    listen 443 ssl;
    server_name mta-sts.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/mta-sts.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.yourdomain.com/privkey.pem;

    location /.well-known/mta-sts/ {
        default_type "text/plain";
        root /var/www/mta-sts;
    }
}

This setup is crucial because without a properly configured web server listening on port 443 with a valid certificate, the MTA-STS policy cannot be retrieved. This means your domain will not benefit from the enhanced security that MTA-STS provides. It’s also important to ensure your MTA-STS file name and its directory path are correct.

Dedicated subdomain: The policy must be hosted on mta-sts.yourdomain.com.
HTTPS only: Policy retrieval must occur over port 443 with a valid TLS certificate.
Specific path: The policy file lives at https://mta-sts.yourdomain.com/.well-known/mta-sts/mta-sts.txt.
Content-type: The file should be served with a Content-Type header of text/plain.

Monitoring MTA-STS and overall email security

While MTA-STS enhances email security, its effectiveness relies on correct implementation and continuous monitoring. Problems with DNS records, SSL certificates, or policy file availability can lead to emails failing to be delivered securely, or even bouncing. Regularly checking your MTA-STS configuration and ensuring it's always accessible on port 443 is vital for maintaining a strong email posture.

This is where dedicated email security platforms like Suped become invaluable. Suped offers robust DMARC monitoring that helps you oversee MTA-STS performance by providing detailed reports and insights. Our AI-powered recommendations help you quickly identify and fix issues, ensuring your policy is always enforced correctly. With Suped, you get real-time alerts and a unified platform for DMARC, SPF, DKIM, and deliverability, all with a generous free plan to get you started.

Beyond MTA-STS, a holistic approach to email security involves proper DMARC monitoring, SPF flattening, and active blocklist monitoring. These measures collectively fortify your domain against various email threats, improve your sender reputation, and help ensure your messages land in the inbox. Ignoring any of these can lead to email deliverability issues and negatively impact your communication.

Before Suped

Manual checks: Required constant manual effort to verify MTA-STS configuration.
Delayed issue detection: Configuration errors or certificate expiry often discovered too late.
Fragmented insights: DMARC, SPF, DKIM, and MTA-STS data scattered across multiple tools.
Lack of guidance: No clear steps provided for fixing email authentication problems.

With Suped

AI-powered recommendations: Get actionable advice to fix MTA-STS and DMARC issues promptly.
Real-time alerts: Instantly notified of any MTA-STS or DMARC policy disruptions.
Unified platform: Centralized view of all email authentication and deliverability data.
MSP dashboard: Manage multiple client domains from a single, intuitive interface.

Ensuring secure email communication

The default port for the MTA-STS policy lookup is 443, aligning with the standard for secure HTTPS traffic. This adherence to HTTPS on a specific subdomain (mta-sts.yourdomain.com) and a well-known path (/.well-known/mta-sts/mta-sts.txt) is fundamental to the security model of MTA-STS. By enforcing TLS encryption and certificate validation, MTA-STS significantly reduces the risk of email interception and tampering.