M3AAWG Sending Domains Best Common Practices

Industry-consensus rules for choosing, segmenting, authenticating, delegating, and migrating the domains used to send bulk and transactional email.

Operationalesp-operatorsender

The M3AAWG consensus (senders, receivers, and anti-spam organizations jointly) on the domain-name half of preparing a sending program — the checklist ESPs re-run for every new client. It complements the IP-side guidance in IP management and the vendor-guide material in Sending Infrastructure Practices; this article carries the industry-standard positions and the DNS delegation mechanics.

Headline recommendation: when choosing a sending domain, a subdomain of the sender's organizational domain should be selected in almost all cases.

Choosing the domain: brand domain/subdomains vs. cousin domain

The choice reduces to two options:

Option	M3AAWG position
Main brand domain, or subdomains of that zone	Recommended — the main recommendation of the document
A newly procured, brand-related domain ("cousin domain")	Strongly discouraged

A cousin domain resembles the primary brand domain but has no direct DNS link with it — it may sit at a different registrar, different DNS host, different WHOIS. Cousin domains, especially when used for one-off mailings, look like phishing campaigns to users and anti-abuse systems alike, producing increased spam complaints and blocking/filtering, and they expose the brand to security issues while confusing users, employees, and security tools. (Cousin-domain monitoring — watching for others' abuse of lookalikes — is covered in Sending Infrastructure Practices.)

Using a subdomain of the main domain instead:

makes the sender easier to identify and is significantly less confusing to recipients and receiving systems;
signals active traffic segmentation/quality management, with a clear link between the brand and each domain's reputation;
lets the sending program benefit from the organizational domain's existing reputation (a brand-new cousin domain starts from zero).

Segmentation strategy

Receivers request — and may require — separation of different traffic types: bulk marketing, one-to-one prospection, transactional (welcome, order confirmation), monthly statements, etc. Best practice also separates traffic per business area — per country, per organizational department — for visibility, distinct reputations, and easier troubleshooting. Each separation requires a distinct subdomain, and in some cases distinct IP addresses too (the domain-level counterpart of Advanced IP Segmentation).

Constraint: every segment must be able to build and sustain its own reputation, which requires sufficient and relatively consistent traffic volume. Sending lapses or major volume fluctuations impair both forming and sustaining reputation — don't segment finer than your volume supports.

Selecting subdomain names

Assign a separate subdomain per distinct sending purpose; reserve the main domain for corporate mail (employee-to-employee, one-to-one external).
The subdomain name should be relevant to the traffic type — filtering may include human review, so "words matter":

Traffic type	Example subdomain
Marketing	`offers.mybrand.com`
Transactional	`info.mybrand.com`

Sending from a subdomain does not require the visible From: to use that subdomain — organizational-domain alignment suffices for authentication and abuse prevention (some use cases do warrant a matching visible From:).
The sender must have access to the inbox specified in the visible From: (see the anti-no-reply guidance in Sending Infrastructure Practices).
Distinct subdomains are best practice especially for bulk; for smaller volumes, differing local parts of the sender address on one domain is acceptable — judge by recipients, geographic diversity, and abuse-prevention needs.

Domain consistency across the message

Use a consistent organizational domain throughout the message: Return-Path (RFC5321.From), visible From: (RFC5322.From), and the DKIM d= signing domain. Aligning Reply-To with the organizational domain is good practice but not required.

Two acceptable patterns:

Header field	Same-subdomain pattern	Org-domain-aligned pattern
Return-Path	`bounce@news.mybrand.com`	`bounce@bounce.mybrand.com`
visible From:	`great@news.mybrand.com`	`service@mybrand.com`
DKIM `d=`	`news.mybrand.com`	`mybrand.com`

Alignment

The document uses relaxed alignment throughout (RFC 7489 §3.1): domains are relaxed-aligned when their organizational domains match.

visible From:	Return-Path	DKIM `d=`	Alignment
`great@news.mybrand.com`	`bounce@bounce.news.mybrand.com`	`news.mybrand.com`	Relaxed
`service@info.mybrand.com`	`bounce@bounce.mybrand.com`	`news.mybrand.com`	Relaxed
`great@news.mybrand.com`	`bounce@news.mybrand.com`	`news.mybrand.com`	Strict
`great@mybrand.com`	`bounce@brandofmine.com`	`brandofmine.com`	None

Domain reputation and ramp-up

Reputation builds quickly from sending activity on a subdomain and is used in filtering alongside content and IP reputation.
Unknown ≈ bad: a domain with no history gets extra scrutiny and caution; a domain with history lets the ISP deduce behavior quality over time. Proper subdomain use inherits benefit from the organizational domain's reputation.
Reputation attaches to the combination of elements, not the domain alone: switching sending domain (org→subdomain or vice-versa), switching sending IPs, or changing headers can each require a ramp-up for the new combination — relevant when restructuring an existing program, not just launching one.

Two phases: warm-up (unknown → noticed) then ramp-up (gradually reach planned long-term volume). Provider-specific strategies vary, but common rules:

Stay consistent — content characteristics and volumes should not vary abruptly.
Check SMTP logs to identify and triage in-flight delivery issues.
Register for data-supervision programs where available (Google Postmaster Tools; Netease and Chengxin for Chinese providers).
Start low and slow; consider ~6 weeks of warm-up as an average (day-by-day volume schedules are in Sending Infrastructure Practices and IP Warm-Up).
Monitor delivery placement and open rates per mailbox provider.

Setup checklist

Authentication

Each protocol stores its data in DNS TXT records checked by the receiver. See the deep articles for full mechanics; the sending-domain-specific points:

Protocol	Where the record lives	Key points
SPF	DNS zone of the Return-Path domain	e.g. TXT on `news.mybrand.com`: `v=spf1 include:_spf.example-esp.com ~all`
DKIM	Zone of the signing domain, at `<selector>._domainkey.<domain>`	Keys ≥ 1024 bits minimum; each sending subdomain should use a different selector (selectors limit blast radius of weak/stolen/old keys and let different senders hold their own private keys); rotate per the M3AAWG DKIM Key Rotation BCP
DMARC	TXT at `_dmarc.` of the visible From: domain	Policy on the organizational domain is the goal; a record on the subdomain is acceptable as an interim step. From: domain must align with a valid DKIM `d=` or a valid-SPF Return-Path domain

MX, role addresses, web presence

Every domain used in Return-Path, visible From:, Sender:, and Reply-To: should have a proper MX record pointing to a functional mail server.
abuse@ and postmaster@ must exist, be read, and never bounce.
Top domains or subdomains used in the visible From: should resolve or forward to a live, current web page related to the sender — users verifying legitimacy try the sending domain's website first.

DNS setup: three delegation models

The core of ESP customer-domain provisioning. Three options, in increasing order of ESP control:

1. Direct setup

The brand publishes records itself in its own zone — the only option when no third party (ESP) is involved. Known limitation: outdated registrar interfaces may be unable to publish DKIM records with stronger keys or specific characters.

Host	Type	Value
`news.mybrand.com.`	TXT	`v=spf1 include:spf.example-esp.com ~all`
`news.mybrand.com.`	MX	`0 bounce.example-esp.com`
`t.news.mybrand.com.`	A	`192.0.2.124` (tracking host)
`myselec._domainkey.news.mybrand.com.`	TXT	`k=rsa; p=MIGfMA0GCSq…`
`_dmarc.mybrand.com`	TXT	`v=DMARC1; p=reject; rua=mailto:dmarc-rua@mybrand.com`

2. CNAME delegation — preferred by ESPs

The brand publishes CNAMEs pointing into the ESP's zone, so the ESP can update record values transparently — e.g., rotate the DKIM public key without asking the customer to touch their zone. This overcomes direct-setup limitations while the brand keeps zone visibility.

Host	Type	Value
`news.mybrand.com.`	TXT	`v=spf1 include:_spf.example-esp.com ~all`
`news.mybrand.com.`	MX	`0 bounce.example-esp.com`
`t.news.mybrand.com.`	CNAME	`tracking.example-esp.com` (tracking host)
`myselec._domainkey.news.mybrand.com.`	CNAME	`myselec.news-mybrand.com.dkim.example-esp.com`
`_dmarc.news.mybrand.com`	CNAME	`dmarc.news-mybrand.com.example-esp.com`

(SPF and MX cannot be CNAMEs at the same node that holds other data, so those stay direct even in this model. CNAME chains also count against SPF's DNS-lookup limits.)

3. Nameserver (NS) delegation

The brand delegates the subdomain (and everything under it) to the ESP's nameservers:

Host	Type	Value
`news.mybrand.com.`	NS	`ns.example-esp.com`

Benefit: the ESP takes care of the entire DNS setup and guarantees the authentication configuration is correct. Drawback: the brand loses full visibility over the zone — a divestment of control requiring strong trust in the ESP.

Migration: switching ESPs or changing the sending domain

Consistency is key to domain reputation, so keep the chosen domain over time — reputation is built gradually and consistent sending patterns over time are paramount. When migrating (new ESP, or a domain change forced by a rename or policy):

Apply this document's concepts gradually and judiciously to an existing effective program; watch deliverability metrics through every configuration change.
Overlap period: both ESPs can send simultaneously by adding the new vendor's IPs to the SPF record and publishing its DKIM selector.
The MX record can point to only one vendor — during overlap, complaints and asynchronous bounces routed via MX may not reach the other vendor. Plan the migration around this data loss.
Complete full cutover only when sending cadence and volume with the new vendor are consistent and sustained at the desired long-term volume.

Sources

M3AAWG Sending Domains Best Common Practices, October 2019 (M3AAWG-130) — https://www.m3aawg.org/SendingDomsBCP