Mail security — DMARC reports, MTA-STS and DNSSEC

A domain's Mail security page answers three questions you cannot answer by looking in your own mailbox:

1. Who is sending mail as my domain, and does it check out?
2. Is the mail on its way to me arriving over a secure connection?
3. Is my DNS signed — and does the rest of the internet believe it?

You reach it through Accounts → your account → Email → Security. Email is one destination with two parts: Addresses (mailboxes, forwarding, mailing lists) and Security (this page). The domain is chosen at the top of the page; every domain publishes its own rules.

Screenshot — Panel → Accounts → your account → Email → Security. Screenshots of this page are captured with openwolf designqc into .wolf/designqc-captures/.

1. The DMARC reports

As soon as your domain receives mail here, we put a DMARC record in your DNS with a reporting address in it: dmarc-reports@yourdomain.com. That address belongs to the platform. There is no mailbox behind it, it does not count against your quota, and you cannot create it as a mailbox or a forwarder — precisely because it is published in DNS and therefore receives mail from strangers.

Receiving mail servers — Gmail, Outlook, a corporate mail server — send one report a day to that address. We read it and put it on the Reports tab:

• Messages — how much mail was seen claiming to be from your domain.
• Authenticated — how much of that was covered by DKIM or SPF. This is the number that should be heading for 100%.
• Sending sources — the addresses that sent it. Do you recognise all of them? A source that does not verify is either a service of yours that has not been set up (a newsletter tool, a webshop, an invoicing package), or somebody pretending to be you.
• Day by day — DKIM and SPF drawn as separate lines. That is deliberate: "SPF is fine and DKIM is broken" is the most common state of a domain that has just moved hosts, and a single merged line would hide exactly that.

The first reports arrive a day or two later. That is not a fault; it is how DMARC works, and the screen says so in as many words while there is nothing.

What do I do about a source that does not verify?

Find out who it is first — click the row and you get the address, how many messages, and what failed. If you recognise the service, it needs permission to send on your behalf: extend your domain's SPF record, or have that service publish a DKIM key for you. If you do not recognise it, somebody is using your name — and as long as your own mail does verify there is nothing you have to do about it, because receivers can tell the difference.

2. MTA-STS: mail must arrive over a secure connection

By default, encryption in e-mail is optional. If it fails, the sending server delivers the mail unencrypted anyway. MTA-STS is your domain saying: no — if you cannot verify me, do not deliver.

There are three modes:

New domains start in testing. That is a deliberate choice: enforce means mail that fails really does not arrive, and you want to turn that on only after you have seen that nothing is failing. Look at TLS problems on the same tab for that: those are exactly the connections enforce would have refused. If that is zero for a few days running, you can promote.

The panel asks you to confirm, with the consequences listed. And withdrawing is not an undo: senders that already fetched the policy keep honouring it for up to a week. That is why withdrawing asks you to type the domain name.

3. DNSSEC: is the chain closed?

DNSSEC signs your DNS so nobody can forge answers along the way. It only works if the zone of your extension (.com, .nl) publishes a DS record for your domain. Only your registrar can put it there — not us, and not any hosting panel.

What we can do is check. The DNSSEC tab has a Check the chain button that asks the nameservers of your extension directly rather than an intermediate resolver:

• closed — everything matches, something really is validating.
• not closed yet — the zone is signed here but the extension carries no DS. This is a warning and not an error: every signed domain sits here for its first day. Underneath is exactly what to enter at your registrar.
• not signed — there is nothing to check.

If the extension carries a DS that belongs to no key here, that is urgent: validating providers refuse your domain outright. The screen says so plainly, in red.

The same thing from the command line

If you run a server yourself, corectl gives the same answers:

corectl mail security show test100.nl
corectl mail security reports --domain test100.nl --days 30
corectl dns dnssec check test100.nl

mail security for test100.nl

