Fraudulent Email Protection

The most convincing phishing email comes from your domain

Nothing in the mail protocol stops somebody writing your domain into the From field. Your customers cannot tell, and neither can your staff. DMARC is how you instruct receiving servers to refuse it — and how you find out who has been trying.

Start Free Trial Documentation →

What's at Stake

Every security awareness lesson tells people to check the sender.

We have spent years teaching customers and staff to look at who an email is from. That advice is sound right up to the point where an attacker simply writes your domain in the From field, which the protocol has always permitted. At that moment the check everybody was trained to perform returns the reassuring answer, and the request to change bank details or approve an urgent payment arrives with your organisation's name on it. Business email compromise remains among the most financially damaging categories of online crime the FBI tracks, and this is the mechanism it runs on.

Trusted by Design

The From field is a claim, not a fact

Mail was specified without sender verification. Anyone can assert your domain, and unless you have published a policy saying otherwise, a receiving server has no instruction about what to do when that assertion fails a check.

Aimed at People

The target may be your staff, not your customers

Impersonating a colleague to authorise a payment or release information is often more valuable than impersonating your brand to customers. Internal mail carries an assumption of legitimacy that an external address never gets.

Damage You Absorb

Your reputation pays for their fraud

Recipients who are deceived by mail bearing your name attribute the experience to you. The reputational cost, the support burden and the effect on your own deliverability all land on your side of the exchange.

How We Help

Publish a policy, then enforce it

DMARC lets you tell every receiving server in the world what to do with mail that claims your domain and fails authentication. Reporting is how you get there safely, by proving your own mail passes before anything starts being refused.

See the Impersonation

Who is sending as you, and how much

Aggregate reports come from the mailbox providers your recipients use, and they include the traffic you did not send. A source with volume and no authentication, from infrastructure you do not recognise, is somebody using your domain — and until reporting is enabled, that activity is entirely invisible to you.

Learn more about DMARC Monitoring →

Then Refuse It

You decide what happens to mail that fails

A policy of quarantine asks receivers to treat failing mail as suspect; reject asks them to refuse it outright, so it never reaches the recipient at all. That instruction is honoured by the large providers, which means the protection reaches your customers without any of them installing anything.

Learn more about email deliverability →

Safe Progression

Enforce only once your own mail is clean

The reason to start at p=none is not caution for its own sake. Enforcement applies to every source claiming your domain, including the invoicing tool and the ticketing system nobody remembered. Reporting first identifies those, so that when you do enforce, the only mail being refused is mail you did not send.

Learn more about SMTP TLS Reports →

Get Started

Stop others sending as you. And see who was.

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 DMARC stops, and what it doesn't

DMARC is decisive about one specific form of impersonation and silent about others. Being clear on the boundary is what stops it being relied on for something it was never designed to do.

Technique	Does DMARC address it?
Mail sent using your exact domain	Yes — this is precisely what an enforcing policy refuses
Subdomains of your domain	Yes — policy can cover them, and should
A lookalike domain	No — it is someone else's domain, and their policy governs it
Display-name spoofing	No — the visible name is not what DMARC authenticates
A compromised account of your own	No — that mail is genuinely yours and will authenticate
Reporting on attempts	Yes — volumes and sources, whether or not you enforce

Lookalike domains are worth watching separately: they need certificates, and certificates are published, so Certificate Transparency monitoring will often surface one while it is still being prepared.

Architecture

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

DMARC is a policy you publish, not a service in your path. Your mail continues to leave your own infrastructure exactly as it does today, and the protection is applied by the receiving servers rather than by anything of ours. We never see the content of a message.

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

Minimal setup — observe only, nothing refused

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. Move p= to quarantine and then reject when the reports show every legitimate sender authenticating.

No code added anywhere

Your mail is never routed through us

Protection reaches recipients without them installing anything

We never receive the content of your messages

p=none observes without affecting any delivery

Beyond Your Domain

When they can't use your name, they use one that looks like it

Enforcing DMARC does not end impersonation, it redirects it. Attackers who can no longer send as your exact domain register something close to it instead. That infrastructure is not covered by your policy, because it belongs to them — but it does need a certificate, and certificates are published to public logs the moment they are issued.

Monitoring names adjacent to your own is how that preparation becomes visible, frequently before the first message is sent.

Certificate Transparency →

Scope

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

This covers others sending as your domain. It does not filter mail you receive, and it does not help with an account of your own that has been compromised — it is the domain authentication layer, and it works alongside the rest.

Covers	Using
Refusing mail that claims your domain	DMARC Monitoring for policy and reporting
Lookalike domains being prepared	Certificate Transparency for issuance visibility
Your own mail reaching the inbox	Email Deliverability for sending reputation
Encryption between mail servers	SMTP TLS Reports for transport security

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