An Unused Domain Can Still Appear in a Fake Email

A retired or parked domain can still appear in a forged email. Its policies need to reflect any applications that send mail and any addresses that still receive it.

A domain does not need working mailboxes for someone to put it in a forged email’s From address.

A retired brand, parked domain or defensive registration can still appear to send mail. Publishing explicit policies gives receiving services a way to identify messages that should not exist. UK government guidance on protecting non-sending domains

No mailboxes does not always mean no sending

An application may send receipts, alerts or password resets using a domain that has no staff mailboxes. Those messages need to remain authorised.

Receiving mail is another separate use. A domain might accept messages at old addresses while never sending any itself. Its incoming mail settings still matter.

The policy should describe what the domain actually does, rather than whether someone currently signs in to a mailbox.

A non-sending SPF policy says no server is authorised

For a domain that truly sends no email, v=spf1 -all declares that no sending IP address is authorised by SPF.

That policy does not disable incoming mail. SPF concerns sending authorisation, so a receive-only domain can still accept messages. Microsoft’s SPF documentation

DMARC adds the connection to the visible From address and can request rejection of messages that fail authentication. It helps receivers handle exact-domain forgery; it does not prevent someone using a similar-looking domain.

SPF records do not automatically apply to subdomains. DMARC policies can cover subdomains, subject to their own published policies and the applicable inheritance rules. How subdomain email authentication works

Choose the policy for what the domain still does

For a domain and its subdomains confirmed to have no legitimate senders, an illustrative starting point is a TXT value of v=spf1 -all at the domain and v=DMARC1; p=reject; sp=reject at _dmarc. If a subdomain still sends, review its own policy and inheritance before applying rejection across the parent.

The DMARC checker can inspect the published policy. The government guidance on non-sending domains provides configuration details; establish the domain's actual uses before applying them.

Sending and receiving are separate decisions

View full-size image

Read the diagram as text

1. A domain that never sends can publish a no-sender SPF policy and an appropriate DMARC rejection policy.
2. If it still receives mail, keep the working MX records.
3. If it neither sends nor receives, Null MX can explicitly declare that incoming mail is not accepted.
4. A domain with a legitimate sending application does not belong in either no-sending example.

A domain that receives nothing can say so too

A Null MX record explicitly states that a domain does not accept email. That is appropriate only when no addresses at the domain need to receive messages.

The Null MX value is a single dot, with priority 0, and it must be the domain’s only MX record. Do not replace working MX records if old addresses still receive email.

Simply removing ordinary MX records is different: email delivery rules can fall back to the domain’s address records. Null MX removes that ambiguity. Null MX standard

A no-sender SPF policy has no provider references to flatten. The useful decision for an unused domain is which activities remain legitimate, then publishing policies that reflect them.