Help

What are these reports?

DMARC aggregate reports are XML files that mail receivers such as Google, Microsoft and Yahoo send once a day to the address named in a domain's DMARC record. They list every server that sent mail claiming to be from your domain, how many messages it sent, and whether SPF and DKIM aligned with the domain. They are the only way to learn who is sending as you.

TLS-RPT reports (RFC 8460) are JSON files that sending servers publish once a day about their attempts to deliver to your mail servers over TLS. They tell you when STARTTLS or your certificates break, which you otherwise only notice when mail silently stops arriving.

RUA Reports receives both, stores the raw files, and turns them into the dashboards you see here. The name comes from rua=, the tag both record types use to say where reports should go.

Getting started

  1. Create an account and verify your email address.
  2. Add a domain under Domains, or import a whole list at once.
  3. Publish the DNS records the setup tab shows (or export them all as a CSV from the domains page). The first one proves you own the domain; the others contain your account's report address. Copy them from the page rather than from this text.
  4. Wait. The domain unlocks at the next check after the ownership record is published (press "Check now" to hurry it). Most receivers send one report per day, so the first data appears within 24 hours. Until then the domain shows "no reports yet".

Proving you own a domain

Every domain you add starts locked: reports for it are not processed and its hosted MTA-STS policy is not served until we find a TXT record at _ruareports.<your domain> with the value the setup tab shows (ruareports-verify=...). The value is the same for every domain of your account, so a list of domains needs the same record at each of them. Reports that arrive while a domain is locked are kept for about a week and processed once the record is found. Once seen, the record can stay in place; removing it later does not lock the domain again.

The DMARC record

The record lives at _dmarc.<your domain> as a TXT record. A minimal one looks like this:

v=DMARC1; p=none; rua=mailto:<your report address>
  • p is the policy receivers apply to mail that fails: none (observe only), quarantine (spam folder) or reject. Start with none, look at the reports, and only tighten once every legitimate sender passes.
  • sp is the policy for subdomains; it defaults to p.
  • pct applies the policy to a percentage of failing mail, useful for a gradual move to quarantine.
  • adkim and aspf choose strict (s) or relaxed (r) alignment. Relaxed is the default and is right for almost everyone.
  • rua is where aggregate reports go. You can list several addresses separated by commas, so an existing address can stay.
  • ruf asks for per-message failure reports. Few receivers send them and they may contain personal data; leave it out unless you need it.

You do not need any extra DNS record to send reports to us. When reports go to a different domain than the sending domain, receivers check a record on our side (<your domain>._report._dmarc.ruareports.com), and we publish a wildcard that answers for every domain.

The TLS-RPT record

The record lives at _smtp._tls.<your domain>:

v=TLSRPTv1; rua=mailto:<your report address>

TLS-RPT only reports on what other servers experience when delivering to you. It is most useful together with MTA-STS, which tells senders that your servers always offer TLS.

Hosted MTA-STS

MTA-STS (RFC 8461) needs an HTTPS host named mta-sts.<your domain> that serves a small policy file, plus a TXT record. RUA Reports can host the policy file for you. The domain's MTA-STS tab leads with a status card that tells you which of the three steps is done and what to do next:

  1. Turn hosting on and save a policy. Nothing is served and no certificate is requested until you do.
  2. Point mta-sts.<your domain> at the CNAME target shown on the tab. The target contains your account token, which is how we know the policy is yours to serve. Once the CNAME resolves we obtain the certificate and start serving the policy, usually within a minute. Opening the target in a browser shows a page confirming it is yours.
  3. Publish the _mta-sts.<your domain> TXT record with the policy id shown on the tab. This is the record that actually switches MTA-STS on for senders, so publish it last, once the status card says the policy file is live.

Until all three are done nothing changes for your mail: senders that find no TXT record simply deliver as before. A step that cannot work yet is shown as still to do, not as an error.

Modes: none publishes a policy that asks nothing of senders (a safe way to test the plumbing, and the way to retire a policy), testing asks senders to report failures through TLS-RPT but still deliver, enforce tells senders to refuse delivery when TLS or the certificate is wrong. Start with testing. Every change to the policy mints a new id; update the TXT record so senders fetch the new policy. Senders cache the policy for the max_age you chose, so keep it short while testing: it is also how long a mistake takes to disappear.

Turning hosting off does not withdraw a policy. Senders keep the copy they already fetched until it expires, while the address they fetch it from stops answering. To retire a policy safely, save mode none first, leave it in place for one full cache period, and only then turn hosting off and remove the two DNS records. We refuse to turn hosting off on an enforce policy without a confirmation for this reason.

