Email Deliverability

Sent is not the same as delivered

Your mail server records that a message left. Whether it reached an inbox, landed in spam, or was refused outright is decided by the receiver — and they will tell you, if you ask. DMARC reporting is how you ask, and it takes one DNS record.

Start Free Trial Documentation →

What's at Stake

The decision is made on somebody else's server, using rules you can satisfy.

Whether your message reaches an inbox is judged by the receiving provider, on evidence you supply: does this sender have permission to use this domain, is the message signed, and does the signed domain match the one the recipient will see. Get those wrong and your mail competes for trust with everything else claiming your name. The costly part is that failing these checks does not bounce — it quietly reduces the odds, on the messages that matter most.

Silent Downgrade

Failing authentication doesn't produce an error

A message that fails SPF or DKIM is rarely rejected outright. It is weighted, filtered, or placed in spam. Nothing returns to your servers to say so, so the sending side sees a clean send and the recipient sees nothing at all.

Transactional Mail

The messages that matter are the ones people wait for

Password resets, order confirmations, invoices and one-time codes. These are not marketing sends with a measurable open rate — they are messages whose failure surfaces as a support ticket, an abandoned checkout, or a customer who cannot log in.

Forgotten Senders

Your domain is used by more systems than you think

A ticketing platform, an invoicing tool, a supplier sending on your behalf. Each needs to be authorised or its mail is treated as suspect, and most organisations only discover the full list when the reports arrive.

How We Help

Ask the receivers what happened to your mail

DMARC turns the receiving side's decisions into a report you can read. That tells you which of your senders are authenticating cleanly, which are not, and what to fix before deliverability is affected.

Authentication Results

Whether your own mail is passing the checks

Aggregate reports come from the large mailbox providers your recipients actually use, and say plainly whether each sending source passed SPF, passed DKIM, and aligned with the domain shown to the reader. A source failing quietly for months becomes an obvious line in a table.

Learn more about DMARC Monitoring →

Actionable Findings

Reports that name the record to change

Raw DMARC data arrives as compressed XML written for machines. We parse it, aggregate across receivers, and enrich the source addresses so an IP reads as an organisation you recognise. What you are left with is a short list of senders and, for each, whether the fix belongs in your SPF record, your DKIM setup, or a conversation with a supplier.

Learn more about stopping impersonation →

Transport Encryption

And whether the connection carrying it was secure

Authentication decides whether a message is trusted; transport decides whether it was protected on the way. SMTP TLS reporting tells you how often delivery to your recipients was properly encrypted and validated, and MTA-STS lets you require it. Both matter to how your domain is regarded.

Learn more about SMTP TLS Reports →

Get Started

Find out what receivers do with your mail. Then fix it.

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

The records that decide your deliverability

Four DNS records do most of the work. Knowing what each asserts makes the reports straightforward to read.

Record	What it asserts
SPF	Which servers are permitted to send mail for your domain
DKIM	A signature proving the message was not altered in transit
DMARC	What receivers should do on failure, and where to send reports
Alignment	That the authenticated domain matches the one your reader sees
MTA-STS	That delivery must use a validated encrypted connection
TLS-RPT	Feedback on how often that encryption succeeded

SPF and DKIM are prerequisites rather than optional extras — DMARC reports on them, so they need to exist before the reporting means anything.

Architecture

DNS records. No code. No change to your mail flow.

None of this puts anything in the path of your mail. Your messages continue to leave your own infrastructure exactly as they do today — the only change is that receiving servers know where to send their reports. We never see the content of a message.

Start at p=none and nothing about delivery changes. One TXT record begins 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. Move to quarantine and then reject when the reports show your legitimate senders 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 providers your recipients actually use

Reputation

Deliverability and impersonation are the same problem

A domain with no published policy is one that anybody can send as. That harms you twice: fraudulent mail reaches your customers wearing your name, and the resulting reputation damage lands on the messages you actually sent. Publishing a policy and enforcing it improves both at once, which is why the same DNS record answers both problems.

The sequence is the same either way — observe first, then enforce once the reports show your own mail is clean.

Fraudulent Emails →

Scope

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

This covers whether your mail is trusted and protected on the way. It does not write your content, and it has no bearing on mail you receive — it is the sending reputation layer, and it works alongside the rest.

Covers	Using
Whether your senders authenticate	DMARC Monitoring for aggregate reporting
Whether delivery was encrypted	SMTP TLS Reports for transport security
Others sending as your domain	Fraudulent Emails for the impersonation case
Certificates issued in your name	Certificate Transparency for issuance visibility

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