Every domain owner faces the same fundamental security challenge: ensuring their digital identity remains trustworthy.

Even if a domain is used exclusively for hosting websites and never transmits an email; not even automated notifications from subdomains; properly configuring its DNS records is essential.

Without these safeguards, the domain remains vulnerable to spoofing, allowing malicious actors to impersonate it and damage its reputation. This guide explains how to secure a non-sending domain by correctly implementing MX, SPF, DMARC and DKIM records.

1. The MX record: Blocking incoming mail

The mail exchange (MX) record tells other servers where to deliver email sent to your domain. If you do not host email, you should not have an MX record pointing to a mail server.

However, simply deleting the MX record can sometimes cause ambiguity. The most robust approach for a non-sending domain is to point the MX record to a null destination. This explicitly instructs receiving servers to reject all incoming mail.

Recommended configuration

Field Value
Type MX
Name @ (or leave blank depending on your DNS provider)
Value ^ . (a single dot)
Priority 0

^ Some DNS providers do not allow a single dot as a value. In that case, ensure no MX record exists at all, or point it to a non-existent IP if your provider requires a valid target. The goal is to ensure no legitimate mail server accepts delivery.

2. The SPF record: Declaring "no senders"

Sender policy framework (SPF) allows you to specify which IP addresses are authorised to send email on behalf of your domain. Since your domain sends nothing, your SPF record must explicitly state that no IP addresses are authorised.

Recommended configuration

Field Value
Type TXT
Name @
Value v=spf1 -all

The -all mechanism is a "hard fail." It tells receiving servers to reject any email claiming to be from your domain that does not originate from an authorised list. Since your list is empty, everything is rejected. This is the strongest possible stance for a non-sending domain.

3. The DMARC record: Enforcing the policy

Domain-based message authentication, reporting, and conformance (DMARC) ties SPF and DKIM together and tells receivers what to do if authentication fails. For a non-sending domain, you want to enforce a strict policy and request reports so you can monitor for spoofing attempts.

Recommended configuration

Field Value
Type TXT
Name _dmarc
Value v=DMARC1; p=reject; rua=mailto:postmaster@yourdomain.com

Key parameters:

  • p=reject: This is critical. It instructs receiving servers to discard any email that fails SPF or DKIM checks. Combined with the -all in your SPF record, this creates a near-impenetrable barrier against spoofing.
  • rua: This specifies where aggregate reports should be sent. Replace postmaster@yourdomain.com with an email address you actually monitor (perhaps on a different domain). These reports will show you if anyone is trying to impersonate your domain.

4. The DKIM record: Not required (but harmless)

DomainKeys Identified Mail (DKIM) involves adding a cryptographic signature to outgoing emails. Since your domain does not send any email, you technically do not need to generate a DKIM key or publish a TXT record for it.

However, if you wish to be thorough and prevent attackers from generating their own keys for your domain, you can publish a dummy record or simply rely on the strict DMARC policy (p=reject) which will fail any email lacking a valid signature anyway. In most cases for non-sending domains, omitting the DKIM record is perfectly acceptable because the SPF -all and DMARC reject policy already block unauthenticated mail.

Summary of records

Record type Name Value Purpose
MX @ . (or none) Rejects all incoming mail
TXT (SPF) @ v=spf1 -all Authorises zero IPs to send mail
TXT (DMARC) _dmarc v=DMARC1; p=reject; rua=mailto:admin@example.com Forces rejection of failed auth and requests reports

Final thoughts

By implementing these records, you transform your domain from a vulnerable target into a fortress. Even if you never send a single email, protecting your domain's reputation is essential for your overall digital security posture.

Once configured, give it 24–48 hours for DNS propagation, then monitor your DMARC reports to ensure no spoofing attempts are slipping through.