Non-Sending Domains: DNS Step-By-Step Setup To Stop Spoofing

Many domain owners maintain websites, blogs, or applications that never send emails. These ‘non-sending’ domains include defensively registered names, legacy sites, or purely hosting-focused properties. Despite not transmitting emails, such domains remain vulnerable to malicious exploitation. Attackers frequently impersonate these domains in phishing campaigns, business email compromise (BEC) schemes, and spam blasts, eroding trust and potentially causing financial harm.

Fortunately, strategic DNS configurations can declare your domain’s non-email status to the world, instructing mail servers to reject any purported messages from it. This article explores the critical DNS records—primarily TXT-based—that form a defensive barrier. By understanding and applying Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC), you can neutralize these threats without complex infrastructure.

Understanding the Threat Landscape

Email spoofing occurs when fraudsters forge the ‘From’ address to mimic legitimate domains. For non-sending domains, lacking authentication records leaves them wide open. According to UK government cybersecurity guidance, unprotected domains enable criminals to perpetrate fraud by masquerading as trusted entities.

Phishers target these domains because they often lack scrutiny. A domain like ‘example-archive.com’ might sit idle, but attackers could send emails claiming to be from ‘support@example-archive.com’, tricking recipients into divulging sensitive data. Statistics from cybersecurity reports highlight millions of spoofed emails daily, with non-configured domains disproportionately abused.

Without defenses, receiving servers assume legitimacy, delivering malicious payloads. Implementing DNS safeguards flips this dynamic: servers actively discard unauthorized claims, safeguarding your reputation.

Core DNS Defenses for Non-Sending Domains

Three TXT records—SPF, DKIM, and DMARC—interlock to create comprehensive protection. Additionally, a null MX record reinforces the ‘no mail here’ signal. Let’s break down each.

Sender Policy Framework (SPF): Deny All Senders

SPF lists authorized mail servers via a TXT record at your domain’s apex (@). For non-sending domains, the directive is simple: authorize none.

The record format is:

• Name/Host: @
• Type: TXT
• Value: v=spf1 -all

Here, v=spf1 declares the SPF version, and -all mandates rejection of any email failing prior authorizations (of which there are zero). This ‘fail’ mechanism prompts strict mail servers to bounce messages outright.

UK GOV.UK recommends this exact setup for government domains not sending email, confirming its efficacy across sectors. Verify via tools like dig TXT yourdomain.com, expecting output like: "v=spf1 -all".

DomainKeys Identified Mail (DKIM): Publish an Empty Key

DKIM verifies email integrity through cryptographic signatures. Senders sign messages with a private key; receivers fetch the public key from DNS to validate.

For non-senders, publish a wildcard empty public key, signaling no valid signatures exist:

• Name/Host: *._domainkey
• Type: TXT
• Value: v=DKIM1; p=

The empty p= (no modulus) ensures all DKIM checks fail, as no signature can match. This wildcard covers all selectors, revoking any prior keys implicitly. Per RFC 7505, this null MX and empty DKIM combo explicitly signals non-delivery intent.

Revoke legacy selectors by deleting old TXT/CNAME records. Servers encountering purported DKIM-signed emails from your domain will reject them due to key mismatch.

Domain-based Message Authentication, Reporting, and Conformance (DMARC): Enforce Rejection

DMARC builds atop SPF/DKIM, dictating actions on failures. Hosted at _dmarc.yourdomain.com, it mandates rejection for non-senders.

Breakdown:

• p=reject: Reject emails failing authentication at the domain level.
• sp=reject: Same for subdomains.
• adkim=s: Strict DKIM alignment (From header domain must match signing domain).
• aspf=s: Strict SPF alignment.

This policy ensures zero tolerance. Since SPF always fails and DKIM has no key, DMARC triggers rejection. UK guidance echoes this for high-security environments.

Null MX Record: No Mail Exchange

Complement with a null MX:

• Name/Host: @
• Type: MX
• Value: . (priority 0)

This points to no server, discouraging delivery attempts per RFC standards.

Implementation Guide Step-by-Step

1. Access DNS Panel: Log into your registrar or host (e.g., Cloudflare, GoDaddy).
2. Add SPF: Create TXT @ with v=spf1 -all.
3. Add Null MX: Set MX @ to . (0).
4. Add Empty DKIM: TXT *._domainkey v=DKIM1; p=.
5. Add DMARC: TXT _dmarc v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s.
6. Propagate & Verify: Wait 1-48 hours; use MX Toolbox or dig.

For subdomains sending email (e.g., mail.sub.yourdomain.com), use sp=none in DMARC and configure subdomain SPF/DKIM separately.

Advanced Scenarios and Best Practices

Legacy Domains: Audit and purge old records. Legacy gsi-family domains, now cloud-migrated, benefit immensely.

Monitoring: Add rua=mailto:reports@yourdomain.com to DMARC for aggregate reports, tracking abuse attempts.

Automation: Tools like DNSControl script bulk setups:

function NO_EMAIL(name) {  return [    MX(name, 0, '.'),    // SPF, DKIM, DMARC builders  ];}

Common Pitfalls:

• Forgetting wildcard DKIM (* selector).
• Using ?all or ~all in SPF (softfail only).
• Misaligning DMARC (relaxed vs. strict).

Frequently Asked Questions

Will these records break my website?

No. These are email-specific TXT/MX records; they don’t affect HTTP/HTTPS.

How long until effective?

DNS TTL varies (1-48 hours). Test immediately with verification tools.

What if I start sending email later?

Revise SPF to include servers, generate DKIM keys, adjust DMARC to p=quarantine.

Do I need all three records?

Yes for maximum protection; they complement each other.

Free tools to check?

MX Toolbox, Google’s DMARC tester, dmarcian.com analyzer.

Conclusion

Securing non-email domains demands proactive DNS hardening. SPF’s -all, empty DKIM, reject DMARC, and null MX form an ironclad shield against spoofing. Implement today to preserve your domain’s integrity amid rising phishing threats. Small configuration yields outsized security gains.