Anyone can send email as your company: the DMARC gap

There is a question every business owner assumes has a reassuring answer: can a stranger send email that appears to come from my company? For most of the Baltic web, the measured answer is yes. As part of the Baltic Web Audit, our near-census of the Latvian, Estonian and Lithuanian web in August 2026, we read the published email protection records across the region’s live domains, and the protection is close to nonexistent.

In short

Only 8% of live Latvian domains, 9% of Estonian and 3% of Lithuanian are actually protected against sender forgery, meaning both standard records are in place and enforcement is switched on. The majority in every country, 70% in Latvia, 60% in Estonia and 72% in Lithuania, has no DMARC record at all, and for those domains nothing instructs the world’s mail servers to stop a forged sender. This is not an exotic attack. Sending email with your domain in the From line requires no break-in and no password, only your silence in DNS, and the fix is a pair of records that cost nothing but configuration.

Why the From line is not proof of anything

Email’s original protocols do not verify the sender address a reader sees. Authorization is something a domain has to opt into by publishing records in DNS, and if it never does, no mail server anywhere has been told what a genuine message from that domain looks like.

Two records do the work. SPF, defined in RFC 7208, lets a domain publish “records in the DNS specifying which hosts are permitted to use their names”, so a receiving server can check whether the machine that delivered a message was ever authorized to. DKIM adds a cryptographic signature. And DMARC, defined in RFC 7489, is the piece that makes the other two mean something to a reader: it ties their results to the visible From address and publishes a policy telling receivers what to do with messages that fail.

That policy is the whole game, because RFC 7489 gives a domain three choices. p=none “requests no specific action be taken regarding delivery of messages”. p=quarantine asks for failures to be treated as suspicious, in practice the spam folder. p=reject states that the domain owner “wishes for Mail Receivers to reject email that fails the DMARC mechanism check”. A domain is protected at reject, partially at quarantine, and merely watching at none.

What the audit measured

The exposure comes first. A working mail setup, meaning the domain actually receives email, is present on 77% of live Latvian domains, 83% of Estonian and 89% of Lithuanian. The Baltic web does email almost universally, which is what makes the protection numbers bite.

Against that, the enforced-protection rate is 8% in Latvia, 9% in Estonia and 3% in Lithuania. The largest group in every country simply has no DMARC record: 70% of live domains in Latvia, 60% in Estonia, 72% in Lithuania.

The second finding is quieter and, for anyone who thought they were done, more uncomfortable: having the record mostly changes nothing. Among domains that do publish DMARC, the policy is p=none, watch but do nothing, on 53.6% in Latvia (7,740 of 14,439), 68.6% in Estonia (20,978 of 30,593) and 77.9% in Lithuania (20,573 of 26,406). A policy that rejects fakes outright stands on 3,584 Latvian, 3,343 Estonian and 2,457 Lithuanian domains; one that quarantines them on 3,115, 6,272 and 3,376 in the same order. The record was published, the switch was never flipped.

Lithuania’s combination is the worst in the region: the most mail-enabled web, the least protected one, and the highest monitor-only share among those who tried.

Who this actually hurts

A forged sender is not a theoretical indignity. It is how a supplier’s “updated bank details” email reaches your client with your name on it, and how a payroll change request reaches your own accountant from “the director”. The forgery does not touch your systems at all, which is why no antivirus, firewall or password policy on your side ever sees it. The damage arrives as a conversation between two other people, both of whom believed the From line.

DMARC setup, in the right order

The rollout has a standard shape, and the order exists because the failure mode of doing it backwards is losing your own legitimate mail.

First, read what you have. Your DMARC policy, if any, is a TXT record at _dmarc.yourdomain.com; nslookup -type=txt _dmarc.yourdomain.com shows it in one command, and your SPF record is a TXT record on the domain itself. If you would rather not open a terminal, our free DMARC check reads both records and answers in plain words. No record, or p=none, means today a forged sender fails nothing.

Second, publish DMARC at p=none with reporting switched on (the rua= address in the record), and read the reports for a few weeks. They will show every service sending as your domain, and there are usually more than anyone remembers: the newsletter tool, the CRM, the invoicing app, the website’s contact form. Each legitimate one needs to be covered by SPF or DKIM before you tighten anything.

Third, move to p=quarantine, then p=reject. Microsoft’s own DMARC rollout documentation puts it plainly: you need to “test and verify along the way to prevent destination email systems from rejecting good mail”. Staged, this takes weeks of elapsed time and very little labour. Skipped, it takes one afternoon and some fraction of your outbound mail with it.

What you can fix yourself, and what needs a developer

Checking your own state is genuinely a one-minute job with the lookup above, and publishing the initial p=none record with reporting is a copy-paste into your DNS panel that risks nothing, because none enforces nothing.

Where it deserves someone who has done it before is the enforcement step. The record is trivial; the inventory is not. Every legitimate sending service has to authenticate correctly before reject is safe, mail flows through forwarders and mailing lists have known sharp edges, and a mistake does not announce itself, it silently drops real messages. That work is part of what our care plans cover, precisely because it is the kind of thing that is cheap to do carefully and expensive to do twice.

Why we can say any of this

The figures here come from a near-census rather than a sample. We measured 293,806 of the 306,872 Baltic domains in our frame across July and August 2026, and the email figures in this article rest on the region’s live domains rather than a survey sample. Everything is published as an aggregate: no individual site or company is ever named beside a weakness. The method and every chapter is in the Baltic Web Audit, and the earlier articles in this series cover whether your site is blocking AI assistants and how slow the region’s web is on a phone.

If you would rather know than guess, check your domain now. It reads your SPF and DMARC records, tells you plainly whether a stranger can currently pass as you, and gives you the safe first record to publish. When you want the enforcement step done properly, with every legitimate sender mapped before anything is switched on, talk to us.