DomainVouch
DMARC, SPF, DKIM, MTA-STS, TLS-RPT

Anyone can send mail as your domain. Until you stop them.

Anyone can check whether you have done this - and almost nobody has finished it. We exist to get it finished, and to show you the evidence at every step rather than asking you to take our word for it.

1 domain, no card required. £50 a month after that, 5 domains included.

Reports within a day of one DNS record No agent, no mail routed through us Every change signed into an audit log
dmarc.example.com/t/acme
Messages
1,005,000
312 reports
DMARC pass
98.7%
991,800 messages
DMARC fail
1.3%
13,200 messages
Sources
47
3 unrecognised
Source IPMessagesPassAlignment
209.85.220.41 572,850 100.0% DKIM + SPF
40.107.243.72 281,400 99.9% DKIM + SPF
198.51.100.24 132,660 99.4% SPF only
203.0.113.88 13,200 0.0% neither
Pass and fail volume by day, and every IP sending as your domains, ranked by volume.
In plain English

What is DMARC, and why does anyone need it?

No jargon in this section. If you have been sent here by an insurer, an IT supplier or a customer's security questionnaire, start at the top.

Anyone can put your name on an email

Email was designed in a more trusting age. The "from" line is simply typed by whoever sends the message, like the return address on an envelope - and nothing checks it. A criminal can send an invoice that appears to come from your finance team, and it will look genuine to the person who receives it.

Other people pay for it

The messages go to your customers, your suppliers and your own staff: a change of bank details, an urgent request from the boss, a delivery that needs a small fee. The loss lands on someone who trusted your name, and the first you hear of it is usually the phone call afterwards.

DMARC is how you stop it

You publish a few short lines in your domain's DNS - the same place your website address lives. They tell every mail server in the world who is allowed to send email as you, and what to do with anything else: let it through, put it in spam, or reject it outright.

What the letters actually mean

SPF - the guest list

A published list of the servers allowed to send email using your domain: your own mail system, your newsletter tool, your invoicing software. Anything not on the list is a stranger at the door.

DKIM - the wax seal

An invisible signature added to every message you send. A receiving server checks it to confirm the message really came from you and was not altered on the way. A forger cannot copy it, because they do not have your key.

DMARC - the door policy, and the visitor book

The instruction that ties the two together: check the seal and the guest list, here is what to do when a message fails both - and send me a daily report of everything sent in my name. That report is where the evidence comes from.

MTA-STS and TLS-RPT - the armoured van

The three above are about mail leaving your domain. These two are about mail arriving at it: they require the delivery to be encrypted in transit, and tell you when a delivery could not be.

So why has nobody finished it?

Two reasons, and neither is laziness. The daily reports arrive as thousands of XML files that no human can read. And turning the policy up without knowing who sends on your behalf is how a company blocks its own invoices, payslips or newsletters - so most people publish the record, see the wall of XML, and stop at the safe setting that changes nothing.

That gap is the product

We read the reports for you and turn them into a plain list of who is sending as your domain, how much, and whether it passes. When the evidence says tightening the policy is safe, we say so - and show you exactly what it would have stopped last month before you change anything.

You probably need this if

Nothing here needs your mail to pass through us, and nothing needs software installed. You publish one line in DNS and the reports start arriving.

Why we exist

Why this exists

Not everything worth doing needs a specialist. Stopping people forging your email has stayed the preserve of a small number of experts, and the result is that the organisations most likely to be impersonated are the least likely to be protected.

Why

We believe a domain should not be easy to impersonate

Spoofing your domain costs an attacker nothing and costs your customers their trust. The controls that stop it have existed for a decade. What has been missing is a way to run them without a specialist on staff.

How

By replacing judgement calls with evidence

Every change we suggest comes from what your own mail is actually doing this week. We refuse anything that would stop your mail arriving, we show you what a change would have blocked last month before you make it, and afterwards we check that what is published is still what you agreed to.

What

DMARC, SPF, DKIM, MTA-STS and TLS-RPT in one place

Everything that proves your mail is yours, everything that keeps mail to you encrypted, and a record of every change that cannot be quietly edited - priced so an organisation with five domains can afford the lot.

How it works

Three steps to start

Publishing one DNS record starts the reports flowing within a day.

Publish a record

