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:
-
example.comis a web-only domain — no email is ever sent from it - An attacker sends phishing emails with
From: support@example.com - 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 .
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"
-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"
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"
Note: This TXT record must be added to the DNS zone of
yourdomain.com(the report receiver), not toexample.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="
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
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"
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"
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.
