DMARC Monitoring

Anyone can put your domain in the From field

Email was designed without a way to prove who sent a message. DMARC closes that gap, and its reports tell you who is sending as you, whether your own mail is authenticating properly, and what an enforcing policy would do — all from a single DNS record.

Start Free Trial Documentation →
What's at Stake

Your domain is a claim anyone can make.

Nothing in the mail protocol stops a sender writing your domain into the From field. SPF and DKIM give receiving servers a way to check that claim, but on their own they publish no policy and send back no information, so you never learn what receivers decided. Meanwhile the invoices, password resets and delivery notices your customers actually rely on are competing for trust with anything an attacker chooses to send in your name.

Impersonation

Fraud arrives wearing your brand

An invoice redirect or a credential-harvesting page is far more effective sent from your domain than from a lookalike. Without a published policy, receiving servers have no instruction about what to do with a message that fails authentication.

Invisible Failures

You can't see what receivers decided

SPF and DKIM are checked by the recipient's server, not by yours. Whether your mail passed, and what happened when it didn't, is information that stays on their side of the exchange unless you ask for it back.

Forgotten Senders

Legitimate mail comes from more places than you think

Marketing platforms, invoicing tools, ticketing systems, a supplier sending on your behalf — most organisations discover several sanctioned senders they had forgotten. Enforcing a policy without knowing about them is what makes teams nervous about enforcing at all.

What DMARC Monitoring Does

See who sends as you, before you enforce anything

Publish a DNS record and receiving servers start reporting back on the mail they saw claiming to be from your domain. Report URI turns those reports into something you can read.

Sender Visibility

Every source sending as your domain, named

Aggregate reports come from the receivers themselves — the large mailbox providers your customers actually use. You see which sources sent mail claiming your domain, how much, and whether it authenticated. That is how a forgotten invoicing platform and an outright impersonator both become visible, usually within a day of publishing the record.

Learn more about DMARC setup →
Enriched Reports

Not the raw XML nobody wants to read

DMARC reports arrive as compressed XML built for machines. We parse them, aggregate across receivers, and enrich the source addresses with our own data so an IP becomes an organisation you recognise. What arrives as an attachment you would never open becomes a page that answers the question you actually had.

Learn more about stopping fraudulent email →
Safe by Default

Start at p=none and change nothing

A policy of p=none asks receivers to report without altering how they treat your mail. Nothing is quarantined, nothing is rejected, and no message is at risk while you build a picture of your senders. You move to quarantine and then reject when the reports say your legitimate mail is authenticating cleanly — on your schedule, with evidence.

Learn more about email deliverability →
Get Started

Find out who's sending as you. Before you enforce.

One DNS record. No code. Reports usually start arriving within a day.

Start Free Trial Talk to our team →

30-day free trial  ·  One DNS record  ·  No code  ·  Cancel anytime

Detection

What a DMARC report actually tells you

Aggregate reports answer a specific set of questions about mail claiming your domain. Knowing which questions they answer — and which they deliberately do not — is what makes them useful.

Reported What it tells you
Source IP and volume Who sent mail as your domain, and how much of it
SPF result Whether the sending server was authorised by your SPF record
DKIM result Whether the message carried a valid signature for your domain
Alignment Whether the authenticated domain matches the one your recipients see
Disposition What the receiving server did with the message under your policy
Message content Never — we support aggregate reports only, deliberately

We accept aggregate (rua) reports and not failure (ruf) reports, because failure reports can contain samples of the message itself — data we would rather not hold on your behalf.

Architecture

One DNS record. No code. No change to your mail flow.

DMARC is a published policy, not a service in your path. Your mail continues to leave your own infrastructure exactly as it does today; the only thing that changes is that receiving servers know where to send their reports. Nothing of ours touches a message.

You need SPF and DKIM in place first. With those set up, a single TXT record starts the reporting, and the first data usually arrives within a day.

Minimal setup — observe only, nothing enforced
v=DMARC1; p=none;
  rua=mailto:your-id@dmarc.report-uri.com

Your unique reporting address is on your Setup page once you have an account. Tighten p= to quarantine and then reject when the reports show your own mail authenticating cleanly.

No code added anywhere

Your mail is never routed through us

p=none observes without affecting delivery

We never receive the content of your messages

Reports come from the receivers your customers actually use

Email Security

DMARC is one of three records working together

SPF declares which servers may send for your domain. DKIM signs your messages so a receiver can verify they were not altered. DMARC ties both to the domain your recipients actually see, publishes what you want done when the checks fail, and asks for a report either way. The first two are prerequisites; the third is what turns them into something you can observe and enforce.

Transport security between mail servers is a separate matter again, reported through SMTP TLS.

SMTP TLS Reports →
Scope

One layer in the stack. Here's how it fits.

DMARC governs whether a message may claim your domain. It does not inspect content, it does not filter your inbound mail, and it does not secure the connection between mail servers — it is the domain authentication layer, and it works alongside the rest.

DMARC does Pairs with
Reports who sends as your domain Fraudulent Emails for the impersonation case in full
Shows whether your own mail authenticates Email Deliverability for reaching the inbox reliably
Publishes what receivers should do on failure SMTP TLS Reports for transport security between servers
Turns SPF and DKIM into something observable Certificate Transparency for certificates issued in your name

Together, these cover the ways your organisation's identity can be claimed by somebody else — in mail, in transport, and in certificates.