We give you a reporting address unique to your tenant. Put it in your DMARC record and receivers start sending reports.

Find your senders

Every source is identified with its volume, alignment and disposition, so you can tell your own mail from everyone else's.

Move to enforcement

Fix alignment for the senders that matter, then tighten the policy knowing exactly what it will stop.

example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-acme-k7m2p9x4@reports.example.com; fo=1"
What you get

Every service, and why it is here

Six services covering the whole of email authentication. Two are included in every plan; the other four are the single add-on below, switched on per domain.

DMARC aggregate reporting

Included
Why
You cannot defend a domain you cannot see. Most organisations have no idea how many systems send as them until something goes wrong.
How
You get your own reporting address, so the reports come straight to you and are never mixed with anybody else. We turn them into a list of who sent what, which checks passed, and what the receiver did about it - instead of a folder full of unreadable files.
What
How much mail, day by day. Who sent it and whether it passed. Which of your senders are failing, and a spreadsheet of any of it.

Failure (forensic) reports

Included
Why
A daily summary tells you something failed. It does not tell you which message - so a service of yours that is simply set up wrong looks exactly like somebody pretending to be you.
How
Each copy is encrypted on its own and tied to the organisation it belongs to, and reading the message itself takes a stronger permission than seeing that it exists.
What
The detail of individual failures, kept only as long as you say.

SPF flattening

Add-on
Why
The record that lists who may send as you is allowed ten lookups, and no more. Four email services is usually enough to go over - and once you do, receivers ignore the record entirely.
How
We do the lookups in advance and write the answers into the record - only the parts that could ever let mail through, so the shorter record permits exactly what the long one did and nothing more.
What
A record that costs a receiver nothing to check, rebuilt when a provider changes its addresses, always shown next to the one it replaces.

DKIM key management

Add-on
Why
Signing keys get published once and then forgotten. Keys that are too small, keys still in test mode, and keys somebody quietly deleted all go unnoticed until mail starts failing.
How
We check what is actually published, continuously, and any key we generate is encrypted on its own so it can only ever be read inside your own organisation.
What
Watching for changes, warnings when a key is too weak, and new keys with the exact record to publish.

MTA-STS policy hosting

Add-on
Why
Mail arriving at your domain is not always encrypted, and an attacker in the middle can quietly turn the encryption off. The fix is well understood and almost nobody uses it, because it means hosting a file on a subdomain with its own certificate.
How
We host the file. You publish one DNS record, and the certificate is issued and renewed for you. Anything that would stop mail reaching one of your live mail servers is refused rather than published, and a new version is not served to anybody until your DNS confirms it.
What
An editor that checks your real mail servers before it lets you save, every past version kept, and a daily check that what is live is still what you approved.

TLS-RPT reporting

Add-on
Why
When encryption fails between two mail servers, the message is either sent unprotected or bounced - and neither end mentions it to anybody.
How
We accept these reports however they are sent, drop the duplicates, and tie every failure to the policy that was live at the time.
What
How much mail to you was encrypted, over time, what went wrong when it was not, and which of your policies was live when it happened.
In practice

SPF flattening and DKIM in practice

dmarc.example.com/t/acme/authdns

acme.example managed 13 / 10 lookups flattened to 0

Before: five includes, three of them nested. After: 34 address ranges, no lookups.

v=spf1 ip4:209.85.128.0/17 ip4:40.107.0.0/16
  ip4:198.51.100.0/24 ip6:2a01:111:f400::/48 ~all
SelectorKeyStatus
googlersa 2048active
selector1rsa 2048active
legacyrsa 1024rotate
SPF flattening keeps you under the ten-lookup limit, and regenerates when a provider changes its addresses.

Flattening that stays correct

Includes are resolved and published as addresses, so the record costs nothing to evaluate. Only mechanisms that could actually produce a pass are inlined, so the flattened record authorises exactly what the original did.

Regenerated when providers move

Upstream address ranges change without warning. We re-resolve on a schedule and tell you when a new revision is ready, with a diff against the last one.

A policy that will not break your mail

MTA-STS at enforce mode can stop delivery outright. We check your live MX records before publishing and refuse a policy that would leave one uncovered, then hold the new version back until your DNS confirms it.

Optional extras

The add-ons

