DEV Community

Nobuo Miura
Nobuo Miura

Posted on • Edited on

Protect Non-Email Domains from Spoofing with DNS Records

#security #dmarc #dns #email

Domains used exclusively for web services, or acquired for future use through domain parking, can still be used in phishing and email-spoofing campaigns, even when they neither send nor receive email.

This article explains how to configure three DNS records — MX / SPF / DMARC — to prevent abuse of non-email domains.

Why Non-Email Domains Are Targeted

Attackers scan for domains with missing or weak SPF and DMARC records to use in the From: address. Domains that never send email are the most likely to be unconfigured, making them easy targets.

A common attack scenario:

  1. example.com is a web-only domain — no email is ever sent from it
  2. An attacker sends phishing emails with From: support@example.com
  3. Because SPF / DMARC are not configured, receiving servers have no policy to apply and the message may be delivered

Records to Configure

Record Value Purpose
MX 0 . Explicitly declare that this domain accepts no mail (null MX)
SPF (TXT) v=spf1 -all Declare no authorized senders exist
DMARC (TXT) v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:... Enforce policy and collect reports

Setting Up Each Record

1. MX Record — Null MX (RFC 7505) 

example.com.  MX  0  .
Enter fullscreen mode Exit fullscreen mode

0 . (zero, dot) is the standard way to explicitly signal that this domain accepts no mail (RFC 7505).
Publishing an explicit null MX is preferable to omitting the MX record entirely, as it removes ambiguity for sending servers.
Note that a null MX must not coexist with any other MX records — it must be set as the sole MX record for the domain.

2. SPF Record — Declare No Authorized Senders 

example.com.  TXT  "v=spf1 -all"
Enter fullscreen mode Exit fullscreen mode

-all (hard fail) declares that no authorized mail servers exist for this domain, resulting in an SPF evaluation of Fail.
This produces a stronger result than ~all (soft fail, SoftFail), making it easier for receivers to apply policy.
However, the final decision to reject a message is left to the receiving server.

3. DMARC Record — Policy Enforcement 

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@yourdomain.com"
Enter fullscreen mode Exit fullscreen mode

Tag breakdown:

Tag Value Meaning
p reject Request that receivers reject messages failing DMARC evaluation
sp reject Apply the same policy to subdomains (same value as p=reject, but explicit)
adkim s (strict) DKIM d= tag must exactly match the From domain
aspf s (strict) SPF MAIL FROM must exactly match the From domain
rua mailto:... Destination for aggregate reports

About rua (Report Destination)

Setting up reporting is recommended especially for non-email domains.
Aggregate reports are sent in periodic batches by DMARC-compliant receivers — immediate detection is not guaranteed — but they can help you identify patterns of spoofing attempts.
Use an email address you can monitor, or an external DMARC reporting service, to receive and review these reports.

If your reporting address is on a different domain, you need to authorize it with a TXT record in that domain's DNS zone:

example.com._report._dmarc.yourdomain.com.  TXT  "v=DMARC1"
Enter fullscreen mode Exit fullscreen mode

Note: This TXT record must be added to the DNS zone of yourdomain.com (the report receiver), not to example.com (the protected domain).

A Note on adkim=s / aspf=s (strict)

In strict mode, DKIM aligns only when its d= domain exactly matches the RFC5322.From domain; SPF aligns only when its MAIL FROM domain exactly matches it. For example, a DKIM signature with d=example.com will not satisfy alignment for From: sub.example.com under strict mode.
If you ever start sending legitimate email from this domain in the future, consider switching to adkim=r; aspf=r (relaxed).

Optional: Revoking DKIM Keys for Past Selectors

If the domain previously sent email and the DKIM selectors used at that time are known, you can explicitly revoke those keys.

default._domainkey.example.com.  TXT  "v=DKIM1; p="
Enter fullscreen mode Exit fullscreen mode

An empty p= signals key revocation (RFC 6376), causing any DKIM signature referencing that selector to be treated as invalid.
Note that there is no verification difference between a revoked record and a deleted record, and this provides no defense against unknown selectors.
Consider this only when you want to explicitly retire a selector that was actively used in the past.

Verifying Your Configuration

Use dig to confirm the records are live:

# MX
dig MX example.com

# SPF
dig TXT example.com

# DMARC
dig TXT _dmarc.example.com
Enter fullscreen mode Exit fullscreen mode

Expected output:

;; ANSWER SECTION:
example.com.        300  IN  MX   0  .
example.com.        300  IN  TXT  "v=spf1 -all"
_dmarc.example.com. 300  IN  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@yourdomain.com"
Enter fullscreen mode Exit fullscreen mode

Summary

These three records form a recommended baseline for protecting a non-email domain from spoofing:

example.com.         MX   0  .
example.com.         TXT  "v=spf1 -all"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@yourdomain.com"
Enter fullscreen mode Exit fullscreen mode

On receivers that implement DMARC and enforce policies, messages spoofing this domain can be expected to be rejected.
Take a few minutes to audit all the domains you own — the ones you're not actively using are the most likely to be missing these records.

Top comments (2)

Collapse
 
sealedmail profile image
SealedMail •

Good write-up. One thing worth adding: parked or non-sending domains should also have an MX record pointing nowhere ("v=spf1 -all" already handles SPF, but a null MX - 0 . per RFC 7505 - signals explicitly that the domain accepts no mail and can reduce bounce-spam). DMARC with p=reject and both SPF and DKIM set to block/omit completes the picture. (disclosure: I run SealedMail)

Collapse
 
miura profile image
Nobuo Miura •

Thanks! I agree. I included the null MX (MX 0 .) as the first part of the baseline because it explicitly signals that the domain accepts no mail, while SPF and DMARC cover sender authorization and policy enforcement. Good point about reducing bounce-spam/resource waste as well.