Missing DMARC? Here's Why It Still Puts You at Risk, Even If You Never Send Email

If you scan a domain today, there's a good chance one finding comes back looking something like this: Critical, severity 9.7 — Missing DMARC Record. For a lot of site owners, that finding is confusing. "We don't even send email from that domain," the thinking goes. "How can it be critical?"

That reaction is exactly the gap attackers count on.

You don't have to send email for someone else to send it as you

Here's the part that catches people off guard: email spoofing doesn't require access to your mail server, your website, or anything you actually run. It only requires that your domain has no rule telling the internet who is allowed to send mail on its behalf. Without that rule, an attacker can put your domain in the "From" field of an email, send it through infrastructure that has nothing to do with you, and the message will often sail straight into your customer's inbox looking completely legitimate.

That's the mechanism the Dutch National Cyber Security Centre (NCSC) describes when it explains how attackers abuse the way email protocols were originally built: without email authentication, the sending domain simply isn't verified, so criminals can send mail that appears to come straight from your organization. Your customer sees your name. Your employee sees your name. Neither has any easy way to tell it's fake.

Now picture the domain that isn't even doing anything: a parked brand name, an old campaign domain, a regional variant you registered defensively and forgot about. No website, no mailbox, no reason to think about it. To an attacker, that's ideal. It carries your name, it carries whatever trust your brand has built up, and because nobody is watching it, nobody notices when it starts sending fraud.

SPF, DKIM, and DMARC, in plain terms

These three records work together, and each one closes a different gap.

SPF (Sender Policy Framework) is a DNS record that lists which mail servers are allowed to send email for your domain. A receiving mail server checks the sender's address against that list. If the sending server isn't on it, the message looks unauthorized. SPF alone has a real weakness, though: it doesn't survive email forwarding well, and it doesn't check the "From" address a human actually sees in their inbox, only a technical field most people never look at.

DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing mail, generated from a private key your mail server holds. The receiving server looks up the matching public key in your DNS and checks whether the message, and its headers, arrived unmodified and genuinely came from a holder of that key. DKIM is more resilient to forwarding than SPF, but on its own an attacker can simply send unsigned mail and skip it entirely.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the piece that ties the other two together. It tells receiving mail servers what to do when a message fails SPF and DKIM checks: let it through, quarantine it, or reject it outright. Just as importantly, it asks receivers to report back, so you can see who is actually sending mail using your domain, including the mail you didn't send. Without a DMARC policy, a receiving server has no instructions for what to do with a message that fails authentication, so it's left to guess, and guessing tends to favor delivering the phishing email rather than blocking a legitimate one.

Why this matters more than it looks like it should

Email remains the single most common way attackers get an initial foothold, whether that's credential theft, ransomware delivery, or the kind of invoice fraud typically called business email compromise. DMARC.org frames the underlying incentive plainly: spoofing a trusted brand's name is one of the cheapest, most effective ways to make a fraudulent message look legitimate, because trust in your name does the persuading for the attacker, and simply borrowing that trust is easy without protection in place.

There's also a business cost that has nothing to do with being attacked directly. If your domain is regularly used to send spoofed mail, mailbox providers start associating your name with abuse, and legitimate email from you can start landing in spam or getting silently dropped. Since 2024, large providers including Gmail and Yahoo have required bulk senders to have SPF, DKIM, and a valid DMARC policy in place, and Microsoft's Outlook checks have tightened further since. Missing or broken authentication doesn't just create a phishing risk, it actively hurts your own mail's deliverability.

The "we don't send email from this domain" trap

This is the scenario that trips up the most organizations, and it's worth spelling out clearly: a domain with no mail flow is not a domain with no risk. If it resolves in DNS at all, it can be spoofed, because spoofing doesn't care whether your domain sends real mail. It only cares whether the domain allows any mail to look legitimate.

The fix is to explicitly tell the internet that the domain sends no mail at all, using the strictest possible settings, since there's no legitimate traffic to accidentally break.

For a domain with no website either (no A or AAAA record):

example.com.       TXT  "v=spf1 -all"
*.example.com.      TXT  "v=spf1 -all"
_dmarc.example.com. TXT  "v=DMARC1; p=reject;"

For a domain that still serves a website but sends no mail:

example.com.         A     203.0.113.10
example.com.         MX    0 .
example.com.         TXT   "v=spf1 -all"
*.example.com.        TXT   "v=spf1 -all"
_dmarc.example.com.    TXT   "v=DMARC1; p=reject;"

The -all (rather than ~all) tells receivers to hard-fail any mail claiming to be from this domain, and the MX 0 . record explicitly declares that the domain accepts no mail at all. Since nothing legitimate is meant to pass, there's no reason to phase this in gradually the way you would for an active mail domain.

If you do send mail: roll it out in stages

For domains that send real mail, don't jump straight to a hard reject policy, since a misconfigured record can just as easily block your own newsletters or invoices as it blocks an attacker. The safer path, echoed by both DMARC.org and the NCSC:

1. Publish SPF and DKIM first, covering every legitimate sending source, including any third-party marketing or CRM tools sending on your behalf.

2. Start DMARC in monitoring mode (p=none) with a rua reporting address. This asks receivers to send you daily reports on who's sending mail as your domain, without changing delivery yet, so you can see spoofing attempts and fix your own gaps at the same time.

3. Move to p=quarantine once reports show your legitimate mail is passing consistently, so failing mail lands in spam rather than the inbox.

4. Move to p=reject once you're confident nothing legitimate is still failing.

5. Use strict alignment (aspf=s) where you can, and rotate DKIM keys periodically. The NCSC specifically recommends signing with both RSA-SHA256 at 2048-bit and Ed25519, since older mail servers and modern ones don't always support the same algorithm, and it recommends dropping RSA-SHA1 entirely as no longer secure.

Watch for the two situations most likely to break a rollout: mailing lists, which don't take authorship of your messages, and automatic forwarding, both of which can fail SPF checks even for entirely legitimate mail.

Adoption is growing, but slowly and unevenly

DMARC.org's own tracking of published policies across a large domain dataset shows adoption climbing over the past several years, alongside a shift toward stricter enforcement policies rather than monitoring-only ones. SIDN Labs, which runs the .nl registry, publishes similar ongoing figures for Dutch domains specifically, including the share of domains with a DMARC record and how those policies are distributed. Both are worth a look if you want to see where the baseline sits for your own industry or country. The pattern is consistent either way: the domains still missing this protection are increasingly the exception, not the norm, which makes them a more conspicuous, and more attractive, target.

Where Catcher24 fits

Catching a missing or misconfigured DMARC record isn't something you can eyeball by looking at your website; it lives in a DNS record almost nobody checks manually. That's exactly the kind of gap our infrastructure scans are built to surface: alongside open ports and known vulnerabilities, we run automated DNS record analysis across every target, flag missing or weak SPF, DKIM, and DMARC configuration, and rank the finding by real-world severity, the same way you saw in the example at the start of this post.

Two honest notes on scope. We find and report the misconfiguration; we don't write your DNS records for you, and we're not a mail server, so implementing the fix is still on your team, your registrar, or your DNS provider. We also don't stop phishing that spoofs a look-alike domain instead of yours, no scanner can, since that's a separate domain entirely.

Start your free 10-day trial and scan up to 5 targets, including the parked and forgotten domains sitting quietly in your portfolio. You'll see your DNS, certificate, and mail-authentication status ranked by severity, so you know exactly what to fix first.

Sources referenced: NCSC — Protect your domains against phishing · DMARC.org FAQ · DMARC.org adoption statistics · SIDN Labs .nl mail statistics