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 DNS check after the ownership record is published (press "Check DNS 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:

  1. Open the domain's MTA-STS tab and enable hosting.
  2. Point mta-sts.<your domain> at the CNAME target shown on the tab (it contains your account token). Opening that 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.

Modes: none publishes a policy that asks nothing of senders (a safe way to test the plumbing), 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. 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.

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. The check runs daily, 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.
  • 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.

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.