You do not have to host it with us. The tab reports on whichever policy senders actually get. If the domain runs MTA-STS on its own host, we fetch that policy over HTTPS on every check and say what it contains and whether it holds up: whether the mx list covers every MX host we found for the domain, what the mode and cache time are, and whether the file is a valid policy at all. The gaps worth knowing about are named plainly: a _mta-sts record announcing a policy nothing serves, a policy host with no record telling senders to look at it, a policy that leaves one of your MX hosts out (mail from MTA-STS-aware senders stops for that host in enforce), and a domain where our hosting is on while the mta-sts name points somewhere else, so senders never get our policy at all.

The tab also shows every MX host of the domain with its certificate: validity dates, whether the chain is trusted, whether the name matches, and whether STARTTLS is offered. This runs whether or not you host a policy with us, daily and more often when a certificate is about to expire, and on demand with Check hosts now. Enable enforce only when every host is green; an expired certificate in enforce mode stops inbound mail from every MTA-STS-aware sender.

Reading the dashboard

  • DMARC pass means the message passed either aligned DKIM or aligned SPF. That is the number receivers act on.
  • SPF fails on forwarded mail by design: the forwarder's server is not in your SPF record. DKIM survives forwarding, which is why you need both.
  • Sources are the IP addresses that sent mail as your domain. A source you do not recognise with a high volume and failing authentication is someone spoofing you; a source you recognise with failing DKIM usually means a missing selector or an unsigned service.
  • Who a source is: each source address shows the email service behind it when we recognise it, otherwise the domain of its reverse DNS name or the network it belongs to, plus its country; the source page has the full details. A source whose mail passes is marked Authenticated; one that passes DKIM but fails SPF is marked Forwarder. The busiest failing sources are also classified from the report data as Needs setup (a service you use that is not signing for your domain yet), Forwarder or Likely spoofing. Treat those as hints, not findings.
  • Dispositions are what receivers did: none, quarantine or reject, following your policy.
  • Days are UTC days, because that is how reporters bucket them; other timestamps show in the time zone from your settings.

Data retention

We keep raw report files for about a week, per-message detail for about five weeks and daily statistics for about thirteen months. If the system runs out of space, older data is removed early, oldest first. Your account, domains and settings are never removed this way. See the Terms of Service.

Limits

Each account can process a set number of reports per calendar month; the dashboard shows the limit and how much of it is used. Duplicate reports, reports for domains you have not added and reports we could not read do not count. When the limit is reached, further reports are refused with a temporary error until the first day of the next month; reporters retry for a few days, so a limit raised soon after loses nothing. Write to us if you need a higher limit.

The domains page can export the DNS records of all or some of your domains as a CSV file, handy for handing to whoever manages your DNS.

AI connections

You can connect an AI assistant that speaks the Model Context Protocol (MCP), Claude for instance, to this account. Open AI connections in the menu, add https://ruareports.com/mcp as a connector in the client, and it sends you back here to sign in and approve it. You choose whether it may only read, or also make changes. There is no key to copy and nothing to paste, and the client never learns your password.

A connection can list your domains and their DNS setup and read your DMARC and TLS reports; with management access it can also add and remove domains, run DNS and MX checks and change hosted MTA-STS. It reaches your account and nothing else. Every connection is listed on that page with when it was last used, and disconnecting one stops it immediately.

Paired with a connector for your DNS provider, this is the short way to set a domain up: the assistant adds the domain here, reads the records it needs, publishes them in your DNS and then asks us to check them.

Account security

Enable two-factor authentication (TOTP) in the security settings, or add a passkey and sign in without a password at all. Keep the recovery codes somewhere safe; they are shown once. If you lose access, the administrator of this installation can reset the second factor for you.

Frequently asked questions

I already send reports to another address. Do I have to drop it? No. The rua tag takes several addresses separated by commas; keep the existing one and add ours. The setup tab shows the merged record when it finds one.

Nothing has arrived after a day. Check the setup tab: it shows what is actually published and whether the record points at your report address. A typo in the record, or a record published at the wrong name (_dmarc.example.org, not example.org), is the usual cause. Some receivers also skip domains that sent them no mail that day.

Why do reports say mail failed that I know is legitimate? Most often it is forwarded mail (SPF breaks, DKIM should still pass), a service that signs with a DKIM domain other than yours, or a service you never added to SPF. The Authentication tab lists the DKIM domains and selectors and the SPF domains seen, which usually names the culprit.

Can I download the original report? Yes, from the report's page, for as long as the raw file is kept (about a week). After that the parsed records stay for the detail retention period and the daily totals for longer.

Does the service send mail as my domain, or change my DNS? No. It only receives reports and, if you enable it, serves your MTA-STS policy file. Every DNS record is published by you.

Is it really free? Yes. RUA Reports is provided by the team behind EmailEngine, the self-hosted email API, as a service to the email community. Storage is bounded, which is why old data is pruned instead of kept forever.

Contact

Questions and problems: info@postalsys.com.