What's new in DMARCHub v0.53: managed SPF, DNSSEC and guided MTA-STS

DMARCHub v0.53 is live. The headline is managed SPF: we can now build and publish your SPF record for you, resolving your sending services to addresses so that following them costs none of the ten DNS lookups SPF allows. Alongside it, DNSSEC has joined the records we monitor, hosted DMARC can copy your aggregate reports to up to three more addresses, and MTA-STS setup is now a guided sequence rather than a page of instructions.

Everything below is already in the portal. None of it changes your DNS on its own: where a change to your own records is needed, the relevant tab shows you exactly what to publish and then waits for you.

Managed SPF, with flattening

SPF is the record that lists which servers may send email using your domain name, and a receiving server is allowed only ten DNS lookups while it checks yours. Four or five email services is often enough to go over, and above ten the check fails outright rather than degrading quietly. Our guide to the ten DNS lookup limit covers why that ceiling exists and how quickly it fills up.

Each domain now has an SPF Settings tab. It starts by importing the record you publish today, so the managed record opens with your real senders in it rather than a blank page. For each of those services you choose what the managed record says: keep the provider's include, which costs a lookup, or write out the addresses that service publishes, which costs none. The second of those is what the industry calls SPF flattening. We re-check those addresses on a schedule and keep the record current as providers move theirs.

Your side of it is one change in your own DNS, a single line at your domain's apex that replaces the SPF record you publish now:

v=spf1 redirect=yourdomain-abc123._spf.dmcrpt.io

Until you publish that line, nothing changes: we build the record first and show it to you in full, so you can compare it against what you had before you commit to anything. The redirect does not abolish the ten-lookup limit, it moves it: everything in the record we publish counts against the same ten, and we hold our side of it to eight at most.

A record built from resolved addresses is a cached copy of somebody else's DNS, and that carries a staleness risk an include does not. It is a real trade-off rather than a free win, which is why the companion post, should you let somebody else publish your SPF record, goes through it properly: what we publish, what happens when a provider changes their addresses or a lookup gives an incomplete answer, and how you take the record back. Read that one before you turn this on.

Do you need to do anything? Only if you want it. Managed SPF is available on selected plans, and the SPF Settings tab on each domain says whether yours includes it. Left alone, your SPF record stays exactly as you publish it today.

DNSSEC on the DNS Monitoring tab

DNSSEC (Domain Name System Security Extensions) signs your domain's DNS answers so that other name servers can check they genuinely came from you. It matters for email because SPF, DKIM and DMARC all live in DNS. It is switched on at your registrar rather than here, and plenty of working domains run without it.

The DNS Monitoring tab now reports whether DNSSEC is switched on for your domain, and tells you if that ever changes, through the same timeline, alerts and notifications as the rest of the records we watch. The panel has three states rather than two: enabled, where your registrar publishes a DS record and we list the signing keys; not enabled, where there is none; and unknown, where we could not get a clear answer. A failed lookup and a domain genuinely running without DNSSEC are different things, so we say we do not know rather than guess at it.

Do you need to do anything? No. Where DNS monitoring is included in your plan, the check runs by itself for every verified domain. The first check records a starting snapshot only, so this arriving never raises an alert of its own.

Up to three extra DMARC reporting addresses

If we host your DMARC record, the DMARC Settings tab now lets you add up to three further reporting addresses, so copies of your daily aggregate reports also reach another service or a colleague's mailbox. Your DMARCHub address stays first, and it is the aggregate reports that are copied; detailed failure reports stay with us. The difference between the two is covered in rua and ruf explained.

An address outside your own domain needs that domain's agreement before most receivers will send it anything, in the form of a small DNS record on their side. Click Check authorisation and we look it up, showing you the exact record whoever runs that domain needs to publish if it is missing. Without that record the reports never arrive and nothing tells you why, so it is worth checking rather than assuming.

Do you need to do anything? Nothing, unless you want your reports copied somewhere else. Hosted DMARC is included on every plan and existing reporting carries on unchanged.

MTA-STS, now a guided setup

MTA-STS (Mail Transfer Agent Strict Transport Security) asks other mail servers to deliver to your domain only over an encrypted, verified connection, rather than falling back to plain text when encryption is not available. What is MTA-STS explains the mechanism. The awkward part has never been the concept, it is the assembly: a policy file served over HTTPS, a DNS record advertising it, and an accurate list of your own mail servers.

The MTA-STS tab now takes it a step at a time. Detect mail servers fills the list from the mail servers your domain publishes today, for you to check, because a sender following your policy may refuse to deliver to a server that is not on it. You choose testing, which asks senders to report problems but deliver as normal, or enforce, which asks them to refuse delivery when a secure connection cannot be verified. We publish the policy, you add the two DNS records the tab gives you, and Check DNS records confirms they are in place. The tab also shows the date your policy went live instead of only telling you by email, and saving your settings when nothing has changed no longer restarts the wait.

Start in testing, watch the TLS reports from the tick box on the same tab, and move to enforce once sessions are succeeding consistently.

Do you need to do anything? Only if you want MTA-STS on the domain. An existing policy carries on as it is.

Smaller changes

• The DMARC Settings tab uses the full width of the page, so your policy settings and the record we publish for you sit side by side.
• New and updated help articles in the knowledge base cover managed SPF, DNSSEC, the extra reporting addresses and the MTA-STS setup.
• Help articles that ship with DMARCHub can now be brought up to date when we release, so a guide overtaken by a change no longer sits there saying the old thing. An article our team has edited is never overwritten.
• The roadmap is current: SPF management and flattening and multiple reporting addresses have both moved to Implemented, and DNSSEC monitoring and the guided MTA-STS setup have been added.

Where to start

Change	Where it lives	What it asks of you
Managed SPF with flattening	SPF Settings tab on each domain	On selected plans. Import your current record, review what we build, then one DNS change at your apex when you are ready.
DNSSEC monitoring	DNS Monitoring tab	Nothing, where DNS monitoring is in your plan.
Extra DMARC reporting addresses	DMARC Settings tab	Nothing, unless you want copies of your aggregate reports sent elsewhere.
Guided MTA-STS setup	MTA-STS tab	Two DNS records, when you choose to turn it on.

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.