Two add-ons, both optional, both described the same way as everything else: the problem first, then the approach, then what you get.

Sender authentication and transport security

£25 a month
Why
Reporting tells you what is broken. It does not fix it. The work that follows a DMARC rollout is nearly all SPF, DKIM and transport, and it is the part that most often stalls.
How
One add-on rather than four, because splitting them would only mean charging for the half of the job that does not work on its own. Each domain is switched on individually, so you can pilot on one brand before committing.
What
SPF flattening with scheduled regeneration, DKIM selector monitoring and key generation, hosted MTA-STS policies with version history, TLS-RPT ingestion and dashboards, and a daily health check across all of it.

Additional domains

£8 per domain per month
Why
Domains you do not send from are the ones attackers prefer, because nobody is watching them. Parked and legacy names deserve a policy too, and per-domain pricing should not make that a difficult conversation internally.
How
Five domains are included before any add-on, and additional ones are charged singly rather than in tiers, so you never pay for a bracket you are not using.
What
One more domain, with the same reporting, the same retention controls and the same add-on eligibility as the domains already on your plan.
Security

Built to be audited

You are handing us reports about your mail. The controls below are the ones we would want to see in your position.

dmarc.example.com/t/acme/audit

History checked - all 8,412 entries intact.

SeqActorActionOutcome
8412ops@acme.examplereport.exportsuccess
8411ops@acme.examplemember.role_changesuccess
8410systemingest.parse.successsuccess
8409unknown@evil.testauth.login.failurefailure
Every action is written down and locked to the one before it. The database itself refuses to change or delete any of it.
No passwords, for anybody There is no password to steal, guess or reuse. Everyone signs in with a passkey - a fingerprint, a face or a device PIN - and a second step is required of every account, not only administrators. You can use your own work sign-in instead.
Your data is only ever yours Every single question we ask the database is stamped with which organisation is asking, in one place that cannot be bypassed. Our tests prove one customer cannot read another one's data even when handed the exact record numbers.
A history nobody can rewrite Every action is written down, and each entry is locked to the one before it. The database itself refuses to change or delete them - not merely our code.
Encrypted where it matters Copies of failed messages and your signing keys are each encrypted separately, and tied to the organisation they belong to.
Your data, your retention You choose how long we keep each kind of data. A job runs nightly, deletes what is past it, and writes down what it deleted.
We never see your card Payment happens on Stripe's own pages. All we keep is a reference number.

If your auditor asks: every control is mapped to the NIST frameworks in a published matrix, and each is marked done, partly done or planned - honestly.

Pricing

One plan, two add-ons, no sales call

Everything in the standard plan is included from the first day of the trial.

Trial

Free

14 days

  • 1 domain
  • Full DMARC aggregate reporting
  • Failure reports and dashboards
  • No card required
  • SPF and DKIM management
Start trial
Best value

£500

per tenant, per year

  • Everything in monthly
  • 5 domains included
  • Save £100 against monthly
Choose annual

Add-ons: Additional domains from £8 per domain per month; Sender authentication and transport security £25 per month. Full pricing.

FAQ

Questions

How long before I see data?

Most receivers send aggregate reports once a day, so the first data usually arrives within 24 to 48 hours of publishing the record.

Will this break my mail?

Not on its own. Start at p=none, which only asks for reports and changes nothing about delivery. You decide when to tighten it, and the dashboard shows what each step would have stopped.

Is MTA-STS risky?

At enforce it can stop mail being delivered to you, which is why we validate a policy against your live MX records and refuse to publish one that would leave a server uncovered. New versions are also held back until your _mta-sts TXT record confirms them, so senders never hold a policy we are no longer serving.

What happens when the trial ends?

Report collection stops and your data stays under your retention policy. Pick a plan and it resumes; nothing is deleted early.

Do you need access to our DNS?

No. We generate the records and tell you exactly what to publish, then check whether what is live matches. Your DNS stays yours. Hosted MTA-STS needs one CNAME from you and nothing more.

Can we use our own identity provider?

Yes. Any OpenID Connect provider can be configured per tenant, with optional just-in-time provisioning and the ability to require SSO for all members.

Start with one domain

14 days, no card. See who is sending as your domain before you decide anything.

One DNS record to begin. Nothing is routed through us and no agent is installed.