Protect a Domain That Does Not Send Email with SPF, DMARC, and Null MX

Registering a new domain does not automatically mean that the domain will send or receive email. It may only host a website, redirect visitors to another site, protect a brand name, or remain parked for future use.

Even when a domain has no email provider, leaving its email authentication policy undefined gives receiving mail systems less information about what should be considered legitimate. An attacker may try to send phishing or spam that places the unused domain in the visible From address.

The better practice is to publish an explicit non-sending email policy. For a domain that truly sends no email, that normally means:

• An SPF record authorizing no sending servers.
• A DMARC policy requesting rejection of messages that impersonate the domain and fail authentication.
• A null MX record if the domain also receives no email.
• No active DKIM public keys. An optional wildcard revoked-key record is discussed later in this article.

This is not a fake DMARC record. It is a legitimate defensive configuration for a non-sending domain.

The Recommended DNS Records

For a domain that sends no email and receives no email, the core records are:

Type  Name     Priority  Value
TXT   @                  v=spf1 -all
TXT   _dmarc             v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s
MX    @        0         .

DNS control panels use different labels for the root domain. Depending on the provider, the Name field may be @, the full domain name, or left blank.

The bare dot in the MX value is intentional. It represents a null MX record and must not be replaced with the domain name.

What the SPF Record Does

The SPF record is:

v=spf1 -all

The -all mechanism is a hard fail. It says that no IP address is authorized to send email using this domain as the SPF identity.

The M3AAWG Protecting Parked Domains Best Common Practices recommends this record for every domain that never sends email. The behavior of SPF and its -all mechanism is defined by RFC 7208.

Do not publish more than one SPF record at the same domain name. If an SPF record already exists, investigate why it exists before replacing it.

What the DMARC Record Does

The DMARC record is published as a TXT record at _dmarc:

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s

The tags mean:

• v=DMARC1 identifies the record as a DMARC policy record.
• p=reject asks receivers to reject mail that uses the domain in the visible From address and fails DMARC.
• sp=reject explicitly applies the reject policy to existing subdomains.
• adkim=s requests strict DKIM identifier alignment.
• aspf=s requests strict SPF identifier alignment.

Strict alignment is not what makes this configuration reject mail. A non-sending domain should have no authorized SPF sender and no usable DKIM key, so legitimate aligned authentication should be impossible. The strict tags simply make the intended boundary explicit.

The current DMARC specification, RFC 9989, defines p=reject as the domain owner's statement that a DMARC failure indicates invalid use of the domain. A receiver still makes the final delivery decision, so DMARC is a requested policy rather than a universal guarantee.

Is This a Fake DMARC Record?

No. The record accurately describes the domain's email behavior.

A fake or misleading record would claim that certain systems are authorized when they are not. This configuration does the opposite: it clearly states that the domain has no authorized outbound mail stream.

This setup is widely recommended for parked, defensive, and website-only domains. M3AAWG recommends SPF -all and DMARC p=reject for domains that never send email. The UK National Cyber Security Centre parked-domain guidance recommends the same protections along with null MX.

DKIM Does Not Have a Reject Policy

It is common to hear this configuration described as adding a "reject DKIM record." That wording is misleading.

DKIM publishes public keys under selector names such as:

selector1._domainkey.example.com

DKIM verifies a cryptographic signature. It does not publish a domain-wide reject policy. DMARC is the layer that publishes the requested handling policy for mail that fails aligned SPF and DKIM authentication.

For a domain that has never sent email, M3AAWG recommends publishing no DKIM record at all. Without a public key, a forged DKIM signature claiming to use the domain cannot validate.

The Optional Wildcard DKIM Revocation Record

Some security guidance, including the UK NCSC guidance, also suggests this optional wildcard TXT record:

Type  Name          Value
TXT   *._domainkey  v=DKIM1; p=

An empty p= value represents a revoked DKIM key. The wildcard attempts to cover arbitrary selector names.

This record is not the DMARC reject instruction, and it is not required for the core non-sending-domain protection. The NCSC notes that a null DKIM record is not absolutely required, while M3AAWG recommends publishing no DKIM records for a parked domain.

For a simple new domain, SPF -all, DMARC p=reject, and no active DKIM keys are the clearest baseline. If your organization's policy calls for the wildcard revoked-key record, confirm that the DNS provider supports wildcard names under _domainkey and that no real DKIM selectors are still in use.

Add a Null MX Record When the Domain Receives No Email

SPF and DMARC address outbound identity and spoofing. They do not announce whether the domain accepts inbound email.

If the domain does not receive mail either, publish a null MX record:

Type  Name  Priority  Value
MX    @     0         .

RFC 7505 defines null MX as the standard way for a domain to state that it does not accept email. This prevents senders from falling back to a website's A or AAAA address when no normal MX record exists.

Do not add null MX if the domain receives mail, forwards addresses, uses an inbound help desk, or may need mailboxes such as [email protected].

