M3AAWG Sending Domains Best Common Practices

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. For guidance drawn from vendor guides, see 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:

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

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":

• 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).
• 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:

Alignment

The document uses relaxed alignment throughout (RFC 7489 §3.1). Two domains are in relaxed alignment when their organizational domains match.

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; 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 and 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:

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.

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.

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.

3. Nameserver (NS) delegation

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

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 (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), "Best Practices for Managing SPF Records" (Aug 2017), and "DKIM Key Rotation BCP" (Mar 2019). See the M3AAWG Document Index.

Related articles

• Sending Infrastructure Practices, including the four domains in a message and domain warm-up schedules
• Advanced IP Segmentation
• SPF, DKIM and DMARC