delivery      this node
zone          this node
reports       on
  aggregate   dmarc-reports@test100.nl
  tls         tls-reports@test100.nl
mail host     on (mail.test100.nl, in the certificate)
mta-sts       testing (id 20260811093000)
  policy      https://mta-sts.test100.nl/.well-known/mta-sts.txt

The mail host line is about mail.test100.nl: the name you type into your mail program. We publish it as an A/AAAA record pointing at this server and carry it on your domain's certificate, so an existing Outlook or phone setup keeps working. If that name points at another provider at your end, switch it off:

corectl mail hostname set test100.nl off

An address record rather than an alias, deliberately: mail.<domain> is a candidate for use as an MX target or a HELO name, and neither may be an alias. The panel has the same switch on the website's SSL page, beside the list of names the certificate covers — see SSL and certificates.

Promoting to enforce asks for a confirmation on the command line too:

corectl mail mtasts set test100.nl enforce --confirm

When there is a mail gateway in front of your server

On some servers mail arrives first at a separate machine — a mail gateway — which checks it and then passes it on. That changes two things on this page, and both automatically:

• Your domain's MX points at the gateway instead of at the mail server.
• The MTA-STS policy names that same gateway. It has to: a policy naming a different host than the MX makes senders refuse your mail. The panel keeps the two in step, so there is nothing for you to do.

If the gateway is more than one machine, all of them are listed — in your MX records and in the MTA-STS policy — because otherwise a sender that honours the policy refuses the mail your second machine accepts.

Checking for yourself that the two agree:

dig +short MX yourdomain.com
curl -s https://mta-sts.yourdomain.com/.well-known/mta-sts.txt | grep '^mx:'

10 pmg1.srvnl.nl.
20 pmg2.srvnl.nl.
mx: pmg1.srvnl.nl
mx: pmg2.srvnl.nl

This is per domain. If you have several domains and the gateway is on for only one of them, that is exactly what you see: that domain names the gateway, the others name the mail server itself.

What the gateway holds back is under E-mail → Quarantine — see Mail that is held back.

Frequently asked questions

I see no reports at all. Check first whether the _dmarc record is really there (the What you publish tab). If we host your DNS it is there automatically; if your zone lives elsewhere you have to enter the line there yourself — the panel gives you the exact text.

May I turn the report address off? Yes, with the switch on What you publish. The rua= part disappears from your DMARC record and no new reports arrive. What was already collected stays.

How long do you keep the reports? Half a year. That is longer than the delivery log (thirty days) because these are counts about your own mail, and the job they support — moving a domain from p=none to something stricter without losing legitimate mail — runs over months.

Why is there no button to sort DNSSEC out at my registrar? Because that button would be lying. The DS record belongs in the zone of the extension, and only your registrar may write there. We do verify it, and we show you exactly what to enter.

Which machine is this set on? The one that carries your account's mail role. On most platforms that is the same machine as your website, and there is nothing to notice. If your mail lives on a separate machine, every setting on this page — MTA-STS, the report address, the mail hostname — goes there and not to the web server. The DNSSEC check is the exception: it looks at your zone, so it goes to your nameserver. You do not have to choose any of this; the panel knows.

Since August 2026: MTA-STS takes care of itself

There is nothing to switch on any more: as soon as your domain receives mail here and its DNS lives here, the server writes the policy, publishes the DNS record and serves the policy page — on every server type, LiteSpeed included. You can always check:

dig +short _mta-sts.yourdomain.com TXT
curl -s https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

If it is not there yet on a freshly added domain: one corectl reconcile (or a moment's patience for the automatic one) puts it there.

When the server refuses to enforce

Switching MTA-STS to enforce, or withdrawing the policy, asks you first — and if the server then will not take it, that dialog stays open with the reason in it. It used to close, and the explanation landed on the page underneath, behind the dialog you had just dismissed without reading. What the screen shows is still what the server has: nothing is half applied.