M3AAWG Sender Best Common Practices (Version 3.0)

The Messaging, Malware and Mobile Anti-Abuse Working Group (M³AAWG) Senders Committee publishes this Best Common Practices (BCP) document as the industry consensus baseline for sending commercial electronic messaging. Version 3.0 (February 2015) is a major rewrite of Version 2.0 (October 2011) with a stronger focus on address collection and data transparency, and it replaces both the earlier Sender Best Communications Practices and its Executive Summary.

The audience ranges from delivery/compliance professionals at ESPs and large senders to the marketing and management staff who approve mailing practices. The stated goal: promote transparency so that recipients and mailbox providers can distinguish legitimate messaging from abuse.

Two framing statements from the document:

M³AAWG categorically states that verifiably clear, conspicuous and informed opt-in subscriber consent is the best practice for messaging permission.

The end user and their expectations should be the highest priority. It does not matter what a sender is legally allowed to do or is granted the right to do under a privacy policy; what matters is that the recipient, their preferences and their expectations be respected.

At minimum, senders must comply with mailbox providers' Acceptable Use Policies and applicable national/regional law (CAN-SPAM, CASL, EU legislation — see the document's Appendix B).

Consent: the three levels of opt-in

The primary rule: the sender must have the explicit consent of the recipient prior to sending and prior to adding the recipient to any ongoing communications. Each level below builds on the previous one.

Level	Name	Mechanics
1	Single opt-in	User provides address; scheduled mailings begin. No notification, no confirmation of consent.
2	Single opt-in with notification (Better)	A notification/welcome message informs recipients they will receive messages. No confirmation of consent.
3	Confirmed opt-in (Best)	A confirmation message requires an affirmative action (click a link / reply) before any subscription messages are sent. Also called "double opt-in" or "closed-loop subscription."

Level 1 — Single opt-in requirements

Use with extreme caution: unconfirmed addresses (typos, outright forgeries) can be added unchecked, leading to complaints, bounces, and reputation degradation. If used:

1. The recipient must knowingly give consent when the address is collected.
2. Consent must be clear and obvious — not hidden in small type, legal jargon, or on a separate page.
3. The sign-up must clearly state the specific type of list(s) being joined; where possible let recipients pick which lists to be included in or excluded from. More recipient control = fewer abuse reports.
4. Notify recipients of the expected frequency and type of communications, with a choice in each. Unexpected frequency increases often lead to increased abuse complaints.
5. Use addresses only for the purposes disclosed at signup. A secondary purpose created later (e.g., a new newsletter with different content) requires a separate opt-in; it must not be opt-in by default. Judge "secondary purpose" from the recipient's point of view; some jurisdictions legally require this separate permission.
6. Consider showing a visual example of the email the subscriber will receive, so they recognize it on arrival.
7. Retain proof-of-consent data at collection time: IP address, date of collection, website/event where collection occurred, and (in large companies) which department collected the address and how. This must be readily accessible if consent must be proven to an individual, ISP, RBL operator, or regulator — subject to PII-storage law.

Level 2 — adds the notification message

8. Send the notification/welcome message immediately, or within 24 hours of submission. It should:
   • include the address submitted and any other information the user provided;
   • state the frequency and type of content;
   • use the same From address as future messages so recipients can add it to their address book;
   • if possible, be sent from IPs segmented from regular bulk sending IPs.

Level 3 — confirmed opt-in

9. The highest standard; prevents typos and maliciously submitted addresses from entering ongoing mailings. Additionally:
   • tell users at submission time to check their email and act on the confirmation message;
   • keep the confirmation email simple and free of advertising so it isn't filtered as abuse.

Implied (implicit) consent

Implied consent is inferred from interaction (classic case: an email address collected at point of sale with no notice that it means being added to marketing lists). It is not considered a best practice: it doesn't work for all senders and is likely to cause abuse complaints. If used, closely watch complaints/opens/clicks for that segment; better, add a distinct explicit-consent checkbox at collection, or run a permission pass / confirmation campaign before further marketing mail. Whatever method is used, keep per-address records of how each address got on the list: sign-up IP, timestamp, a screen capture of the disclosure language, and the privacy policies in force at subscription time.

