security.txt, MTA-STS and TLS-RPT: Three Simple Steps to Improve Website and Email Security
Website and email security today goes far beyond SSL certificates, antivirus software, and properly configured SPF, DKIM, and DMARC records. There are also several less well-known standards that can significantly improve vulnerability reporting and the security of email communication.
Among the most useful are security.txt, MTA-STS, and TLS-RPT.
Each of these mechanisms addresses a different area of security:
- security.txt helps security researchers report vulnerabilities,
- MTA-STS helps enforce secure email delivery over TLS,
- TLS-RPT provides reports about problems with encrypted email delivery.
Their implementation is relatively straightforward.
What is security.txt?
The security.txt file provides a standardized way to publish contact information and instructions for reporting security vulnerabilities.
The standard is defined in RFC 9116.
If, for example, a security researcher discovers a vulnerability on your website, they do not have to search for a contact form, technical support address, or server administrator. The information needed to report the issue can be found at a standardized location:
https://example.com/.well-known/security.txt
The file is primarily intended to improve communication between internet service operators and people who discover security issues.
Example of a security.txt file
Contact: mailto:This email address is being protected from spambots. You need JavaScript enabled to view it.
Expires: 2027-08-31T23:59:59Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
The most important field is:
Contact
This specifies how a security issue should be reported.
RFC 9116 also requires the Expires field, which defines how long the published information remains valid.
Additional fields can also be used, such as links to the company security policy or vulnerability disclosure policy.
Where should security.txt be located?
The preferred location is:
/.well-known/security.txt
For example:
https://www.example.com/.well-known/security.txt
The file should be available over HTTPS and served as plain text.
It is also important to understand that security.txt applies to the specific domain or IP address from which it is retrieved. It does not automatically apply to every subdomain.
Why use security.txt?
Security.txt does not directly prevent a server from being compromised. However, it significantly improves the process of responsible vulnerability disclosure.
This can be particularly useful for companies, hosting providers, e-commerce websites, and operators of larger internet services.
For example, a security researcher may discover a vulnerability that allows authentication to be bypassed. If no suitable security contact can be found, the issue may remain unreported for a long period of time.
Security.txt clearly tells the researcher:
“Report security issues to us here.”
Implementation usually takes only a few minutes.
What is MTA-STS?
MTA-STS stands for:
Mail Transfer Agent Strict Transport Security
It is a standard defined in RFC 8461 designed to improve the security of communication between email servers.
SMTP was originally designed at a time when encrypted communication was not the default. The STARTTLS extension was later introduced to allow SMTP connections to be secured using TLS.
The problem is that traditional STARTTLS can, under certain circumstances, allow a connection to fall back to unencrypted delivery.
MTA-STS helps mitigate this problem.
How does MTA-STS work?
A domain publishes information in DNS indicating:
“An MTA-STS security policy exists for this domain.”
The sending mail server can then retrieve this policy over HTTPS.
An MTA-STS policy can specify:
- which MX servers are authorized to receive email,
- that TLS must be supported,
- that TLS certificates must be valid,
- how long sending servers should cache the policy.
This significantly reduces the risk of certain attacks against SMTP communication.
MTA-STS DNS record
For the domain example.com, a TXT record can be created at:
_mta-sts.example.com
With a value such as:
v=STSv1; id=20260831
The id parameter acts as an identifier for the current version of the policy.
If the policy changes, the value of this identifier should also be changed.
MTA-STS policy
The actual policy must be available over HTTPS at:
https://mta-sts.example.com/.well-known/mta-sts.txt
For example:
version: STSv1 mode: enforce mx: mail.example.com max_age: 604800
This specifies that email is received by:
mail.example.com
and that the policy should be enforced.
MTA-STS modes
MTA-STS provides three basic modes:
none
The policy is effectively not enforced.
testing
The policy is evaluated, but failures should not prevent message delivery.
enforce
The policy is actively enforced.
If a sending server that supports MTA-STS cannot establish a connection that complies with the published security policy, it should not simply deliver the message using an insecure connection.
For an initial deployment, it is therefore recommended to start with:
mode: testing
Once the configuration has been verified, the policy can be changed to:
mode: enforce
What is TLS-RPT?
TLS-RPT, also known as SMTP TLS Reporting, is defined in RFC 8460.
It is a reporting mechanism that allows domain operators to receive information about problems that occur during secure SMTP connections.
The concept is similar to reporting mechanisms used with DMARC.
If, for example, another email server cannot establish a secure connection with your MX server, TLS-RPT can provide information about the problem.
How to configure TLS-RPT
For the domain example.com, the following DNS TXT record is used:
_smtp._tls.example.com
For example:
v=TLSRPTv1; rua=mailto:This email address is being protected from spambots. You need JavaScript enabled to view it.
Aggregated TLS reports can then be sent to:
This email address is being protected from spambots. You need JavaScript enabled to view it.
The standard also allows HTTPS endpoints to be used for report delivery.
What can TLS-RPT reports reveal?
TLS-RPT reports can highlight issues such as:
- STARTTLS failures,
- TLS certificate problems,
- MTA-STS policy mismatches,
- MX server problems,
- DNS issues,
- TLS connection failures.
This allows administrators to identify issues that might otherwise remain unnoticed.
A typical example is an incorrectly renewed certificate on one of several MX servers.
Standard website monitoring may not detect such a problem, while TLS-RPT can reveal that external mail servers are experiencing delivery issues.
MTA-STS and TLS-RPT should be used together
The greatest benefit comes from combining both technologies.
MTA-STS defines the rules.
TLS-RPT reports whether problems occur while following those rules.
In very simple terms:
MTA-STS = protection TLS-RPT = monitoring
Before enabling enforce mode in MTA-STS, it is therefore advisable to have TLS-RPT enabled first.
You can initially monitor the configuration for several days using:
mode: testing
and only then switch to:
mode: enforce
security.txt vs. MTA-STS vs. TLS-RPT
Although all three technologies are related to internet security, their purposes are different.
| Technology | Purpose |
|---|---|
| security.txt | Contact information and instructions for reporting security vulnerabilities |
| MTA-STS | Enforcing safer TLS communication between email servers |
| TLS-RPT | Reporting TLS-related problems during email delivery |
Security.txt primarily addresses security communication between people and organizations.
MTA-STS and TLS-RPT primarily address communication between email servers.
How does MTA-STS relate to SPF, DKIM, and DMARC?
These technologies do not replace one another.
SPF, DKIM, and DMARC primarily address sender authentication and protection against domain spoofing and abuse.
MTA-STS addresses a different problem:
the security of the transport layer when email messages are transferred between SMTP servers.
In simplified terms:
SPF → who is allowed to send DKIM → cryptographic message signature DMARC → authentication policy and reporting MTA-STS → secure transport between mail servers TLS-RPT → TLS delivery reporting
For a properly secured corporate domain, it therefore makes sense to use several of these technologies together.
What about DANE?
MTA-STS is not the only method available for protecting SMTP transport.
Another option is DANE for SMTP, which uses DNSSEC and TLSA records.
DANE can provide strong cryptographic protection, but it requires correctly deployed DNSSEC infrastructure.
MTA-STS, on the other hand, uses a combination of DNS and HTTPS, which may be easier to deploy for many organizations.
TLS-RPT can also be used in environments that use DANE.
Do not forget proper TLS certificates for mail servers
Enabling MTA-STS will not fix an incorrectly configured mail server.
You should first ensure that the following are configured correctly:
- MX records,
- DNS,
- SMTP server configuration,
- STARTTLS,
- valid TLS certificates,
- correct server names in certificates,
- automatic certificate renewal.
Only after these elements have been verified should MTA-STS be switched to enforce mode.
An incorrect configuration could otherwise cause email delivery problems.
Who should use security.txt, MTA-STS, and TLS-RPT?
Implementation is especially recommended for:
- companies operating their own domains,
- e-commerce websites,
- web hosting companies,
- Cloud service providers,
- organizations running their own mail servers,
- healthcare organizations,
- financial companies,
- government and public institutions,
- operators of larger online services.
Security.txt can, however, be recommended for virtually any operator of a significant public-facing website.
Modern domain security is more than an SSL certificate
Internet infrastructure security consists of many relatively small measures.
Individually, they may not appear revolutionary, but together they create a significantly more resilient environment.
Alongside established technologies such as HTTPS, SPF, DKIM, and DMARC, it is therefore worth considering:
security.txt
MTA-STS
TLS-RPT
Deploying these standards is relatively simple, does not usually require major infrastructure changes, and can significantly improve both security and troubleshooting capabilities.
For operators of their own mail servers, the combination of MTA-STS + TLS-RPT is particularly useful, while security.txt is a simple standard that should increasingly be considered standard practice for corporate and publicly accessible internet services.
