# 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.

Source: emailmarketing.net — https://emailmarketing.net/learn/industry-best-practices/m3aawg-sending-domains

When you prepare a sending program, you have to decide which domains the mail will use, how to split traffic between them, and how to publish their DNS records. If you run an email service provider (ESP), you go through this checklist for every new client.

The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) Sending Domains Best Common Practices (BCP) records the consensus of senders, receivers and anti-spam organizations on these domain questions. For the IP side, see [IP management](https://emailmarketing.net/learn/ip-management/basic-ip-allocation). For guidance drawn from vendor guides, see [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices). This page covers the industry-standard positions and the mechanics of DNS delegation.

**Main recommendation:** when choosing a sending domain, select a subdomain of the sender's organizational domain **in almost all cases**.

## Choosing the domain: brand domain or subdomains, or a cousin domain

The choice comes down to two options:

| Option | M3AAWG position |
|---|---|
| Main brand domain, or subdomains of that zone | **Recommended**. This is the main recommendation of the document |
| A newly acquired domain related to the brand (a "cousin domain") | **Strongly discouraged** |

A **cousin domain** resembles the primary brand domain but has no direct DNS link with it. It may use a different registrar, a different DNS host and different WHOIS details. Cousin domains, especially when used for one-off mailings, **look like phishing campaigns to users and to anti-abuse systems alike**. They lead to more spam complaints, blocking and filtering. They also expose the brand to security issues, and confuse users, employees and security tools. [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices) covers monitoring for cousin domains, that is, watching for other people's abuse of look-alike domains.

Using a subdomain of the main domain instead:

- makes the sender easier to identify, and is much less confusing to recipients and receiving systems;
- shows that traffic is actively segmented and its quality managed, with a clear link between the brand and the reputation of each domain;
- lets the sending program benefit from the **existing reputation** of the organizational domain (a brand-new cousin domain starts from zero).

Version 4.0 of the [M3AAWG Sender Best Common Practices](https://www.m3aawg.org/senderbcp) (August 2026) carries this rule over to ESP customers. It strongly recommends that an ESP have each customer send from the customer's own domain or one of its subdomains. The ESP's domain is a fallback for small senders who cannot change their DNS, and even then the ESP should give each brand its own subdomain of the shared domain. A single subdomain shared by all customers, or by a whole pool, is not recommended: everyone on it shares one reputation, and abuse becomes hard to trace.

## Segmentation strategy

Receivers ask for, and may **require**, separation of different types of traffic: bulk marketing, one-to-one prospecting, transactional mail (welcome messages, order confirmations), monthly statements, and so on. Best practice also separates traffic by business area, such as by country or by department, for visibility, separate reputations and easier troubleshooting. Each separation needs a **distinct subdomain**, and in some cases distinct IP addresses too. This is the domain-level counterpart of [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation).

**Constraint:** every segment must be able to build and keep its own reputation, which requires **enough traffic volume, at a fairly consistent level**. Gaps in sending, or large swings in volume, make it harder both to build reputation and to keep it. Do not segment more finely than your volume supports.

## Selecting subdomain names

- Assign a **separate subdomain to each distinct sending purpose**. Keep the main domain for corporate mail (between employees, and one-to-one external mail).
- The subdomain name should be **relevant to the type of traffic**. 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. Alignment on the organizational domain is enough for authentication and abuse prevention, although some use cases do justify a matching visible From:.
- The sender must **have access to the inbox given in the visible From:** (see the guidance against `no-reply` addresses in [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices)).
- Distinct subdomains are best practice, especially for bulk mail. For smaller volumes, using different **local parts** of the sender address on one domain is acceptable. Decide based on the recipients, their geographic spread, and what abuse prevention needs.

## Domain consistency across the message

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

Two patterns are acceptable:

| 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](https://emailmarketing.net/learn/authentication/dmarc)). Two domains are in relaxed alignment 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 filters use it together with content and IP reputation.
- **An unknown domain is treated almost like a bad one.** A domain with no history gets extra scrutiny and caution. A domain with history lets the mailbox provider judge the quality of its behavior over time. A subdomain used properly benefits from the reputation of the organizational domain.
- Reputation attaches to the **combination** of elements, not to the domain alone. Switching the sending domain (from the organizational domain to a subdomain, or the reverse), switching sending IP addresses, or changing headers can each require a **ramp-up for the new combination**. This matters when you restructure an existing program, not only when you launch one.

There are two phases: **warm-up**, where the domain goes from unknown to noticed, and then **ramp-up**, where volume gradually reaches the planned long-term level. Strategies vary by provider, but some rules are common:

- Stay consistent. Content characteristics and volumes should not change abruptly.
- Check SMTP logs to find and deal with delivery issues while sending is under way.
- Register for data programs where they exist (Google [Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools); Netease and Chengxin for Chinese providers).
- Start low and go slowly. Plan for **~6 weeks of warm-up as an average** (daily volume schedules are in [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices) and [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)).
- Monitor placement and open rates **for each mailbox provider**.

## Setup checklist

### Authentication

Each protocol stores its data in DNS TXT records that the receiver checks. The protocol references cover the full mechanics. The points specific to sending domains are:

| Protocol | Where the record lives | Key points |
|---|---|---|
| [SPF](https://emailmarketing.net/learn/authentication/spf) | DNS zone of the **Return-Path domain** | For example, TXT on `news.mybrand.com`: `v=spf1 include:_spf.example-esp.com ~all` |
| [DKIM](https://emailmarketing.net/learn/authentication/dkim) | Zone of the signing domain, at `<selector>._domainkey.<domain>` | Keys of at least **1024 bits**. **Each sending subdomain should use a different selector**: separate selectors limit the damage from weak, stolen or old keys, and let different senders hold their own private keys. Rotate keys as the M3AAWG DKIM Key Rotation BCP describes |
| [DMARC](https://emailmarketing.net/learn/authentication/dmarc) | TXT at `_dmarc.` of the **visible From: domain** | The goal is a policy on the **organizational domain**. A record on the subdomain is acceptable as an interim step. The From: domain must align with a valid DKIM `d=` **or** with a Return-Path domain that passes SPF |

### MX, role addresses, web presence

- Every domain used in the **Return-Path, visible From:, Sender: and Reply-To:** should have a **proper MX record that points to a working mail server**.
- **`abuse@` and `postmaster@` must exist, be read, and never bounce.**
- Top-level domains or subdomains used in the visible From: should **resolve or redirect to a live, current web page** related to the sender. Users who want to check that a message is legitimate try the sending domain's website first.

## DNS setup: three delegation models

This is the core of setting up customer domains at an ESP. There are three options, in increasing order of ESP control:

### 1. Direct setup

The brand publishes the records itself, in its own zone. This is the only option when no third party (such as an ESP) is involved. A known limitation: **outdated registrar interfaces may be unable to publish DKIM records with stronger keys or with certain 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 CNAME records that point into the ESP's zone, so the ESP can **update record values without involving the brand**. For example, it can rotate the DKIM public key without asking the customer to change their zone. This overcomes the limitations of direct setup while the brand keeps visibility of its zone.

| 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 records cannot be CNAMEs at a node that holds other data, so they stay direct even in this model. CNAME chains also count against [SPF's DNS-lookup limits](https://emailmarketing.net/learn/authentication/spf).

### 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` |

The benefit: the ESP handles the entire DNS setup and guarantees that the authentication configuration is correct. The drawback: the brand **loses full visibility of the zone**. It gives up control, which requires **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 builds gradually, and consistent sending patterns over time matter most. When you migrate (to a new ESP, or to a new domain because of a rename or a policy change):

- Apply these practices to an existing, effective program **gradually and with care**, and watch deliverability metrics through every configuration change.
- **Overlap period**: both ESPs can send at the same time if you add the new vendor's IP addresses to the SPF record and publish its DKIM selector.
- **The MX record can point to only one vendor.** During the overlap, complaints and asynchronous bounces routed through MX may not reach the other vendor. Plan the migration around this loss of data.
- Complete the switch **only when sending cadence and volume with the new vendor are consistent and sustained at the desired long-term volume**.

## Related M3AAWG documents

This BCP refers to the [Senders BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-senders-bcp) (v3.0, Feb 2015; since replaced by Version 4.0, August 2026, which points back to this BCP for domain usage), "Trust in Email Begins with Authentication" (Feb 2015, summarized in [Email Authentication BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-email-authentication-bcp)), "Best Practices for Managing SPF Records" (Aug 2017), and "DKIM Key Rotation BCP" (Mar 2019). See the [M3AAWG Document Index](https://emailmarketing.net/learn/industry-best-practices/m3aawg-document-index).

## Related articles

- [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices), including the four domains in a message and domain warm-up schedules
- [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation)
- [SPF](https://emailmarketing.net/learn/authentication/spf), [DKIM](https://emailmarketing.net/learn/authentication/dkim) and [DMARC](https://emailmarketing.net/learn/authentication/dmarc)