Parked, defensive and acquired domains belong in one ownership programme, but they should not inherit one untested DNS template. First establish who controls each domain and whether it sends or receives legitimate mail. An acquisition label tells you how the domain arrived, not whether it is safe to disable its mail services.
Record purpose before choosing records
Document the registrar and DNS account owner, business sponsor, renewal responsibility, sending purpose, receiving purpose and known subdomains. Keep account secrets out of the register. For an acquired domain, include the former administrator and unresolved application dependencies. A defensive registration can still receive legal or recovery correspondence, so confirm receiving use independently of sending use.
Use at least three states for each question: yes, no after review, and unknown. A blank field should not become no. Include scheduled jobs, website forms, vendor notifications, dormant disaster-recovery systems and seasonal campaigns in the hidden-flow review. This is a recommended operational checklist, not a test performed by a DNS record.
Choose controls for the correct direction
Null MX is a single MX record with preference zero and a root label exchange, commonly shown as 0 .; it declares no mail acceptance for that domain and must not coexist with other MX records. It does not mean that the domain sends no mail. RFC 7505, sections 3 and 4. Do not replace working inbound MX records because outbound traffic appears absent. RFC 7505 section 4.2 also says systems SHOULD NOT publish Null MX for domains used in MAIL FROM or visible From addresses, because mail risks rejection. A campaign domain that sends but does not receive therefore should not be assigned Null MX automatically.
For a confirmed non-sending domain, the exact SPF record v=spf1 -all, with no positive mechanisms, expresses that no sending hosts are authorised for the evaluated SPF identity. A record with earlier positive mechanisms can authorise matching hosts even when it ends in -all. DMARC separately expresses policy for use of the visible From domain when aligned authentication fails. Neither prevents display-name impersonation or lookalike domains. RFC 7208, section 5.1 and RFC 9989. Review subdomain and policy discovery behaviour rather than assuming every child name has the same configuration.
Decide separately for four domain purposes
Consider four hypothetical review outcomes. Payroll sends and receives, so both approved directions must remain available. A campaign domain sends but has confirmed no receiving use, so outbound authentication and any no-reception decision are independent. A defensive registration is confirmed to do neither after a hidden-flow review, making it a candidate for restrictive controls. An inherited domain has unknown purpose, so its configuration remains on hold pending investigation.
These are assumed inputs, not executed code, owner interviews or DNS observations. For the inherited domain, a quiet reporting window cannot turn unknown into no. Assign the former application owner and current registrar operator to resolve service dependencies before approving a change. Check child names separately; a parent’s record is not evidence that every subdomain has the same use.
Keep the portfolio maintainable
Apply changes through a recorded approval and verification process. Preserve the old RRsets, test affected services and confirm the authoritative state after an approved mutation. Record the domain's lifecycle stage, review date and next owner action. Do not let an acquisition exception become a permanent unknown.
Recheck purpose when a parked domain becomes a campaign site, when ownership changes or before retirement. Keep registrations and renewals under accountable ownership even when mail is disabled. A domain's low activity does not remove its value as a business identity.