A domain can be new to your organisation without being free of mail dependencies. A fresh registration may be used by a new website, while an acquired or re-registered name may have inherited applications, forwarding rules or expectations that the new owner has not yet discovered.
The first useful DMARC decision is therefore a purpose decision. Establish who controls the domain, what it will send, what it will receive and who can approve a change. Then configure and verify the relevant records for that scope.
Create a small purpose register
Treat the domain as an asset with a responsible owner. Record the registrar account, authoritative DNS provider, renewal contact, change approver and intended use. Administrative access should survive a staff departure.
Keep sending and receiving as two separate fields:
- Intended use: Website only; Sending question: Can any form, support tool or application send using this domain?; Receiving question: Do customers or services need an address here?
- Intended use: Transactional product mail; Sending question: Which application accounts and recovery routes send?; Receiving question: Where will replies, delivery failures and support requests go?
- Intended use: Employee mail; Sending question: Which users, delegates and connected tools send?; Receiving question: Which mailboxes, aliases and forwarding paths exist?
- Intended use: Defensive registration; Sending question: Has the organisation approved any sending at all?; Receiving question: Is any inbound service required?
This suggested register makes hidden assumptions visible. “No employee mailboxes” does not establish that a domain sends nothing.
Check for a less obvious mail dependency
Before declaring a domain non-sending, inspect website forms, monitoring tools, ecommerce settings, invoice systems, identity providers and support platforms. Ask whether they use the domain as visible From, envelope return address or a DKIM signing domain.
For an acquired domain, include contracts and application owners from the acquisition handover. A DNS snapshot records what is published now; it does not prove the absence of a dormant application or a message scheduled for next month.
Use the sender inventory to attach each discovered use to a named account and owner. Retain unanswered checks as open findings rather than converting silence into approval.
Verify where DNS changes actually belong
Confirm the authoritative servers and the exact fully qualified owner name before publishing. A registrar account and a DNS hosting account can be different systems. Subdomain delegation can move a particular part of the name tree to another authority.
For a new sending domain, follow the platform's generated configuration for the actual account. Publishing a DKIM key or delegation record is not proof that the service has begun signing; RFC 6376 §3.6.2.1 and RFC 6376 §5 separate key retrieval and signing. Send a controlled message through the intended route and inspect trusted received verification and alignment.
Under RFC 9989 §4.5, DMARC policy is published at the applicable _dmarc name. A value placed at the domain root does not substitute for that owner name. The publication workflow connects DNS verification with message and reporting evidence.
Choose the correct branch for a non-sending domain
A genuinely non-sending domain can publish policy expressing the owner's handling preference for unauthorised use of its From domain. A restrictive DMARC policy is a scope decision that still depends on receiver implementation and analysis.
SPF and inbound service require separate decisions. Under RFC 7208 §5.1 and RFC 7208 §4.6.2, an illustrative v=spf1 -all policy states that no source is authorised by that SPF policy for the evaluated domain. It does not by itself describe every possible subdomain or block inbound mail.
A null MX declaration concerns receiving. RFC 7505 §3 defines it as the sole MX record, with preference zero and target a single dot, for a domain accepting no mail. The guidance in RFC 7505 §4.2 says domains used in MAIL FROM or the visible From address should not publish null MX. Do not apply it merely because the domain has no ordinary inbox.
Use the non-sending-domain guide before combining these controls. They express different intentions and must agree with the actual use.
Work through a fictional new product domain
Suppose a company registers a product domain. Its launch checklist labels the name “website only”, but three checks reveal other uses:
- Discovery: A password-reset service will use the product domain in From; Consequence: The name is a sending domain
- Discovery: Replies should reach a support address; Consequence: An inbound route is required
- Discovery: A backup application region uses a separate provider account; Consequence: That account needs its own configuration and message evidence
The correct next step is to revise the purpose register, configure the approved routes and verify them. Applying a non-sending record set would contradict the planned service.
A separate defensive name might genuinely have no approved sending or receiving use. Its owner can choose controls for that different purpose and document the checks supporting the classification.
Make reporting a working operational path
If aggregate reporting is requested, verify the destination and any required external-destination authorisation under RFC 9990 §4. Decide who will review reports and how unexpected traffic will be investigated. A reporting address is not useful merely because it appears in a TXT value.
A new domain may produce little legitimate traffic. Under RFC 9990 §3.1 and RFC 9989 §5.3.8, an empty collection could reflect no observed mail, receiver participation or a collection problem. Use controlled tests and collection checks to distinguish those possibilities.
Keep reporting privacy and access proportional to the purpose. The reporting-privacy guide explains how to assess the data collected.
Review purpose changes before enabling a new service
The initial configuration should not become an obstacle that teams bypass. When a domain gains employee mail, transactional use or a new subdomain, require a purpose update and the corresponding authentication and receiving review.
Current full DMARC participation requires more than a single passing message: The requirements in RFC 9989 §8 include aligned SPF and DKIM, reporting and policy publication. General-purpose employee domains also need the interoperability assessment in RFC 9989 §7.4 before choosing reject.
The durable outcome is a domain whose owner, purpose and records agree. Review that agreement when the domain's business role changes, rather than assuming a first-day label remains accurate forever.
Keep the next action specific
The product-domain fixture needs both an approved sending route and a reply path, so its website-only label must change before selecting non-sending controls. The backup account remains a distinct verification task. Null MX, SPF -all and DMARC handling preference are not interchangeable switches. These are planning consequences, not implemented records or a real acquisition assessment.