Email append (epending)

Matching a customer record to an email address the customer never provided for that purpose is a direct violation of core M³AAWG values — abusive, complaint-generating, and a privacy/anti-spam legal risk. See the M³AAWG Position on Email Appending (updated 2019: https://www.m3aawg.org/sites/default/files/legacy/m3aawg_apending_position_update-2019-01.pdf).

Unsubscribe requirements

1. Make the unsubscribe process as clear and easy as reasonably possible.
2. Process all unsubscribe requests without delay (legal compliance and respect for the recipient).
3. Set expectations: state the processing timeframe and which list(s)/communication types are affected. The longer the removal timeframe, the more likely continued email is judged abusive and reported.
4. Be able to process email-based unsubscribe requests sent to the From and Reply-To addresses of outbound mail.
5. The unsubscribe link must contain everything needed to complete the unsubscribe: subscriber ID; which list (if multiple); per-user authentication tokens if needed to prevent malicious third-party unsubscribes.
6. Adopt the List-Unsubscribe header (RFC 2369) in every message:
   • mailto variant: an encoded per-recipient address; any message received there can be treated as an unsubscribe for that recipient even if not sent from the subscribed address.
   • URL variant: a link to the platform's unsubscribe function (may be the same link as in the body); encode any personal information in the link to prevent misuse and maximize ease of use.
7. Decide a policy for unsubscribes when no preference center can be shown: valid for all mail or one list? Best practice default: remove the recipient from all mail.
8. Use readable text descriptions (not images) next to one-click unsubscribe links.
9. Consider offline unsubscribe mechanisms (postal address, phone) — local/toll-free so cost to the individual is low or nil.
10. In a preference center with multiple options, the unsubscribe option should be pre-checked by default for the user's currently subscribed lists.
11. New subscription offers presented to returning subscribers must be un-checked by default.
12. Subscribers must be able to unsubscribe without logging in or facing any security challenge. A login-protected preference center is fine as an extra, but list-specific unsubscribe must work outside any secure area.
13. Strongly recommended: include the recipient's subscribed email address in the message body — especially useful when multiple addresses forward to one mailbox.

Data security

ESPs and senders storing subscriber PII should maintain a comprehensive security program using industry-standard practices. Starting points named: OWASP, SANS, the Online Trust Alliance "Data Protection and Breach Readiness Guide," ISO/IEC 27002:2013 (Access Control; Communications and Operations Management; Information Security Incident Management), and the U.S. FTC consumer-privacy report. M³AAWG very strongly recommends treating security as a primary consideration: stored email address data has value to criminals even when it is "only" email addresses.

Transparency of data (technical identity)

Transparency applies to the IPs and domains of sending servers and to links in the message body. When information is in the open, senders can be held accountable and receivers can identify and contact them about problem customers.

WHOIS

• Maintain accurate, up-to-date WHOIS (or rWHOIS) records for domains asserting responsibility for large volumes of mail.
• IP sub-allocations of /29 or larger (IPv4) and /56 or larger (IPv6) must be accurately and completely documented per RIR (e.g., ARIN) policy.
• Anonymous/proxy domain registration circumvents transparency — there is no compelling business case for intentionally vague WHOIS by entities that don't intend to abuse messaging networks.

Email authentication

Four forms listed: SPF (validates sending IP against Return-Path and HELO domains), Sender ID (PRA-based; no longer widely used), DKIM (cryptographic signature validated against a domain), and DMARC (sender-declared policy + visibility for mail failing SPF/DKIM in the From domain). See M3AAWG Email Authentication BCP and DMARC for current deployment guidance.

Technical IP details (forward DNS, reverse DNS, HELO)

Written for IPv4; intent is transparency of ownership and clear responsibility to reputation/filtering systems.

Forward DNS

• A name MUST be chosen that clearly identifies the responsible party's domain: the ESP/provider when the IP is shared, normally the customer/advertiser when dedicated (the customer's domain admin implements the forward DNS in that case).
• The name must clearly indicate a server, not generic pool space: server03.espname.com, not pool-dhcp-456.espname.com.
• If multiple names point to the same shared IP, the chosen name is the "primary name."
• Except for dedicated IPs, all mail servers of the ESP/advertiser must use the same name or a small set of names at the "domain registry level," differentiating with subdomains: use server1.espname.com, server2.espname.com — not espname01.com, espname02.com.

