‘We don’t send from it’ is a claim: prove it before you harden the DNS
A domain with no obvious mailbox can still send mail. A website contact form, certificate alert, old help desk, finance platform or cloud tenant may use it without appearing in the current staff directory. Treat ‘non-sending’ as a claim that needs evidence, not as a synonym for ‘no MX record’.
The useful reframe is that DNS does not discover your business systems. It publishes instructions based on what you know. A restrictive policy gives receivers an unambiguous signal about forged mail, but the same signal can reject a hidden legitimate route. The work is therefore an inventory decision followed by a DNS change, not a quick security toggle.
The UK National Cyber Security Centre recommends defensive SPF, DMARC and null MX records for parked domains. NCSC guidance Those records address different paths: SPF describes authorised SMTP identities, DMARC covers use of the domain in the visible From field, and null MX says the domain accepts no inbound mail. None proves that an application has stopped sending.
Build evidence that the domain is genuinely quiet
Write the domain, its owner, business purpose, registrar, authoritative DNS provider and renewal contact into your sender inventory. Ask the people who run websites, finance, customer support, HR, monitoring and cloud services whether any product sends as the domain or receives replies at it. Search configuration repositories and password-manager item names without copying secrets into the inventory.
Query the current MX and TXT records and save the answers with a UTC timestamp. Review DMARC aggregate data if a reporting address already exists. Search mail-platform logs for the domain as a visible From address, envelope sender, return path or DKIM signing domain. Check subdomains separately. A root domain can be quiet while alerts.example.co.uk remains active.
Inspect continuity arrangements too. A parked brand domain may be reserved for a launch or kept as an emergency alias. Record that dependency. If nobody can identify the domain owner, logs are unavailable or reports show legitimate-looking traffic with no owner, stop. Do not publish rejection merely because the website looks unused. Escalate the evidence gap to the person responsible for domain and messaging ownership.
Separate what the domain may send from what it refuses to receive
An SPF record such as v=spf1 -all says that no host is authorised to use that domain in the SPF identities evaluated by a receiver. RFC 7208 defines the fail qualifier and explains that SPF is evaluated against SMTP identities, not merely the address a person sees. RFC 7208
A DMARC record such as v=DMARC1; p=reject asks participating receivers to reject mail using the domain in the visible From field when it does not pass aligned authentication. Current DMARC behaviour and alignment are defined by RFC 9989. RFC 9989 This control directly addresses many ordinary From-domain spoofs.
A null MX record states that the domain does not accept email. It affects delivery attempts to addresses at the domain, not forged outbound claims. The NCSC presents all three because each closes a different ambiguity. NCSC parked-domain guidance Publishing only null MX does not authenticate outbound mail. Publishing only DMARC does not tell remote senders that no inbound mail system exists.
Prepare exact records without borrowing another zone’s values
At the domain apex, prepare one SPF TXT policy that denies all senders: v=spf1 -all. Check whether a record beginning v=spf1 already exists. SPF permits one selected policy for a given name; separate competing records can produce a permanent error rather than a combined policy. RFC 7208 publication rules Never add a second record beside an unexplained first one.
At _dmarc.example.co.uk, prepare v=DMARC1; p=reject. If you have an approved reporting mailbox or service and a retention policy, an aggregate-report destination may be added. Reports can reveal unexpected use, but their XML includes domains, IP addresses and message counts. Do not route them to a personal mailbox or unapproved processor.
For inbound refusal, prepare an MX record with priority zero and target ., following the DNS provider’s syntax. Some panels represent the root with @; others use a blank name. Some append the zone automatically. Preview every resulting fully qualified name. Keep a snapshot of the old records, TTL values, change approver and rollback decision.
Once a domain is verified as silent, the hardening itself is short and effective: a deny-all SPF record, a rejecting DMARC policy and a null MX. Because each record closes a different ambiguity, it is worth reading them against the DMARC record examples guide so you understand exactly what each value requests from receivers before you publish.
Before publishing a deny-all SPF policy, check how SPF records are selected and repaired so an existing policy is not duplicated.
Publish in a controlled window with a named owner
Choose a period when the DNS owner, domain owner and any mail-platform owner can observe the result. Reduce TTL only if your process permits it and do so early enough for the previous TTL to expire. A newly lowered TTL does not erase answers already cached for longer.
Apply the records to the intended zone, one DNS name at a time. Save the provider audit event. Do not alter MX for a neighbouring active domain, remove ownership-verification TXT data or overwrite DKIM selectors. The restrictive SPF value belongs at the identity being protected; DMARC belongs at its _dmarc name; null MX belongs at the domain that must not receive.
There is a practical trade-off. Publishing all controls in one approved change removes ambiguity quickly, but can make fault isolation harder if the inventory was weak. Publishing in a brief recorded sequence makes each answer easier to check, but leaves protection incomplete between changes. Choose according to risk. In both cases, preserve the rollback snapshot and never weaken an active domain to simplify this parked-domain task.
The main risk is that a parked-domain change is made alongside a busy active-zone edit and something gets applied to the wrong name. Publishing in a short, recorded window, to the exact intended names only, removes that risk: the same controlled-change discipline you would use when repairing an SPF record on a live domain.
Query what the internet can actually see
Verification is not the save confirmation in a DNS dashboard. Query the authoritative nameservers and at least one independent recursive resolver. Record complete answers, names and TTLs. For example.co.uk, retrieve TXT at the apex, TXT at _dmarc.example.co.uk and MX at the apex.
Confirm there is exactly one logical SPF policy and its complete value is v=spf1 -all. Confirm the DMARC answer contains v=DMARC1; p=reject at the correct owner. Confirm MX returns priority zero with a dot target, not a hostname accidentally formed when the control panel appended the domain. Compare with the NCSC pattern rather than relying on appearance. NCSC examples
Test from outside the organisation because split DNS can return different answers. Query again after the old TTL window. A public checker is convenient, but save raw DNS output so another administrator can reproduce it. Do not paste account tokens, registrar screenshots or unrelated zone contents into a public support request.
Verify behaviour without sending forged mail
Do not spoof the parked domain to unsuspecting recipients as a test. Public DNS evidence is enough to check publication. Any mail test must use systems and recipient accounts you are authorised to operate. In a controlled lab, the expected finding is that unauthorised use cannot produce an aligned DMARC pass, not that a message lands in a particular folder.
For inbound behaviour, send one non-sensitive message from a controlled sender to a fictional local part at the parked domain. Expect the sender to recognise null MX and fail without delivery. Check that the sending service does not continue pointless retries. Never use a real person’s address or include customer content merely to prove rejection.
If aggregate reporting is configured, inspect it for unexpected sources after the change. Treat traffic as a lead, not automatic proof of attack or forgotten mail. Group it by source and authentication result, then investigate ownership. Also query and test important active domains sharing the same DNS account, because a template or bulk edit might have touched the wrong zone. The domain is verified only when the exact parked name shows the intended records and no legitimate dependency breaks.
Keep the protection attached to domain ownership
Add the records, evidence date and business decision to the domain register. Review them when ownership changes, hosting moves, a new website launches or a supplier proposes sending from the name. A future project must recognise the restrictive values as deliberate controls, not old clutter to delete. Include the expected renewal date and registry lock or access owner because losing control of the domain can invalidate every assumption behind the records. During each review, query the live answers again and compare them with the register. If reporting is enabled, confirm its destination is still controlled and that access follows the recorded retention arrangement.
The advantage is clarity: receivers get strong, consistent signals and inbound systems do not waste time trying an unsuitable host. The cost is operational discipline. A legitimate sender introduced without authentication will fail, and no real mailbox can receive while null MX remains. That is appropriate for a silent domain and harmful for an undocumented active one.
Stop and escalate before any exception if a team wants to send or receive mail, subdomain inheritance is unclear, another administrator cannot explain an existing record, or changing the zone could affect an active service. Reopen the sender inventory, design authentication for the proposed route and replace the parked-domain controls through an approved change. Do not simply soften -all or p=reject. Protection lasts only while the published promise matches the domain’s real use.
Protection only lasts while the printed promise matches what the domain actually does. When someone later wants to send or receive mail from the domain, the restrictive records must be replaced through a proper authenticated design, not quietly softened. That handover belongs in the same place as the rest of your sender inventory and domain register.
If the domain starts sending legitimate mail later, use the controlled DMARC enforcement guide to reassess policy against observed routes.
Sources and further reading
- NCSC: Protecting parked domains
- RFC 7208: Sender Policy Framework
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance