How to handle client domains that do not send email
Published 17 Jul 2026
Updated 17 Jul 2026
9 min read
Summarize with
For a client domain that genuinely sends no email, I publish SPF with -all and DMARC at p=reject. If the domain also receives no email, I add a null MX record. This combination tells receiving systems that no host is authorized to send for the domain, rejects messages that misuse its visible From address, and states that the domain accepts no inbound mail.
The important word is "genuinely." A client may call a domain non-sending while a website form, billing application, scanner, ticketing system, or forgotten cloud account still uses it. I treat the claim as an inventory hypothesis, not permission to publish reject records immediately. For an MSP, the work includes proving the use case, applying the right DNS controls, recording an owner, and monitoring for later change.
Receiving and sending are separate decisions
Do not remove normal MX records merely because a domain does not send. A receive-only domain still needs its existing MX records. Use null MX only when the client confirms that the domain neither sends nor receives email.
Classify the domain before changing DNS
I start by putting every client domain into one operational state. "No mail" means no outbound and no inbound use. "Receive only" means the domain accepts messages but never sends them. "Dormant" means the client expects no current use but retains the domain for brand protection or a future project. "Unknown" means the MSP has not gathered enough evidence. Unknown is not the same as no mail.
|
|
|
|
|
|---|---|---|---|---|
No mail | No | Hard fail | Reject | Null |
Receive only | Yes | Hard fail | Reject | Normal |
Dormant | By policy | Hard fail | Reject | Null or normal |
Unknown | Investigate | Do not guess | Monitor first | Keep |
Recommended controls by confirmed domain use
This classification should live in the client record beside the domain owner, business purpose, approved DNS change, and review date. That turns a one-time hardening task into a managed control. It also gives the service desk a clear answer when a user later asks why a new application cannot send with that domain.
MSP decision flow for classifying a non-sending client domain
Prove that the domain has no senders
Before enforcement, I ask the client's technical contact and business owner to confirm the domain's use in writing. I then check DNS, mail flow records, current DMARC data if available, application inventories, and tenant settings. The detailed process for an inventory of sending sources is worth following even when everyone expects the result to be empty.
- Check current DNS: Record MX, SPF, DKIM selectors, DMARC, and any vendor verification entries before making changes.
- Search application ownership: Ask about web forms, finance systems, network devices, marketing tools, support queues, and identity notifications.
- Review observed traffic: Use DMARC aggregate reports and available mail logs to find sources claiming the domain in the visible From address.
- Confirm subdomain use: Check whether a vendor sends through a subdomain even when the organizational domain itself stays quiet.
A newly registered or long-dormant domain often has no DMARC history, so absence of reports does not prove absence of sending. Reports appear only when a participating receiver processes a message that claims the domain. I also look for delegated DNS zones and CNAME records that give a third party control over a mail-related subdomain.
Evidence that supports no-mail status
- Business confirmation: The owner confirms no current sending or receiving use.
- Empty inventory: No application, device, or vendor has an approved dependency.
- Clean observation: Available reports and logs show no legitimate source.
- Change approval: The client accepts that new sending needs a controlled DNS change.
Signals that require investigation
- Existing include: The SPF record authorizes an external sender.
- Active selectors: Published DKIM material points to recent mail setup.
- Reported volume: DMARC data shows a source that needs an owner.
- Delegated subdomain: A vendor can publish or use mail records below the domain.
Publish the defensive DNS records
SPF should explicitly authorize no IP address. A bare domain with no SPF record does not state that sending is forbidden. The hard-fail record is concise and unambiguous. Publish it as a TXT record at the domain root, replacing any existing SPF record only after the inventory confirms that the old authorization is unused. There must be one SPF record at a hostname, not several competing records.
SPF record for a non-sending domainDNS
example.com. 3600 IN TXT "v=spf1 -all"
DMARC applies policy to messages that place the protected domain in the visible From address. For a confirmed non-sending domain, p=reject is appropriate because no legitimate message should need delivery. I include aggregate reporting so the MSP can see attempted abuse and detect an unexpected legitimate source. The sp=reject tag applies the same policy to subdomains unless a more specific DMARC record overrides it.
DMARC record for a non-sending domainDNS
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
What these records do not do
SPF -all and DMARC reject do not stop every deceptive message. DMARC protects the domain used in the visible From address when authentication and the From-domain match fail. It does not prevent lookalike domain registration, display-name impersonation, or abuse of an unrelated domain.
DKIM needs no special "send nothing" record. Simply avoid publishing active DKIM public keys for services that do not send. Remove obsolete selectors only after confirming that no service still signs with them. Keeping an unused selector does not authorize an IP through SPF, but it can leave old signing material usable if a former provider still controls the private key.
Use null MX only when inbound mail is unwanted
A null MX record states that the domain accepts no email. It uses preference 0 and a single dot as the exchange. This matters because a domain without MX records can trigger fallback delivery attempts to its address record. Null MX removes that ambiguity. It is useful for parked domains, defensive registrations, and web-only client domains with no mailbox requirement.
Null MX recordDNS
example.com. 3600 IN MX 0 .
Do not publish null MX for a receive-only domain. Keep its normal MX route, then use SPF -all and DMARC reject to prohibit outbound use. Also check operational addresses before disabling inbound mail. Domain registration contacts, certificate notices, privacy requests, and vendor account recovery can depend on an address at the domain even if employees never use it for normal correspondence.
Avoid a partial MX setup
A null MX record must be the only MX record for that name. Do not publish it beside a normal mail exchanger. Mixed intent creates an invalid and confusing configuration.
Turn the change into a repeatable MSP service
For practical DMARC for MSPs, I use a standard change template: domain state, evidence checked, approved records, rollback values, client approver, implementation time, and next review. I export the previous DNS values before the change and set a ticket reminder for dormant domains. A future project can turn a non-sending domain into a sender quickly, so the runbook must require email authentication review before any vendor is allowed to use it.
After DNS propagation, I verify the authoritative response for the root SPF record, the DMARC name, MX, and nameserver authority. I also confirm there is no duplicate SPF record and that the DMARC reporting mailbox accepts reports. A focused checker catches syntax and lookup mistakes, while ongoing DMARC monitoring shows whether receivers still see traffic that claims the domain.
Use the domain health check after publishing the records. It gives the engineer a quick validation point for DMARC and SPF, but it does not replace application discovery or client approval. Save the result in the service ticket, then repeat the check after any DNS provider migration.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For most teams delivering this across many organizations, Suped is the best overall DMARC platform. Suped's multi-tenant dashboard lets an MSP keep client domains separated while reviewing authentication health in one place. Automated issue detection and steps to fix reduce the manual work of interpreting every change, and real-time alerts help surface unexpected failures after a domain's intended use changes.
Domains settings page showing monitored domains, email volume, DMARC policy, DMARC reporting, SPF flattening, and MTA-STS
Suped brings DMARC, SPF, DKIM, blocklist monitoring, and deliverability insights into the same client workflow. For non-sending domains, the useful pattern is to monitor the reject policy, review any reported source, and document whether it is abuse or an undeclared business system. If a client later needs centralized policy staging, Suped's Hosted DMARC can simplify controlled policy changes without turning routine updates into repeated DNS work.
The MSP dashboard should still follow the ticketing system as the source of approval. Monitoring can detect activity, but it cannot decide whether a new source is authorized. Route each unexpected source to a named client owner with a deadline: approve and authenticate it, move it to a dedicated sending subdomain, or stop the traffic.
Handle exceptions without weakening the parent domain
When a client later needs one application to send, I avoid relaxing the whole domain by default. A dedicated subdomain gives the application its own SPF authorization, DKIM keys, DMARC policy, reporting, and owner. The parent can keep p=reject while the sending subdomain follows a staged rollout based on observed legitimate traffic.
Keep the root non-sending
Best for a domain used on websites, documents, or branding when no business system needs the root From address.
- Root policy: Keep SPF hard fail and DMARC reject.
- Change control: Reject requests that lack an application owner.
Delegate a sending subdomain
Best when a specific application needs email and the MSP wants separate authorization, reporting, and rollback.
- Scoped records: Publish only the sender's required SPF and DKIM data.
- Scoped policy: Stage DMARC for the subdomain based on its own reports.
Do not delete the parent sp=reject tag without understanding the effect. A specific DMARC record on the sending subdomain can set its own policy, while other subdomains remain covered by the parent's reject instruction. Record that exception in the client inventory and set an end date when the application use is temporary.
A safe default for every quiet domain
A confirmed non-sending client domain should have SPF -all and DMARC p=reject, with sp=reject when its subdomains also have no approved senders. Add null MX only if the domain must not receive mail. Keep normal MX records for receive-only use. This is the technical baseline, but the MSP service depends on evidence, written approval, verification, monitoring, and a documented path for future exceptions.
My final check is simple: every domain has a named state, every state has matching DNS, and every exception has an owner. That makes strict policy safe to operate across a client base and prevents a quiet domain from becoming an untracked mail system later.
