IT Toolbox
Procedure

Deploy MTA-STS and TLS-RPT

Deploy MTA-STS and SMTP TLS Reporting without disrupting mail reception by auditing MX and STARTTLS, publishing the HTTPS policy in testing mode, adding DNS records, reviewing TLS-RPT reports, and moving to enforce gradually.

Email

Objective

Deploy MTA-STS and SMTP TLS Reporting without disrupting mail reception by auditing MX and STARTTLS, publishing the HTTPS policy in testing mode, adding DNS records, reviewing TLS-RPT reports, and moving to enforce gradually.

Prerequisites

  • The sending domain, sender address, recipient and the exact mail path or provider.
  • Access to DNS and mail-system logs or message tracing appropriate to the environment.
  • Administrative access appropriate to the system being changed or diagnosed.
  • A clearly identified scope: affected users, systems, addresses, services and the time of the observed problem.
  • A maintenance or test window when the procedure can affect production traffic or availability.
  • A copy of the current configuration or other recovery material before any irreversible action.

Step-by-step procedure

1

Establish the baseline and scope

Before changing anything, reproduce the issue or document the requested change on a representative system. Record the affected users or services, exact time, current configuration, recent changes and a known-good comparison point. This baseline is the reference used to decide whether each later step improves the situation.

Expected result
  • The scope and current state are documented well enough to reproduce or verify the procedure.
2

Auditing MX

Implement this requirement in a controlled scope: auditing MX. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
3

STARTTLS

Implement this requirement in a controlled scope: STARTTLS. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
4

The HTTPS policy in testing mode

Implement this requirement in a controlled scope: the HTTPS policy in testing mode. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
5

Adding DNS records

Implement this requirement in a controlled scope: adding DNS records. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
6

TLS-RPT reports

Implement this requirement in a controlled scope: TLS-RPT reports. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
7

Moving to enforce gradually

Implement this requirement in a controlled scope: moving to enforce gradually. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
8

Validate the complete service

Repeat the original user, system or application workflow from the real source and verify the complete result, not only one command or one local check. Confirm that logs and monitoring show the expected behavior and that no temporary debug, bypass, test account, rule or maintenance setting remains enabled.

Expected result
  • The end-to-end service works or the remaining failure is isolated to a clearly identified component.

Technical commands from the original procedure

These technical blocks are preserved byte-for-byte from the historical procedure and kept in their original order. Review names, addresses, paths and parameters before use.

Technical block 1
Resolve-DnsName -Type MX <DOMAINE>
Technical block 2
nslookup -type=mx <DOMAINE>
Technical block 3
Test-NetConnection <MX-FQDN> -Port 25
Technical block 4
openssl s_client -starttls smtp -connect <MX-FQDN>:25 -servername <MX-FQDN> -verify_return_error
Technical block 5
Resolve-DnsName mta-sts.<DOMAINE>
Technical block 6
curl -I https://mta-sts.<DOMAINE>/.well-known/mta-sts.txt
Technical block 7
version: STSv1
mode: testing
mx: <MX1.EXEMPLE.NET>
mx: <MX2.EXEMPLE.NET>
max_age: 86400
Technical block 8
curl https://mta-sts.<DOMAINE>/.well-known/mta-sts.txt
Technical block 9
TXT _mta-sts.<DOMAINE> = "v=STSv1; id=20260810T140000Z;"
Technical block 10
Resolve-DnsName -Type TXT _mta-sts.<DOMAINE>
Technical block 11
TXT _smtp._tls.<DOMAINE> = "v=TLSRPTv1; rua=mailto:tlsrpt@<DOMAINE>"
Technical block 12
Resolve-DnsName -Type TXT _smtp._tls.<DOMAINE>
Technical block 13
version: STSv1
mode: enforce
mx: <MX1.EXEMPLE.NET>
mx: <MX2.EXEMPLE.NET>
max_age: 604800
Technical block 14
TXT _mta-sts.<DOMAINE> = "v=STSv1; id=20260817T090000Z;"
Technical block 15
curl -fsS https://mta-sts.<DOMAINE>/.well-known/mta-sts.txt
Technical block 16
Resolve-DnsName -Type MX <DOMAINE>
Technical block 17
Resolve-DnsName -Type TXT _mta-sts.<DOMAINE>

Validation

The procedure is validated when:

  • The original symptom or change request has been tested end to end.
  • The effective configuration matches the intended design and no unexplained error remains in the relevant logs.
  • Temporary troubleshooting controls have been removed and monitoring remains normal.
  • The result, evidence and any follow-up action are documented.

Rollback

  • Restore the configuration, policy, binding, route, credential assignment or service state recorded in the baseline when the change does not meet its success criteria.
  • Remove temporary rules, test objects and diagnostic settings that were introduced only for the procedure.
  • After rollback, repeat the minimum health checks to confirm that the previous service level has been restored.

Troubleshooting / common errors

  • Always distinguish envelope MAIL FROM, visible From, Reply-To and authenticated identity.
  • DNS changes can be correct at the authoritative server while recursive resolvers still hold the previous value until TTL expiry.
  • If the result changes between tests, compare source, destination, identity, time and policy context before changing additional settings.
  • If a command succeeds but the application still fails, continue at the next protocol or application layer instead of widening access.
  • If the expected evidence is missing, verify that logging, auditing and the test path actually cover the failing component.
  • If the change does not improve the measured symptom, restore the previous state and reassess the working hypothesis.

Official and vendor references preserved from the original procedure

♡ 0