How to Prevent Email Abuse on Non-Sending Domains

Every domain in your portfolio represents your brand. Whether you use it for email or not, spoofers don’t care – they care only that it looks like you. With a few DNS entries, you can protect your reputation, your customers, and your credibility. Think of it as sealing every envelope, vetting every post office, and watching your mailbox – at scale.

Trust, once broken, is hard to rebuild. But with the right tools, you can prevent it from ever being compromised.

A letter from your favorite brand

Imagine receiving a letter that looks like it’s from your favorite brand. The envelope bears the company logo, the return address matches corporate headquarters, and the message inside promises a limited-time discount. It feels authentic. But when you act on it, you discover it’s a scam. You’ve just been impersonated – on paper.

Now transpose this scenario to the digital world. Email, like traditional mail, can be faked just as easily. It’s one of the biggest blind spots in brand protection: organizations often overlook the threat of abuse coming from domains they don’t even use for sending email.

This includes defensive or dormant domains like brand.shop, brand.store, or brand.email. These are registered to prevent cybersquatting or brand dilution, but are often left unsecured from a mail perspective. That oversight opens the door for bad actors to spoof them, sending fake emails that appear to come from the brand itself. The consequences? Tarnished reputation, lost customer trust, and sometimes real financial damage.

So how is this possible? And more importantly, what can you do about it?

The digital post office: Understanding email spoofing

To demystify this, let’s stick with our mail analogy. Email delivery can be compared to sending a traditional letter. There’s the envelope, which contains routing information like sender and recipient, used by postal systems (or mail servers) to deliver it. Then there’s the letter itself, containing the actual message, and often duplicating the sender’s address in the letterhead.

Here’s the kicker: just as anyone can scribble any return address on a physical envelope, it’s also possible in the digital world to “spoof” the sender fields of an email. The mail server delivering the message doesn’t inherently verify that the sender is authorized to represent the domain they claim to be using.

Unless, of course, mechanisms are in place to enforce those rules.

Your first line of defense

The Sender Policy Framework (SPF) is like registering with the postal service which couriers are allowed to carry your brand’s mail. It lets domain owners specify which mail servers may send messages on their behalf. This information is published as a DNS TXT record for the domain – publicly accessible and used by receiving servers to validate incoming emails.

Example:

example.com. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com -all"

This says: “Only Microsoft’s infrastructure is allowed to send email for lemarit.com. If it comes from somewhere else, reject it.”

Now consider a non-sending domain like brand.shop. You can proactively declare that no email should ever come from it:

brand.shop. 3600 IN TXT "v=spf1 -all"

This small record sends a big message: “This domain is not meant for sending email. Treat any such message as suspicious.”

Wax-sealing the envelope

While SPF helps validate the envelope, DomainKeys Identified Mail (DKIM) helps ensure the letter’s integrity and authenticity. Think of DKIM as a wax seal used in traditional mail; a way to prove that the contents haven’t been altered and that the sender is legitimate.

With DKIM, part of the email is digitally signed by the sending server using a private cryptographic key. The matching public key is stored in the DNS, allowing receiving servers to validate the signature.

Example:

selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqh..."

Even if you don’t send email from a domain, you can (and should) publish a DKIM record that explicitly communicates this. Using a wildcard entry ensures that spoofers can’t forge a valid DKIM header:

*._domainkey.brand.shop. 3600 IN TXT "v=DKIM1; p="

Enforcing trust at the mailbox

SPF and DKIM are powerful alone – but together, they shine. Enter DMARC (Domain-based Message Authentication, Reporting, and Conformance), the policy layer that ties everything together.

DMARC tells receiving mail servers what to do if a message fails SPF or DKIM checks and enables reporting back to the domain owner. Think of DMARC as a letter to the postmaster: “Here’s how to handle suspicious mail, and here’s where to send the incident report.”

Strict DMARC for an active domain:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@lemarit.io"

For non-sending domains, you want a clear and strict policy:

_dmarc.brand.shop. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"

This says: “Reject all unauthorized emails – even from subdomains – and enforce strict alignment for both SPF and DKIM.”

But perhaps DMARC’s most underused power lies in its reporting function. Through rua (aggregate reports) and ruf (forensic reports) addresses, you get a daily feed of who is trying to spoof your domain. It’s your brand’s threat radar – don’t leave it turned off.

Shutting the mail slot with NULL-MX

Finally, an often-overlooked tool in your email defense arsenal: NULL-MX record. Just like taping over your mailbox slot with a “No mail here” sign, it tells the world this domain cannot receive email.

Example:

brand.shop. 3600 IN MX 0 .

This disables email delivery entirely. Combined with SPF, DKIM, and DMARC, this ensures that no part of the domain can be used for any legitimate mail purpose, shutting the spoofing door completely.

One domain? Or one hundred?

While your primary .com might be fortified, what about the dozens – or hundreds – of other domains you’ve registered for brand protection? Attackers assume these are overlooked. That .online, .store, or .sale domain from three marketing campaigns ago might now be the perfect vehicle for fraud.

Every domain you own should be treated like an open front door – lock it, or someone might walk in.

You may think: This isn’t rocket science. And it is in fact not. But it is tedious, especially across a wide domain portfolio. Understanding SPF syntax, configuring DKIM keys, interpreting DMARC reports, and maintaining policies across multiple domains require time and expertise.

A trusted partner like LEMARIT can simplify this process and help businesses:

• Analyze current email security posture
• Define and implement optimal DNS records (SPF, DKIM, DMARC, NULL-MX)
• Monitor DMARC reports to catch misuse before it causes damage
• Centralized, scalable control across your entire domain portfolio

Don’t wait until your customers call asking about suspicious emails. Secure your brand’s entire domain landscape proactively. It’s a small effort with a big impact – and it starts with a DNS entry.

Thomas Küchenthal is co-founder and CTO of LEMARIT GmbH, a specialist for domain management and digital brand protection. As an IT business engineer, Thomas brings technical expertise from more than 20 years of experience. As an acknowledged DNS specialist, he is a member of the Technical Advisory Council of DENIC eG and an advocate of a secure infrastructure with technically high-quality solutions.

Day in, day out, he and his team ensure optimal protection as well as control of digital brands of multinational enterprises. In doing so, customers also benefit from a platform specially developed under his leadership: the LEMARIT.app.