What Is a Sending Domain?
TL;DR
A sending domain is the domain a message is sent from and authenticated against, and it is the unit inbox providers attach reputation to. It appears in the visible From address, in the DKIM signing domain and in the envelope sender, and DMARC alignment requires the authenticated one to match the one the reader sees.
What does a sending domain need published?
A single SPF record naming every service that sends for it, a DKIM public key at each selector your senders sign with, and a DMARC record so receivers know what to do when neither check aligns. Those three are what turn a domain from an unverified claim into an identity a receiver can act on.
One thing sits outside DNS on the domain itself: the PTR record for the sending IP, which lives with whoever controls the address. A forward-confirmed reverse lookup is a basic expectation at the large providers, and a sending IP with no PTR is a cheap way to look like an amateur operation.
Should cold outreach go out on your main domain?
Consider what shares the reputation. The domain carrying your billing notifications, password resets, support replies and sales conversations is the same domain a cold campaign would build a sending history on, and reputation damage does not stay in the mailbox that caused it.
The usual answer is to separate the streams, either on a subdomain or on a distinct domain kept close to the brand. That preserves the recovery path: a subdomain or secondary domain can be paused and rebuilt, while the domain your customers reply to cannot.
Frequently asked questions
Both are tracked, and domain reputation is the one you carry with you. Changing sending provider changes the IP and leaves its history behind; the domain keeps its record wherever it sends from, which is what makes the domain the asset worth protecting.