What's new in DMARCHub v0.54: new sending IP alerts and a steadier MTA-STS

DMARCHub v0.54 is live. The headline is new sending IP alerts: we now tell you when your DMARC reports show mail sent as your domain from a source we have not seen before. Alongside it, MTA-STS goes live much sooner and then settles into a longer cache duration in planned steps, setting up a domain is down to two steps, hosted DMARC publishes and shows your policy without the wait, and the managed SPF screens are clearer about what to publish.

Everything below is already in the portal. Only one change, the MTA-STS cache duration, touches anything you already have set up, and it does so on a timetable we describe in full below, with an email at each step.

New sending IP alerts

Every aggregate report lists the IP addresses that sent mail using your domain name. Most of the time a new address is a service someone has just started using, such as a newsletter tool or a helpdesk. Sometimes it is someone sending mail that pretends to come from you. Either way it is worth knowing about while it is fresh, and spotting it by reading reports is slow work. Our guide to unknown sources in DMARC reports covers how to work out which is which.

We now keep a record of every address seen for each of your domains, and when a report shows one that is new for that domain we check it a few minutes later and email your organisation's owners and admins. You receive at most one of these emails per domain per day. Each new source is listed with its network, how many messages it sent, whether they passed DMARC, which mail provider reported it and when it was first seen, and the email links to the domain's Messages tab.

An alert that fires on every ordinary sender would soon be ignored, so we leave out the sources that are expected:

• Your own mail provider. If your domain's mail is handled by Microsoft 365 or Google Workspace, addresses that belong to that provider are left out, but only when we can prove it: the address's reverse DNS name has to point back to the same address, or the address has to be in the ranges the provider publishes. A name alone proves nothing, because anyone can set one. Reverse DNS and email explains why.
• Senders already covered by your managed SPF record.
• Networks the domain already sends from, such as a new address at an email service you already use. Home broadband and shared cloud hosting do not count, because one address there says nothing about who else is on that network.
• Mail forwarders and mailing lists passing on your own mail. We only count an address as one when every message from it was marked by the receiving provider as forwarded or from a mailing list, or still carries your own domain's valid DKIM signature while SPF did not pass for your domain. The signature part only covers an address passing on a small number of messages; a server sending a large volume still alerts, even if it signs with your key, which also catches someone resending copies of your genuine mail. A list that changes your messages and breaks the signature looks exactly like spoofing, so that still alerts.
• A new domain's first week, while we learn its usual senders, and old reports that describe history rather than a new sender.

When a source on the list is one nobody recognises, the knowledge base article on new sending IP alerts walks through what to check, and finding all of your email senders covers the wider job of keeping track of who sends for you.

Do you need to do anything? No. Alerts are on by default for owners and admins on every plan, and existing domains start quietly: every address already in your reports counts as known, so this arriving does not set off a flood of alerts. Anyone who would rather not receive them can untick New sending IP alerts under Settings, on the Account tab.

MTA-STS: live within the hour, then a cache duration that grows

MTA-STS asks other mail servers to deliver to your domain only over an encrypted, verified connection. What is MTA-STS explains the mechanism. Two things have changed.

The first is how quickly it goes live. Before, we confirmed a new policy in a daily check that waited two days after your records were verified, so the "MTA-STS is now active" email could take two or three days. We now check every 15 minutes, confirm that your policy is really being served over HTTPS, the same way a sending mail server fetches it, and email you as soon as it is. That is usually within an hour of your records being verified.

