You bought the .net to go with your .com. You still own the domain from a product you shut down two years ago. Or you registered a name for something you haven't built yet.
You don't use these domains to send email, but they still need protection against spoofing.
An attacker doesn't need access to your inbox or mail server to put your domain in a forged From address. Publishing SPF and DMARC helps receiving mail servers recognize that unauthorized use and decide what to do with the message.
For a domain you don't send email from, the setup is straightforward: authorize no senders with SPF, request rejection with DMARC, and collect reports so you can see attempted use. If the domain doesn't receive email either, there's one more record to add.
First, confirm that nothing sends email on your behalf
This step is worth spending time on. Having no mailboxes doesn't necessarily mean your domain isn't used to send email.
Check for:
- A contact form that sends notifications from the domain
- Password resets, invoices, or monitoring alerts
- A newsletter or marketing platform someone set up years ago
- Third-party tools configured to send on your behalf
Check subdomains, too. You might never send from example.com while an application still uses notifications.example.com.
Receiving mail is a separate question. If the domain forwards incoming messages to your main inbox, keep that routing in place. Also check whether anyone replies using an address on the domain. If they do, it isn't a non-sending domain.
If you're unsure, start with DMARC reporting at p=none while you investigate, and leave existing SPF authorizations in place. A monitoring-only DMARC policy does not stop receivers from rejecting mail because of an SPF failure.
Once you've confirmed there are no legitimate senders, you can apply the configuration below.
These examples assume no legitimate email is sent from example.com or any of its subdomains.
1. Publish an SPF record that authorizes no senders
Add this TXT record at the root of your domain:
Type: TXT
Name: @
Value: v=spf1 -all
Many DNS providers use @ for the root domain. Some expect the full domain name instead.
That's the entire SPF record. There are no mail servers to list and no providers to include. The -all mechanism produces an SPF failure for every sending IP address.
Use the minus sign. ~all is a soft fail, which expresses a weaker policy. For a domain with no legitimate senders, -all makes the intent explicit.
If an SPF record already exists, replace it after checking that its authorizations are no longer needed. Don't add a second one: you can only have one SPF record at a given name. Unrelated TXT records, such as domain verification records, can stay.
There's one limitation: SPF checks the envelope sender used during delivery, not the From address someone sees in their inbox. That's the gap DMARC closes.
2. Publish a DMARC reject policy
Add a TXT record at _dmarc.example.com. If your DNS provider automatically appends example.com, enter only _dmarc in the Name field:
Type: TXT
Name: _dmarc
Value: v=DMARC1; p=reject
If you already have a DMARC record, edit it rather than creating another.
p=reject asks receivers to reject messages that fail DMARC. Subdomains, including those that don't exist in DNS, inherit this policy unless a more specific DMARC policy overrides it.
DMARC requires SPF or DKIM to pass and align with the visible From domain. An SPF failure alone doesn't make a message fail DMARC: a valid, aligned DKIM signature can still produce a pass. That's one reason to review old sending authorizations as part of this setup.
Receiving servers make the final delivery decision, so they can override p=reject. The record gives them a clear policy for handling forged mail, but it doesn't guarantee that every attempt will be blocked.
3. Keep reporting turned on
Even if you never send email from the domain, someone else's attempt to use it can appear in DMARC reports. Add a reporting address to the same record:
v=DMARC1; p=reject; rua=mailto:[email protected]
Create a free MyDMARC account, add your domain, and replace [email protected] with its assigned RUA address. If you already have an account, copy the address from your domain’s settings.
Reports can show which IP addresses sent mail claiming to be from your domain, how many messages receivers saw, whether authentication passed, and how receivers reported handling those messages.
If you're sending reports to another organization's domain, the destination needs to authorize receiving those reports. Follow your reporting provider's setup instructions.
Unexpected traffic is worth investigating. An empty dashboard isn't proof that nobody has attempted to spoof the domain, though. Reporting depends on what participating receivers observe and report.
4. Add null MX if the domain doesn't receive email
This step is only for domains that are used for neither sending nor receiving email.
Type: MX
Name: @
Priority: 0
Target: .
The target is a single period. A null MX record explicitly tells sending servers that the domain doesn't accept email.
Simply removing the MX records doesn't make the same declaration. Without an MX record, sending servers can fall back to the domain's A or AAAA records and attempt delivery there.
The null MX must be the domain's only MX record. Don't add it alongside an existing mail provider's records, and don't use it if the domain still has inboxes, aliases, or forwarding you rely on.
Your DMARC reporting address also needs to be on a domain that accepts mail. Reports can't be delivered to an address on the domain you've just configured with null MX.
5. Review subdomains and old sending access
The root domain's SPF record doesn't automatically cover subdomains. Publish v=spf1 -all separately on existing non-sending subdomains where appropriate.
For additional coverage, you can publish a wildcard TXT record at *.example.com with the value v=spf1 -all. It doesn't cover every subdomain: existing DNS names can prevent the wildcard from applying. The wildcard doesn't replace the root SPF record or explicit SPF records needed on existing subdomains. Review it before enabling future sending services.
Check for subdomain DMARC records, too. An explicit record can override the policy inherited from the parent.
Then retire obsolete SPF authorizations, DKIM records, and sending-provider access across the domain and its subdomains. Under DMARC's default relaxed alignment, a sender that authenticates through a subdomain can still pass DMARC for the main domain. Publishing v=spf1 -all at the root doesn't cancel those other authorizations.
Check the published records
Use a DNS lookup tool, or run:
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
Confirm that the results match your intended configuration, with only one SPF record and one DMARC record at their respective names. If you added null MX, the MX result should be 0 ., with no other mail servers listed.
Existing DNS caches need time to expire, so changes won't necessarily appear everywhere immediately.
Keep these domains on your review list. If you decide to use one to send email later, configure SPF and DKIM for the new sender, check DMARC alignment, and replace any null MX record with the appropriate receiving configuration.