# Managing MTA-STS policies
Once hosted MTA-STS is set up, open **Hosted services** → **MTA-STS** to manage the policy.
The page shows the current DNS and certificate status, policy settings, detected MX servers and the history of published policies.
## Policy mode
The mode determines what a sending server should do when it cannot deliver mail using one of the MX servers listed in the policy over a valid TLS connection.
- **None** tells sending servers to treat the domain as if it doesn't have an active MTA-STS policy, with no restrictions on delivery.
- **Testing** lets sending servers evaluate the policy, but a validation failure does not block or delay delivery. When the sender supports TLSRPT and the domain has it enabled, the failure is reported in a TLS report.
- **Enforce** requires sending servers to deliver to an MX hostname allowed by the policy, negotiate TLS and receive a valid, trusted certificate for that MX hostname. If these requirements aren't met, the sender must defer delivery and try again later. The failure can also be included in a TLS report when TLSRPT is supported and enabled.
New hosted policies start in `testing` mode. Review your [SMTP TLS reports](/docs/tlsrpt/setup) before switching to `enforce`.
Choosing the `none` mode publishes a non-enforcing policy, but hosted MTA-STS remains enabled. To disable MTA-STS completely, follow the [retirement process](/docs/mta-sts/retirement).
## Max age
The **max age** tells sending servers how long they can cache the policy. DMARCwise offers values from one day to 60 days and **recommends 14 days for normal use**.
A longer max age keeps the policy effective during temporary DNS or hosting problems and makes it harder for an attacker to suppress MTA-STS. The tradeoff is that an outdated policy can remain cached for longer, which can matter when changing MX providers or [retiring MTA-STS](/docs/mta-sts/retirement).
Sending servers don't need to download the policy for every email delivery. They can **keep a cached copy** and check the lightweight **DNS discovery record** for changes. When its ID changes, they know that a new policy is available and can fetch it.
Even when the ID hasn't changed, the MTA-STS standard recommends refreshing cached policies proactively, with **once a day** as a suggested frequency. A successful fetch starts the max age again. If a refresh fails, the sender continues applying its cached policy until its max age expires.
Publishing a new policy with a shorter max age does not shorten the lifetime of copies that were already cached: those copies keep their original max age until they are refreshed or expire.
## Detected MX servers
DMARCwise reads the **MX records** from your domain and includes the detected hostnames in the policy automatically.
When the MX records change, DMARCwise:
- Publishes a **new policy** containing the updated list.
- Updates the **discovery ID** so sending servers know about the change.
- **Sends an email** to active organization owners and admins showing the added and removed hosts.
## Additional MX servers
Use **Additional MX servers** when the policy must allow a hostname that is not currently returned by the domain's MX records. This can be useful during a mail provider migration.
Enter one hostname per line. You can also use a wildcard in the leftmost label, for example:
```
mail.example.com
*.example.com
```
Additional entries are combined with the automatically detected MX servers, with duplicate entries included only once.
## Publishing changes
After changing the mode, max age or additional MX servers, review the changes and click Publish policy.
DMARCwise makes the new policy available first and then updates the discovery record with its new ID. This order ensures that sending servers do not discover a policy version before it is ready to be fetched.
The page may briefly show **Sync in progress** while the discovery record is being updated.
## Policy history
Every published policy is saved in **Policy history**. The table shows:
- The discovery ID.
- Why the policy was created.
- Its mode and MX servers.
- When it was published.
Use the Preview button to inspect the exact policy text for an entry.
## DNS and certificate warnings
DMARCwise continues checking the DNS and certificate statuses even after the initial setup.
When **healthy DNS records become invalid** or when **the certificate cannot be issued or renewed** as expected, owners and admins of the organization receive an email notification.
If the dashboard reports a DNS problem, restore the two CNAME records shown in the onboarding instructions. If the records are valid but a certificate warning remains, [contact support](/@/support) so we can investigate.