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 → Mail security. The domain is chosen at the top of the page; every domain publishes its own rules.

Screenshot — Panel → Accounts → your account → Mail 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
mta-sts       testing (id 20260811093000)
  policy      https://mta-sts.test100.nl/.well-known/mta-sts.txt

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

corectl mail mtasts set test100.nl enforce --confirm

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.