21 June 2026 · 3 min read
No. DMARC Engine does not read, receive, store or have any access to the contents of your actual emails. The way email authentication works, it never needs to. DMARC, SPF and DKIM all operate on your domain's DNS records and on metadata about how messages were authenticated, not on the messages themselves. We publish and manage DNS records on your behalf (your SPF policy, your DKIM keys, your DMARC, MTA-STS and BIMI records) and we process the aggregate reports that receiving mail servers send back. At no point does your normal mail flow pass through us, and we are not in the delivery path for the email you send or receive.
It helps to understand what an aggregate (RUA) report actually contains, because that is the only email-related data we handle. When a domain such as Google, Microsoft or Yahoo receives a message claiming to be from your domain, it checks SPF and DKIM, applies your DMARC policy, and then once a day sends you a summary in XML. That summary is statistical: it lists sending IP addresses, the volume of messages seen from each, the envelope and header domains, and the pass or fail results for SPF, DKIM and DMARC alignment. That is it. An aggregate report tells us "200 messages claiming to be from your-domain.com came from IP 203.0.113.10 yesterday, and 198 passed DKIM." It does not, and cannot, tell us who the email was sent to, what the subject line was, what the body said, who the real sender was, or whether the message was legitimate marketing or a phishing attempt. The DMARC standard deliberately excludes all of that from aggregate reports.
There is a separate, optional report type called a forensic or failure (RUF) report, and this is the one people worry about because it can include redacted message headers and sometimes a portion of a failing message. To be clear about our position: aggregate reporting is what drives the platform and what we rely on to move you safely from p=none to p=reject. We do not require RUF reports to do our job, very few large mailbox providers send them anyway (Google and Microsoft do not), and where they exist they are heavily redacted by the reporter, not by us. If your plan or configuration involves any failure reporting, we treat those headers as sensitive and you remain in control of whether they are collected at all.
To summarise what we do and do not touch:
- We manage: your DNS records for DMARC, SPF, DKIM, MTA-STS and BIMI, and the per-domain settings in your dashboard at app.dmarcengine.com.
- We process: aggregate (RUA) XML reports, which contain sending IPs, message counts and authentication pass/fail results only.
- We never see: message bodies, subject lines, recipients, attachments or your mailbox contents, because none of that is ever sent to us.
- We are not: an inbound or outbound mail server, a relay, or a proxy in your email path.
If you want to verify any of this for yourself before trusting us with a domain, every check we run is also available as a free, no-login diagnostic. You can inspect exactly what is published in your DNS using the DMARC checker, the SPF checker and the DKIM checker, and you can paste a real aggregate report into the DMARC report analyzer to see precisely what one contains. For more on how reporting and alignment work end to end, see the glossary and requirements pages. The short version: your email content stays between you and your mailbox provider, and we only ever work with DNS and the anonymous, aggregated authentication metadata that keeps spoofers out of your domain.