GoCloudConsulting Email Reports

Setup guide

Step-by-step DNS and Cloudflare configuration for onboarding a domain — what this dashboard does for you versus what you still have to do by hand. Type a domain below to see live examples throughout.

1. Add the domain to the dashboard

On the Domains page, use Add domain. This registers it for live email ingestion and daily DNS checks — it does not touch DNS itself. The three records below are what it tells you to publish; this page explains why each one is needed.

2. DMARC

Publish (or update) the domain's own _dmarc TXT record with this tool's rua/ruf addresses added. This example is a DMARCbis-aligned, enforcement-ready record — see the p/ sp/np notes below if the domain is still in monitoring mode and not ready for that yet:

p=reject

Enforcement policy for the organizational domain — reject messages that fail DMARC. This tool has no opinion on which value to use; move to quarantine/reject once the aggregate reports show DMARC passing reliably, not before. Use p=none instead while still monitoring.

sp=reject

The same enforcement, applied to subdomains that don't publish their own DMARC record. Defaults to the p value if omitted — spelled out explicitly here.

np=reject

DMARCbis addition — enforcement specifically for subdomains that don't exist (NXDOMAIN). Ambiguous under the original RFC 7489; DMARCbis makes it an explicit, separately-settable tag rather than folding it into sp.

psd=n

DMARCbis addition — declares this domain is not itself a public suffix (a registry-style domain operated on behalf of many unrelated third parties, e.g. a TLD). Only relevant to organizations that manage a public suffix; n is correct for an ordinary domain.

adkim=s

DKIM identifier alignment. s (strict) requires the DKIM d= domain to exactly match the visible From domain; the default, r (relaxed), only requires matching organizational domains.

aspf=r

SPF identifier alignment. r (relaxed, the default) accepts a matching organizational domain between the From address and the SPF-authenticated domain; s (strict) requires an exact match.

fo=1

Needed for ruf reports to actually be useful. The default (fo=0) only generates a forensic report when the message fails DMARC outright (both SPF and DKIM misaligned). fo=1 generates one whenever either underlying mechanism fails to produce an aligned pass — even if the message still passes DMARC overall via the other mechanism — which is what actually surfaces problems like a legitimate sender's SPF record briefly missing an IP. Without fo=1, expect very few or no forensic reports even with ruf configured.

rua=

Aggregate reports — the main data source for the DMARC dashboard. Accepts a comma-separated list of mailto: destinations if you ever want to add another recipient; every listed recipient gets a copy of each report.

ruf=

Forensic (per-message failure) reports. Optional — most large mailbox providers stopped sending these for privacy reasons, but the senders that do give near-real-time spoofing evidence, so it's worth keeping.

3. TLS-RPT

Publish this TXT record on the domain to subscribe it to SMTP TLS reporting — independent of whether you self-host MTA-STS below; a domain can have this without MTA-STS, or MTA-STS without this.

4. MTA-STS self-hosting (optional, per domain)

Adding the domain in step 1 is not the same as this — MTA-STS hosting is a separate opt-in step on the MTA-STS page. It hosts the policy file that tells senders to enforce TLS to this domain's mail servers, and removes that file's cert-expiry risk entirely (Cloudflare manages the certificate, auto-renewed).

1. Save a policy on the MTA-STS page — mode, MX hosts (use "Look up current MX" to pull the real records rather than guessing), and max age. This only writes to this project's own database; the next three steps are still needed before it does anything.
2. Add a Cloudflare Worker route for pointing at this Worker. The domain's zone must be on the same Cloudflare account as this deployment — this doesn't work across accounts. Either add a line to wrangler.toml's routes and redeploy:
   or, faster and no redeploy needed, via the Cloudflare dashboard either of two ways: Workers & Pages → this Worker → Domains → Add route; or Domains → the domain itself → Worker Routes → Add route.
3. Create the DNS record — this is the part most likely to be set up wrong.
   What it should point to: it doesn't matter, as long as it's Proxied. Add an A record for with any value (192.0.2.1 is a fine placeholder) — the content is never actually used, because the Worker route from step 2 intercepts the request at Cloudflare's edge before any origin is ever contacted.
   
   What does matter: the record's proxy status must be Proxied (orange cloud), not DNS only (grey cloud). A grey-clouded record bypasses Workers entirely — Cloudflare resolves it as plain DNS, the Worker route never runs, and mail senders trying to fetch the policy get a connection failure instead of your policy file. This is the single most common way this setup breaks.
   Subdomain policies need an extra certificate. Universal SSL only covers the zone apex plus one label (*.example.com). If the mail domain is itself a subdomain — say reports.example.com — its policy host mta-sts.reports.example.com is two labels deep, no certificate covers it, and HTTPS fails at the TLS handshake (not a 404 — the connection itself is rejected). Cloudflare's error for this, if you check SSL/TLS → Edge Certificates on that zone, is "This hostname is not covered by a certificate." Fix, on that zone: enable Total TLS (SSL/TLS → Edge Certificates → Total TLS — auto-issues a certificate for every currently-uncovered proxied hostname on the zone, so it fixes this one and any future one in a single action) or order an Advanced Certificate covering just this specific hostname; both need the Advanced Certificate Manager subscription on that zone.
4. Verify before publishing the DNS authorization record — confirm the policy file is actually being served:
   Should return the policy text saved in step 1. A 404 means the Worker route or the DNS record's proxy status (step 2 or 3) isn't right yet; an SSL/TLS handshake error means the certificate-depth problem above — recheck those before continuing.
5. Publish the TXT record — the exact value is shown after saving the policy in step 1 (v=STSv1; id=<policy_id>). Publishing this last, only once step 4 confirms the file is reachable, avoids senders discovering the record while the endpoint still 404s. The id changes every time the policy is re-saved — senders cache by it and only re-fetch the file when it changes, so an edit here always needs a matching DNS update.

Version history