Reverse DNS

• Every sending IP must have reverse DNS (PTR/IN-ADDR) configured.
• Only one reverse DNS name per IP.
• It must exactly match the primary forward DNS name.

HELO/EHLO (factors into SPF authentication)

• Must be a resolvable hostname — a []-quoted IP literal is not acceptable.
• Dedicated IP: HELO MUST exactly match the primary forward DNS name.
• Shared IP / NAT to multiple servers: HELO must match the primary name at least at the domain-registry level; exact match is fine. Recommended: give each mail system or customer behind a NAT its own HELO subdomain (e.g., server01.brand1.espname.com) to aid diagnosis.

Shared vs. dedicated IP environments

Definitions:

• Dedicated environment: one distinct entity has exclusive use of and responsibility for the outbound mail through it (one or more IPs, exactly one responsible entity).
• Shared environment: more than one entity assigned to an IP or pool of IPs.
• An "entity" is the party responsible for sending the message — a company, a brand within it, or an ESP customer.

Reasons to choose dedicated:

• Mail/list quality unknown or below average — isolate it to protect others (or to establish/track its quality).
• Mail quality known to be above average — isolate it from others' ill effects.
• Control over volume patterns: mixing transactional + marketing or multiple entities creates irregular traffic; volume consistency plays an integral part in IP reputation, especially at free-mailbox providers, large domains, and small businesses hosted by large providers. (Volume consistency is not typically a useful metric for self-hosted small businesses making automated decisions.)
• The entity wants full responsibility, not attribution to the ESP, or needs unique outbound MTA settings.
• Certification/allowlisting or other enhanced deliverability services requiring a dedicated environment.

Reasons to choose shared:

• Combining volumes sustains a consistent average sending volume that establishes and maintains IP reputation.
• Reputation is shared, so any single sender's mistakes are diluted.
• Cheaper — makes mailing economically feasible for very small senders.

Provisioning guidance:

• Entities in a shared environment should have similar content and metrics (complaint and bounce rates); extra vetting diligence is needed because one entity's poor practices can "poison" the pool.
• DKIM-sign each entity's mail with a unique domain or subdomain in shared environments: lets receivers differentiate mail streams, enables per-entity DMARC participation, and lets an entity carry its earned reputation if re-provisioned.
• Best practice (acknowledged as hard): authenticate the ESP's domain and the individual entity's domain simultaneously.
• ESPs offering both models should define in advance the criteria for migrating an entity from shared to dedicated and monitor for fulfillment.
• Dedicated-IP best practices for ESPs: entity-specific reverse DNS (e.g., entity.cust.esp.com — readable attribution); a well-defined, consistently applied IP warm-up process; help entities get allowlisted where available; help entities keep a consistent average sending volume to accrete reputation.

See also Basic IP Allocation and Advanced IP Segmentation.

Vetting of clients (ESPs)

ESPs that send large volumes of email on behalf of their clients are at the mercy of their worst clients' worst practices.

