Subdomain or root domain
Why a sending subdomain is the safer default, what it isolates, and why verification never inherits from a parent domain.
Send from a subdomain such as mail.acme.com unless you have a specific reason not to.
What a subdomain isolates
A dedicated sending subdomain separates the reputation of your transactional and marketing streams from each other, and from the root domain that carries your corporate mail: your support inbox, your team's mail, your website's own MX records. The goal is to keep a reputation problem on one stream from reaching the domain your business depends on for everything else.
Verification does not inherit
Verifying acme.com does not authorize orders@mail.acme.com to send. Mailfully's per-send check matches the from domain exactly against your verified domains, so a subdomain of a verified domain is not itself verified. Send from mail.acme.com before it's verified in its own right and the request fails 422 validation_error with param: "from", even with acme.com fully verified. See Verify a domain.
When the root domain is right
Send from the root domain when your volume is low, you run a single stream with no separate transactional and marketing traffic to isolate from each other, and the apex isn't used for anything else a reputation problem could touch.
Separate subdomains per stream
At any real volume, give transactional and marketing mail their own subdomains, such as mail.acme.com for transactional and a distinct one like news.acme.com for marketing, and verify each one separately since verification is per domain. Splitting streams this way keeps a rough marketing send from putting your transactional reputation at risk with receiving providers, even though both draw from the same account-level IP pool.
DMARC follows the sending domain
Whichever domain you send from, DMARC's home is _dmarc.<sending domain>, the record Mailfully returns for every domain you add. A subdomain sender publishes its own record there rather than at the root's _dmarc.acme.com. If the subdomain has no record of its own, receivers checking DMARC on that subdomain typically fall back to whatever the root domain publishes, so an apex DMARC policy can still touch subdomain mail even when you don't intend it to. Publishing the subdomain's own record removes that dependency. See Publishing your DNS records for the record itself.