---
title: "Subdomain or root domain"
description: "Why a sending subdomain is the safer default, what it isolates, and why verification never inherits from a parent domain."
---

> **For AI agents:** the complete documentation index is at [llms.txt](/docs/llms.txt). Append `.md` to any page URL for its markdown version.

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](/guides/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](/concepts/ip-pools).

## 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](/dns/overview) for the record itself.