• All ESPs must have a pre-send vetting process to proactively identify malicious senders before they mail.
• All ESPs must have a post-send vetting (monitoring) process after clients begin mailing.
• Good vetting distinguishes true spammers from customers who merely need list-hygiene guidance. Vetting is integral to reputation and abuse reduction.
• In-depth guide: M³AAWG Vetting Best Common Practices (https://www.m3aawg.org/sites/default/files/doc_files/MAAWG_Vetting_BCP_2011-11.pdf).

Complaint / feedback loop (FBL) handling

• ESPs receive complaints mainly via mailbox-provider feedback loops and directly to their abuse mailbox. They must have a system to handle both, plus a process to decide what to do with them.
• Complaints are a key factor in determining whether customers violate the sender's Terms and Conditions or are simply misbehaving.
• Reference: M³AAWG Feedback Reporting Recommendation; see M3AAWG document index for the FBL ecosystem (formats, provider list).

Forwarding services

If an ESP provisions smaller customers with addresses on the ESP's own sending domain (used in message headers), it may need to forward replies back to those customers — in that case it should run a proper mail forwarding service. Details: M³AAWG Email Forwarding Best Practices.

Bounce / NDR handling

Delivery is never guaranteed. A sending system must be able to receive and process returned mail at the same volume and rate that it sends — provision resources for both directions of SMTP traffic.

• Returns are usually synchronous (rejected during the SMTP conversation); less often asynchronous (a bounce message to the Return-Path address, possibly hours or days later). In practice about 95% of all returns occur synchronously. Senders must be able to identify which address bounced in order to process asynchronous returns correctly.
• Returns carry a numeric status code plus a descriptive message. RFC 5321 defines basic SMTP responses; RFC 3463 defines enhanced status codes. Status codes generally follow the RFCs, but descriptive text is receiver-customized and may only loosely follow them — senders must be able to process, categorize, and report on both.

Code class	Meaning	Sender action
2xx	Success — message accepted	None
4xx	Temporary failure — not accepted	Re-queue and retry later
5xx	Permanent failure — not accepted	Do not re-queue

Temporary failures (4xx): causes include a busy receiver or a receiver that detected unusual mailing characteristics and paused acceptance from the IP for a set time. Close the connection and retry later. Receivers of very large volume expect senders to adjust retry behavior in real time, wholesale for all mail from the same IP. Critically: some receivers deliberately tempfail an initial message to test RFC compliance — spammers generally don't retry, legitimate senders do. Never treat 4xx as permanent.

Permanent failures (5xx): most common is "user unknown"; many 5xx codes signal a policy violation per the descriptive text. Regardless of text, never retry the message.

Handling NDRs / list hygiene:

• 4xx/5xx codes tell the mail server what to do with the message but were not designed for list managers — they don't say whether to remove the address from the list. Read the descriptive text to decide per-address handling; it may also reveal infrastructure/content problems or that the sending IP is on a blocklist needing delisting before further mail gets through.
• If the receiver says the user doesn't exist, do not retry, and suppress the address from future mailings. Receivers use the volume of permanent failures as a reputation input; large volumes of hard bounces usually indicate a poorly managed registration process or an old/misapplied list, and subtract from an IP's reputation score.
• Recommended removal rule: drop an address that consistently bounces (any failure code/text) over multiple consecutive campaigns — generally, at least two consecutive bounces over two weeks or more, which allows for transient receiver-side server issues.

Glossary highlights (Appendix C, derived from RFC 5598)

Term	Definition (abridged)
Dedicated IP	Static IP sending only for one sender/company/brand, which is responsible for all its content; rDNS usually identifies the brand.
Shared IP	IP mailed from by many senders/brands/ESP customers, usually simultaneously; identified with the owning ESP.
Dirty mailing list	List with addresses from poor acquisition/opt-in practices and/or not kept up to date (poor hard-bounce or unsubscribe handling, or unmailed for a year+).
FBL	Mailbox-provider system giving qualified senders copies of messages their end users reported as spam, so senders can fix the causes.
Hard bounce	Permanent failure: address or domain no longer exists or never existed.
Soft bounce	Temporary failure: full mailbox, connection problem, provider technical issue, or throttling of the connecting IP to slow delivery.
Transactional messaging	Confirms a transaction or gives individual status information (bank alert, password change) — vs. bulk/marketing messaging.
Confirmation message	Sent to a new subscriber to notify and/or confirm that they want the mail (click or reply).

Related

• M3AAWG Email Authentication BCP
• M3AAWG document index — other M³AAWG sender/ESP documents and FBL resources
• Foundations of Email Deliverability
• Two Worlds of Email Deliverability
• IP Warm-Up Recommendations
• Advanced IP Segmentation and Allocation