DMARC Reporting Is Optional

A DMARC record can include an aggregate reporting address:

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

The rua tag is optional. Reports can show attempted abuse and whether receivers applied the policy.

If the protected domain has null MX and cannot receive email, do not point rua to an address on that same domain. Use a monitoring service or a mailbox on another domain. External DMARC report destinations may require an additional DNS authorization record at the receiving domain.

For a small parked domain where nobody will review reports, it is reasonable to omit rua entirely.

Confirm That the Domain Truly Sends No Email

Having no mailbox provider does not necessarily mean that the domain sends no email.

Before publishing SPF -all and DMARC p=reject, check for every system that may send mail using the domain, including:

• WordPress password resets, contact forms, comment notifications, and security alerts.
• WooCommerce receipts, invoices, and order updates.
• Web servers using PHP mail or a local mail transfer agent.
• SMTP plugins and transactional providers such as Amazon SES, Mailgun, Postmark, or SendGrid.
• Microsoft 365, Google Workspace, CRM platforms, ticketing systems, and newsletter services.
• Monitoring tools, backup alerts, scanners, firewalls, and cloud platforms.
• Services sending from subdomains such as mail.example.com or notifications.example.com.

If any of those systems sends legitimate mail using the domain, do not use the non-sending configuration. Document every sender, configure its SPF and DKIM requirements, verify alignment, monitor DMARC reports, and only then move toward an enforcement policy.

What This Configuration Stops

This configuration helps receiving systems reject direct spoofing of your domain in the visible From address. It makes a clear statement that no legitimate message should claim to originate from the domain.

It does not:

• Stop spam sent from unrelated domains.
• Stop attackers from registering a lookalike domain.
• Prevent display-name impersonation.
• Protect a domain whose DNS account has been compromised.
• Guarantee that every receiving mail server will enforce the requested DMARC policy.

DMARC is an important anti-spoofing control, but it is not a general-purpose spam filter.

Protect Subdomains Carefully

The example uses sp=reject, which applies the reject policy to subdomains. That is appropriate only when subdomains also send no email.

Before deploying it, inventory DNS and confirm that services do not send from addresses such as:

[email protected]
[email protected]
[email protected]

If a subdomain legitimately sends mail, give it its own correct SPF, DKIM, and DMARC configuration before enforcing a parent-domain policy that could affect it.

Verify the Records

After DNS changes propagate, check the records from a terminal.

On Linux or macOS:

dig TXT example.com
dig TXT _dmarc.example.com
dig MX example.com

On Windows PowerShell:

Resolve-DnsName example.com -Type TXT
Resolve-DnsName _dmarc.example.com -Type TXT
Resolve-DnsName example.com -Type MX

Confirm that:

• The root domain has exactly one SPF record and it returns v=spf1 -all.
• _dmarc returns the reject policy.
• The MX result is a null MX only if the domain receives no email.
• No old DKIM TXT or CNAME selectors remain active.
• No application or service is attempting to send legitimate mail from the domain.

If You Add Email Later

Treat the non-sending records as a lock that must be changed before the first legitimate message is sent.

Before activating an email provider:

1. Identify every outbound email service. 2. Replace SPF -all with the provider's exact authorized SPF configuration. 3. Publish the provider's DKIM selectors and enable DKIM signing. 4. Remove the wildcard revoked DKIM record if one was added. 5. Replace null MX with the provider's inbound MX records if the domain will receive mail. 6. Verify SPF and DKIM alignment before sending production email. 7. Review DMARC reporting and choose an enforcement rollout appropriate for the active mail stream.

Make these changes before enabling WordPress SMTP, creating mailboxes, launching a newsletter, or allowing an application to send notifications.

Recommended Baseline

For a new domain that sends no email but may host a website:

@       TXT  v=spf1 -all
_dmarc  TXT  v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s

If it also receives no email, add:

@  MX  0  .

Leave DKIM selectors unpublished unless your security policy specifically calls for the optional wildcard revoked-key record:

*._domainkey  TXT  v=DKIM1; p=

The important distinction is that DMARC publishes the reject policy. DKIM provides keys, and an empty DKIM key is only an optional revocation signal.

Final Recommendation

Yes, it is recommended to protect domains that do not send email. Publish SPF -all and DMARC p=reject, and use null MX when the domain also accepts no inbound email.

Do not call the DMARC record fake, and do not describe DKIM as the source of the reject policy. The DNS records are an accurate declaration that the domain has no legitimate mail stream.

Most importantly, audit the domain before applying the policy. A forgotten contact form, password-reset system, invoice service, or subdomain sender can turn a good anti-spoofing control into a legitimate email outage.

Sources

• M3AAWG Protecting Parked Domains Best Common Practices
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance
• RFC 7208: Sender Policy Framework
• RFC 7505: A Null MX Resource Record for Domains That Accept No Mail
• UK NCSC: Protecting Parked Domains