MediumPolicy

Non-sending domain is not protected against forgery

This domain appears to send no email, and it is not protected against being used to send email. A parked, defensive or retired domain can be spoofed as easily as an active one, more easily, in fact, because nobody is monitoring it and there is no sending history for a receiver to compare against. Three records close it off permanently and require no maintenance.

Check your own domainFull domain health check

What causes this

A domain that sends no mail should say so explicitly. Without a restrictive SPF record and a DMARC reject policy, an attacker can send mail claiming to be from it and receivers have no basis on which to refuse. Unused and parked domains are attractive precisely because nobody is watching them.

What it breaks

The domain can be used in phishing without any published policy standing in the way.

What the receiving server does

With nothing published, a receiver evaluating mail that claims to come from this domain gets a result of none for SPF and finds no DMARC policy. It has no basis on which to reject and falls back to reputation, which for a domain with no mail history is weak evidence either way. Publish v=spf1 -all and DMARC at p=reject and the same message is authenticated against an explicit statement that no server is authorised and failing mail should be refused, which conforming receivers act on.

The lockdown, in three records

This is a complete configuration for a domain that neither sends nor receives. Nothing here needs revisiting unless the domain is brought into use.

SPFv=spf1 -allTXT at the apex: no server is authorised to send
DMARCv=DMARC1; p=reject; rua=mailto:dmarc@yourmain.comTXT at _dmarc: refuse failing mail, and report it
MX0 .null MX: this domain accepts no mail
note-all not ~allthere is nothing legitimate to protect, so use the strict form

How to fix it

Publish an explicit no-mail policy.

  1. Publish a null MX record so senders know the domain receives no mail.
  2. Publish an SPF record of exactly 'v=spf1 -all'.
  3. Publish a DMARC record with p=reject at _dmarc.
TXT · _dmarc
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

If you send with

Brand and typo domains
Domains registered defensively against typosquatting are the highest value targets in a portfolio, because they look plausible to a recipient and are almost never monitored. Apply the lockdown at registration, as part of the standard setup, rather than as a later audit.
Domains retired after a rebrand
An old domain usually keeps redirecting the website long after mail stops. Mail authentication is the part that gets forgotten. If mail once flowed from it, the domain has history that makes spoofed mail more credible, not less.
Where to send the reports
Point rua at an address on a domain you actively monitor, not at the parked domain itself, which, with a null MX, cannot receive anything. Remember that reporting to another domain requires an authorisation record there.

Confirming the fix worked

  1. Publish the SPF record as TXT at the apex with the value v=spf1 -all.
  2. Publish the DMARC record as TXT at _dmarc with p=reject and a reporting address on a domain you monitor.
  3. Replace any existing MX records with a single null MX, priority 0 and a hostname of one dot.
  4. Re-run the check and confirm all three resolve. Nothing further is required unless the domain is brought into use.

Common questions

Why protect a domain that nobody uses?
Because attackers prefer them. An unused domain has no sending history to contradict a spoofed message and no one watching for reports. Registering a domain defensively and leaving it unprotected covers the trademark risk while leaving the email risk wide open.
Should I use -all or ~all here?
-all. Softfail exists to avoid harming legitimate mail you might have missed, and on a domain that sends nothing there is no such mail. The strict form is the accurate statement.
Will this stop the domain redirecting to my website?
No. These are mail records only. Web traffic uses A, AAAA and CNAME records and is entirely unaffected.
What if the domain needs to send mail later?
Reverse it when that happens: replace -all with the senders you are authorising, lower DMARC to p=none while you confirm the configuration, and publish real MX records if it needs to receive. The lockdown is not permanent, it is simply correct until the answer changes.