Products

Email authentication is one job, not six

DMARC, SPF, DKIM, MTA-STS, TLS-RPT and BIMI are usually treated as separate chores, scattered across a DNS panel, a mail-server config and three vendor dashboards. In reality they are one system with one purpose: proving that mail claiming to come from your domain genuinely did, and that nobody can forge your brand into a customer's inbox. Each record does part of the work, and each one depends on the others being correct. Get SPF wrong and DMARC fails. Skip DKIM and your mail breaks the moment it is forwarded. Reach p=reject without first reading your reports and you start bouncing your own invoices.

DMARC Engine hosts and manages the whole stack in one place, so the records stay consistent with each other and stay correct as your sending changes. You add a single delegation at your DNS provider once, and from that point the records are versioned, monitored and kept aligned for you. Below is what each piece does, what we automate, and why running them together is the difference between a dashboard nobody reads and a domain that can no longer be forged in your own name.

Hosted DMARC

DMARC is the policy layer that ties everything together. It is a TXT record at _dmarc.yourdomain.com that tells receiving servers what to do with mail that claims to be from your domain but cannot prove it, and it names an address where those servers send daily reports on every attempt, real and forged alike. Without DMARC, a scammer can type your address into the From line and nothing stops the message reaching your customers.

We publish and version the record, stage the policy from p=none through quarantine to reject using your live report data, ingest the aggregate (RUA) reports from every receiver, and combine them into one readable view across all your domains. The benefit is a controlled path to enforcement rather than a guess: you reach a policy that refuses forgeries without ever blocking your own legitimate mail. More on hosted DMARC.

Hosted SPF

SPF lists which servers are allowed to send mail using your domain in the envelope. It sounds simple, but RFC 7208 caps SPF evaluation at ten DNS lookups, and every include: for a service like Google Workspace, a CRM or a marketing platform eats into that limit and nests further. Cross ten lookups and SPF returns permerror, which means it fails outright, which means DMARC loses one of its two passing paths.

We flatten your SPF record automatically, resolving those nested includes down to the underlying IP ranges so the record stays safely under the limit, and we keep it updated when a provider changes its IPs. The benefit is an SPF record that does not silently break the day you add a sixth sender. More on hosted SPF.

Hosted DKIM

DKIM adds a cryptographic signature to every message and publishes the matching public key in DNS at selector._domainkey.yourdomain.com. Unlike SPF, a DKIM signature survives forwarding, which makes aligned DKIM the more reliable of the two routes to a passing DMARC result. The cost of that reliability is key management: generating keys, publishing selectors, and rotating them without an outage.

Your key pair is generated in your browser and the private key never leaves it; we host the public key, manage selectors, and remind you when a key is due to rotate, with overlapping selectors so a changeover never drops a passing signature. The benefit is signed, forward-proof mail that stays aligned with your From domain without anyone having to remember to rotate a key. More on hosted DKIM.

MTA-STS and TLS-RPT

SPF, DKIM and DMARC protect the From address. MTA-STS protects the connection. It forces inbound mail to your domain to use TLS, closing off downgrade attacks where an attacker strips encryption from mail in transit. It works through a policy file served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt plus a _mta-sts TXT record, and TLS-RPT (a _smtp._tls record) collects daily reports of any TLS failures.

We host the policy file and both records, so you do not need to stand up a separate web server. We start in testing mode paired with TLS-RPT, then switch to enforce once the reports come back clean. The benefit is encrypted inbound mail with evidence it is working, not a config you set once and never check. More on MTA-STS and TLS-RPT.

BIMI

BIMI is the visible reward for doing the rest properly. Once your domain is enforced at p=quarantine or p=reject, BIMI lets your verified logo appear next to your messages in supporting inboxes such as Gmail and Apple Mail. It is published as a TXT record pointing to an SVG logo, and most major receivers also require a Verified Mark Certificate to display it.

We host the record, normalise your logo to the strict SVG profile the standard demands, and check the prerequisites are in place so the logo actually renders. The benefit is a recognisable, trusted sender mark that also nudges open rates, available only because the authentication underneath it is real. More on BIMI.

Analytics and reporting

Aggregate reports are the engine behind every safe policy change, and they arrive as raw XML from dozens of providers in volumes nobody can read by hand. A single mid-sized domain can produce hundreds of files a week. Until those reports are parsed, deduplicated and charted, they tell you nothing.

We ingest the RUA streams, combine them across all your domains, and turn them into pass-rate trends, a map of every source sending as you, and alerts when a previously aligned sender starts failing or an unknown one appears. The benefit is the visibility that lets us advance your policy on evidence rather than hope, and the early warning that keeps you enforced afterwards. More on analytics and reporting.

How the records work together

The pieces only protect you when they line up. DMARC does not simply ask whether SPF or DKIM passed. It asks whether they passed for a domain that matches the From address your recipient actually sees. That rule is called alignment, and it is what makes the stack stronger than any single record.

So the order matters. SPF and DKIM provide the proof, alignment ties that proof to your brand, DMARC sets the policy that acts on it, and the aggregate reports tell you whether every legitimate sender is covered before you tighten the policy further. MTA-STS protects the transport underneath, and BIMI sits on top as the visible payoff once enforcement is in place. Run them in isolation and a gap in one quietly undermines the rest.

The path to p=reject

Publishing a record takes five minutes. Reaching p=reject without losing real mail is the hard part, because almost every organisation sends from more services than it remembers: the main mailbox provider, a CRM, a billing platform, a transactional sender, a helpdesk, an events tool, and some internal app firing from a server in a cupboard. Each one needs SPF or DKIM configured so it aligns. Miss one at p=reject and its mail starts bouncing.

That is why the work is staged across four monitored steps, never rushed.

Who needs this, and why now

Email authentication stopped being optional. Google and Yahoo's bulk-sender rules took effect on 1 February 2024: any domain sending roughly 5,000 or more messages a day to Gmail must have SPF, DKIM and an aligned DMARC record, one-click unsubscribe on marketing mail, and a spam complaint rate under 0.3%. Microsoft began applying similar requirements to high-volume senders into Outlook.com, Hotmail and Live in 2025. PCI DSS 4.0 made anti-phishing controls mandatory from 31 March 2025, and DMARC is widely adopted as part of meeting those anti-spoofing expectations. Anti-spoofing questions now appear routinely in cyber-insurance forms and vendor security reviews.

In practice the platform suits a clear set of teams:

Done-for-you enforcement, or do it yourself

Everything we host is something you could run by hand. The question is whether you want to. The records are public standards, but keeping six of them correct and aligned, reading the reports, and timing each policy change safely is ongoing operational work, not a one-off project.

Task	Do it yourself	With DMARC Engine
Publishing records	Edit TXT entries by hand in your DNS panel	Hosted and versioned, with a history of every change
SPF lookup limit	Track includes manually, hope a vendor IP change does not break it	Flattened automatically and kept under ten lookups
DKIM keys	Generate, publish and rotate selectors yourself	Generated in your browser; public key hosted; rotation reminders + overlapping selectors
Reading RUA	Open hundreds of raw XML files a week	Parsed, combined and charted across all domains
Reaching p=reject	Judge by hand when it is safe to tighten	Staged on evidence, with rollback in minutes

If you run your own DNS and prefer to keep control, that is fine: our free tools diagnose your domain and generate correct records you can paste in yourself. If you would rather hand it over, we host and stage the lot. Either way the destination is the same, a domain that cannot be convincingly forged. Compare the options on our comparison page, or read how the staged rollout works step by step below.