DIAGNOSTIC PLAYBOOK
Protect a domain that should never send email
A non-sending domain still benefits from an explicit email policy, but first verify that no application or vendor uses it. Incoming-mail behavior is a separate decision from outbound authentication.
HealthCheck Email editorial team · · Examples are illustrative
How to investigate
- Inventory website forms, billing systems, support tools and aliases that might use the domain as a From identity.
- Establish a no-sending SPF policy and an appropriate DMARC rejection policy once ownership confirms the intent.
- Review report evidence and separately decide whether the domain should receive mail or publish null MX.
What this looks like
ILLUSTRATIVE EXAMPLE
A parked brand domain is thought to be unused, but a legacy alert job still sends as it. The inventory catches that dependency before a policy change.
A mistake to avoid
Do not publish null MX if the domain needs to receive mail. An outbound-only decision does not automatically imply no inbound service.
Keep the result in context
DMARC connects the visible From domain to a passing, aligned SPF or DKIM identity. A DNS policy is an instruction to receivers, not a delivery receipt. Use message results and aggregate reports together, and identify legitimate services before tightening a policy.
Take the next step
Use the related check to gather evidence, then compare it with the affected message or service. Keep the result and time with your notes so a later change can be distinguished from the original problem.
Sources and further reading
The protocol references below explain the underlying behavior. Your sending or DNS provider supplies the account-specific settings for its service.