The second is how long other mail servers keep your policy. A server that follows your policy keeps a copy for a set time, called the cache duration (the policy's max_age), and applies that copy even if it cannot reach your policy again in the meantime. We now set it in three steps:

• 1 day when the policy is new. While it beds in, a short cache means any mistake, such as a mail server missing from your list or a certificate problem, clears from other mail servers within a day once it is fixed.
• 7 days once the policy has been served without problems for four weeks. A longer cache means senders keep protecting your mail even if they briefly cannot reach your policy, and it makes it harder for an attacker who blocks or tampers with the policy lookup to strip the encryption requirement. That is called a downgrade attack.
• 28 days four weeks after that. A cache of several weeks is what the MTA-STS standard recommends for a stable policy and what large mail providers use. This is the final level.

We email your owners and admins at each step, explaining why it is happening and, for the first step, roughly when the next one is due. The MTA-STS tab shows the current duration and the approximate date of the next step. The trade-off is that the longer the cache, the longer a change to your policy takes to reach every sender. So, before you change mail provider, add the new provider's mail servers to the list on the MTA-STS tab first, and do not turn MTA-STS off to make the move: a server that already holds your policy keeps applying it until its copy expires. The tab now says how long that can be. It also has a Reset cache duration to 1 day button: before a move to a different email provider, use it, or switch the policy to testing mode, as far ahead of the move as your current cache duration. The steps then start again, with an email each time.

Changing the mode between testing and enforce, turning MTA-STS off and on again, or cancelling a turn-off, starts the steps again at 1 day, so a mistake in the new set-up clears quickly. Changing only your list of mail servers keeps the current duration. The four weeks are counted from when we started serving your policy, so a domain that is still being set up does not move on.

Turning MTA-STS off is now safe too. Because other mail servers can remember your policy for up to its cache duration, switching it off at once could leave one of them refusing mail to a new mail server for weeks. So when you click Turn off MTA-STS, we follow the procedure the MTA-STS standard sets out: we first switch your policy to none, which tells other mail servers to stop applying it, publish that as a new version so they fetch it, and keep it published until every remembered copy of your old policy has expired. The tab shows the date, and you can cancel before then. On that date MTA-STS switches off and we email you to say which two DNS records you can remove. Leave them in place until that email. If no other mail server could have fetched your policy, for example because its two DNS records were never added, it switches off straight away.

Deleting a domain that uses MTA-STS now winds down in the same safe way, even though the domain itself is gone from your account straight away. And whether you turn MTA-STS off or delete a domain, we now tell you exactly which DNS records to remove and when: the confirmation lists each record, with copy buttons, and says which to remove now, which to replace and with what, and which to keep until a date. We email you the same list, and email again when the last of them can go.

Records we publish for you on your behalf also no longer set off DNS change alerts. Each step above publishes a new version of your policy, and so does saving your MTA-STS settings or editing a hosted DMARC policy. Each of those used to raise a "DNS change detected" email for a change you either made through us or did not make at all. A change made by anyone else still alerts as before.

Do you need to do anything? No. A policy that has already been served for four weeks or more moves to 7 days over the next few days, with an email when it does, and to 28 days four weeks later. If you are planning to change mail provider, read the knowledge base article on how long mail servers keep your MTA-STS policy first.

Setting up a domain now takes two steps

Adding a domain, whether it is your first or your tenth, now asks for two things: verify that you own it, then set up DMARC. The optional third step, which asked for two MTA-STS records and a TLS reporting record before you had seen a single report, has gone from the setup flow. MTA-STS and TLS reporting are set up from the domain's MTA-STS tab once monitoring is running, and managed SPF from SPF Settings, and the final step of setup points you to both.

If you leave part way through, opening the domain now takes you back into setup where you left off, rather than to a mostly empty page with a reminder banner. A domain that is already receiving reports always opens as normal, and the setup page has links to the domain's settings if you would rather remove the domain or manage your own DMARC record instead.

Do you need to do anything? No. Domains that are already set up are not affected.

Hosted DMARC without the wait

If we host your DMARC record, as described in what is hosted DMARC, three waits have gone:

• We publish your record as soon as your domain is ready, rather than in our next hourly pass. Before, a DNS change made straight away could point at a record that did not exist yet for up to an hour.
• We notice your DNS change ourselves, usually within 15 minutes, even if you never press the check button. A domain whose owner made the change and walked away used to stay marked as unfinished for good.
• Your policy shows on the domain's overview and on the dashboard as soon as it is live, instead of waiting for an hourly check or for the first report. When you move from none to quarantine or reject, the new policy shows straight away too.

The setup screens are also more careful with their words: when your DNS change has been found but our record is still being published, they now say so, instead of announcing that monitoring is on a moment early.

Do you need to do anything? No.

Clearer managed SPF instructions

The SPF Settings tab now shows the record to publish as a TXT record with its host, alongside a note to replace your existing SPF record and leave your other TXT records as they are. That came from a real case: a verification value, such as google-site-verification= or MS=, typed into the same DNS entry as the SPF record. Separated by a space it is ignored by SPF; joined on without a space it makes the whole record unreadable. We now point out a value like that by name, explain that it belongs in a TXT record of its own, and show the same explanation wherever we display your record. Managed SPF also now only switches on with the SPF record that is actually published at your domain, so the record we offer back if you ever hand SPF back to yourself is always the real one.

Do you need to do anything? Only if the tab points out a value like this in your record. Managed SPF is available on selected plans.

Each DNS record now lives with its feature

Each domain used to have a DNS records tab listing every record we asked you to publish, separate from the settings those records belong to. That tab has gone, and each record now sits with the feature it is for, with the same live check beside it:

• The two MTA-STS records are on the MTA-STS tab, with a live status for each from the moment you turn it on until it is fully off.
• The TLS reporting record is on a new TLS Records tab, next to MTA-STS. It is there whether or not TLS reports are switched on, and when they are off it explains how to switch them on.
• If you manage your own DMARC record rather than letting us host it, the record and whether it is sending reports to us are on the DMARC Settings tab.

A record that is published but sends its reports somewhere else is now flagged as not verified, with a note saying so, and if we cannot get an answer from DNS at that moment the status says so rather than guessing. An old link or bookmark to the DNS records tab now opens the domain's overview.

Do you need to do anything? No. Nothing about your records has changed, only where you find them.

Smaller changes

• In Settings, on the Account tab, New sending IP alerts is now ticked by default to match what is sent, and the Weekly DMARC summary email is marked as coming soon. Team members who do not receive alert emails see a short note explaining that they go to owners and admins.
• Team members whose access has been locked no longer receive alert emails.
• Emails we send only once, such as the reminder to finish setting up hosted DMARC, are now tried again if sending fails, instead of being treated as if they had gone.
• The button in our card expiry reminder emails now opens your billing page.
• If someone starts signing up but never finishes their company details, we now send a reminder after two weeks and a final notice two weeks after that. If setup is still unfinished a week later, the sign-up is closed and its data is deleted 30 days after that. Organisations that have finished setting up are not affected.
• New and updated knowledge base articles cover new sending IP alerts, the MTA-STS cache duration, the two-step domain setup and your account settings.
• The roadmap is current: New sending IP alerts has moved to Implemented, and the simpler domain setup and faster MTA-STS activation have been added.

Where to start

Change	Where it lives	What it asks of you
New sending IP alerts	Your inbox, with details on each domain's Messages tab	Nothing. On by default; switch it off under Settings, on the Account tab.
MTA-STS cache duration steps	MTA-STS tab	Nothing. Before you change mail provider, reset the cache duration to 1 day or switch to testing, as far ahead of the move as the current duration.
Safe MTA-STS turn-off, and on deleting a domain	MTA-STS tab, the delete confirmation and your inbox	Only if you turn MTA-STS off or delete a domain: follow the list of DNS records we show and email you, keeping the MTA-STS records until the date given.
Faster MTA-STS activation	MTA-STS tab and your inbox	Nothing beyond the two DNS records you already add.
Two-step domain setup	Adding a domain, and opening one you have not finished	Nothing.
Hosted DMARC without the wait	DMARC Settings tab and the domain overview	Nothing.
Clearer managed SPF instructions	SPF Settings tab	Only if it points out a stray value in your SPF record.
DNS records with their features	MTA-STS, TLS Records and DMARC Settings tabs	Nothing. Your records are unchanged.

Every release is listed in the portal under What's new, and the knowledge base carries the step-by-step guides for each of these. If any of it does not behave the way this post describes, tell us and we will look at it.