Business email authentication on 82 company domains in Harghita: 46% have no DMARC record

Business email authentication decides whether a receiving mail server can tell your real emails apart from the ones someone else sends using your domain. In the fifth part of the series on the websites of 100 companies in Harghita County, I checked whether company domains have the three DNS records that make this possible: SPF, DKIM and DMARC.

Why I care: for a while, anyone could send email in my name from my own domain too. I wrote up what happened and how I fixed it here.

How I measured

The measurement was taken on 27 September 2026. The sample: the 50 largest companies in Harghita County from the Termene 2025 revenue ranking, and 50 small businesses from different sectors. Of the 100 companies, 87 have a website; I checked the domains of those websites, and 82 of them receive email (they have an MX record). The numbers below refer to these 82 domains. I read the MX, SPF and DMARC records with public DNS lookups, and looked for a DKIM key under 18 common selector names.

Limits:

• A missing DKIM key proves nothing. The name of a DKIM key (the selector) can be anything, and it cannot be listed from the outside. Where I found no key, one may still exist under another name.
• I measured the website domain. If a company sends email from a different domain, this study says nothing about it, but protecting the website domain still matters, because a fraudster can send email under that name.
• DNS records show what the domain owner asks receiving servers to do. They do not show where a particular email ends up.
• The small-business half contains only companies with a working website.

Three records in a nutshell

• SPF lists the servers allowed to send email for the domain.
• DKIM adds a digital signature to each message, which the receiving server checks against a key published in DNS.
• DMARC tells receivers what to do with a message that fails these checks: nothing (p=none), put it in spam (p=quarantine), or reject it (p=reject). The standard is defined in RFC 7489.

SPF and DKIM on their own are only signals. Real protection comes from DMARC, and only when its policy is quarantine or reject.

Business email authentication in numbers

• 78 domains have an SPF record (95%), 4 (5%) do not. I found no domain with duplicate, and therefore invalid, SPF records.
• At the end of the SPF record, 59 domains use ~all (soft fail), 18 use -all (hard fail) and 1 uses ?all (neutral).
• I found a DKIM key on 61 domains (74%) under one of the common selector names.
• 38 domains (46%) have no DMARC record.
• On 25 domains (30%) the DMARC policy is p=none, meaning it only monitors. 12 (15%) use quarantine, 7 (9%) use reject.
• 19 domains (23%) count as protected: they have a single SPF record and a quarantine or reject DMARC policy.

The raw data shows one more telling number: of the 25 domains with p=none, only 7 ask for reports (rua) from receiving servers. On the other 18, the DMARC record gives neither protection nor any information to the owner. The 4 domains without SPF have no DMARC either.

Large companies and small businesses

• No DMARC: 31% of the 35 mail-receiving domains of large companies, 57% of the 47 small-business domains.
• Protected (quarantine or reject): 29% of large companies, 19% of small businesses.
• Ask for DMARC reports: 40% of large companies, 15% of small businesses.

Here the large companies are ahead, but even among them only about one domain in three or four sends spoofed email to spam or rejects it.

Who handles the email?

Based on the MX records, 15 of the 82 domains use Google and 7 use Microsoft; the other 60 use other providers. The big mailbox providers keep getting stricter: since 2024, Google has required SPF, DKIM and DMARC from bulk senders (Google email sender guidelines). A small company is not a bulk sender, but its emails pass through the same filters, and an unauthenticated message is more likely to land in spam.

What does this mean for your company?

There are two risks. One is that someone sends email using your domain, say a fake invoice or a "new bank account number", and the recipient's server does not filter it out. The other is that your own emails land in spam, because the recipient's server cannot verify them. The same thing happens with the contact form on your website: I wrote here about why contact form emails do not arrive.

The order of the fix:

1. Have exactly one SPF record that includes every service sending on your behalf: your mailbox provider, your website, your newsletter tool. 2. Turn on DKIM at your email provider. In Google Workspace and Microsoft 365 this is one setting and one DNS record. 3. Publish a DMARC record with p=none and a report address, then watch for a few weeks who sends email in your name. 4. Once every legitimate sender passes, move to quarantine, then to reject.

Many stop at step three. A p=none record without reports is like an alarm that nobody can hear.

A five-minute self-check

• Check your domain with a free DMARC checker: is there an SPF record, and only one?
• Do you have a _dmarc record? If so, what follows p=, and is there an rua= address?
• Send an email to your own Gmail address and open "Show original": do SPF, DKIM and DMARC all say PASS?
• Does your website's contact form send from an authenticated mailbox?

If any of these is off, send me your domain and I will take a look. On the websites I build, email authentication is part of the launch, and in a website takeover it is part of the first check.