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.

Hosted MTA-STS configuration page

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 before switching to enforce.

“None” does not disable hosting

Choosing the none mode publishes a non-enforcing policy, but hosted MTA-STS remains enabled. To disable MTA-STS completely, follow the retirement process.

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.

How sending servers refresh the policy

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 so we can investigate.