Step-by-Step Guide: Securing Unused or Parked Domains from Spoofing and Abuse

Unused or parked domains are common targets for spoofing, phishing, and spam campaigns. Even if a domain does not send email, failing to configure email authentication (SPF, DKIM, and DMARC) can leave it open to abuse.

In this guide, you'll learn how to secure unused or parked domains against email-based threats by implementing effective authentication controls.

Prerequisites #

Before you begin, ensure you have:

• Access to your domain registrar
  You must be able to log in to the control panel of your domain registrar to manage DNS settings.
• Basic understanding of DNS
  Familiarity with DNS record types will help you understand and apply the changes.

Step 1: Publish a "No Mail" SPF Record #

SPF declares which mail servers are allowed to send email for your domain. For a domain that should send no email, explicitly state this:

DNS Record:

• Type: TXT
• Name: @ (or the domain name)
• TTL: auto
• Value:

v=spf1 -all

Explanation:

• v=spf1: SPF version.
• -all: No IPs or servers are allowed to send email.

Step 2: Publish a "No Mail" DMARC Policy #

DMARC tells receiving servers how to handle unauthorised messages. For unused domains, it should instruct them to reject all mail and send reports if desired.

DNS Record:

• Type: TXT
• Name: _dmarc
• TTL: auto
• Value:

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]

Explanation:

• v=DMARC1: DMARC version.
• p=reject: Reject unauthenticated mail sent from the main domain.
• sp=reject: Reject unauthenticated mail sent from subdomains.
• adkim=s and aspf=s: Use strict alignment for DKIM/SPF.
• rua=...: (Optional) Receive aggregate reports.

Step 3: Do Not Publish DKIM Keys #

For domains that don’t send email:

• Do not publish DKIM DNS records.
• This avoids giving the false impression that DKIM is in use.

Step 4: Disable All Mail Services #

1. Remove MX Records

• Delete any MX records unless the domain is actively receiving email.
• Active MX records signal that the domain accepts mail.

2. Set a Null MX Record

• Configure a special MX record indicating that the domain does not accept email.
• This is defined in RFC 7505 and uses a null MX with a single dot (.) as the target.

DNS Record:

• Type: MX
• Name: @ (or the domain name)
• Mail server: .
• TTL: auto
• Priority: 0

example.com. 3600 IN MX 0 .

Explanation:

• example.com. is the domain.
• 3600 is the TTL (time to live) in seconds.
• IN MX 0 . specifies:
  • Priority: 0 (ignored in this context)
  • Destination: . (a root label, signifying "no mail accepted")

3. Alternative: Dummy MX Record

• Not all DNS providers support . as a valid mail server value.
• In that case, use a dummy mail server:

Example:

example.com. 3600 IN MX 10 invalid.mailhost.

This tells other mail servers to try sending mail to invalid.mailhost., which doesn't exist. As a result, mail to example.com will fail. This helps block unwanted or spoofed email.

Explanation:

• example.com. is the domain name.
• 3600 is the TTL (time to live) in seconds.
• IN MX defines it as a mail exchange (MX) record.
• 10 is the priority (lower numbers are preferred).
• invalid.mailhost. is a fake or non-existent mail server.

Step 5: Verify #

Once you have added the records, you should verify their existence to ensure they have been correctly set up.

SPF:

dig +short TXT example.com

DMARC:

dig +short TXT _dmarc.example.com

MX:

dig +short MX example.com

Step 6: Monitor (Optional) #

If using rua=mailto:..., aggregate DMARC reports from major providers will inform you if someone attempts to spoof your domain.

DNS Records Checklist #

Result #

With these records:

• All emails claiming to be from the domain will fail SPF and DMARC.
• Receiving servers will reject these spoofed emails.
• Attackers cannot use your domain for phishing, spam, or spoofing.