# M3AAWG Sender Best Common Practices (Version 4.0)

> Industry-consensus baseline for commercial senders and ESPs, version 4.0 (August 2026). Email authentication, bounce and feedback loop handling, domain warming and monitoring, IP and DNS identity, service monitoring, data security, WHOIS, opt-in levels, list bombing, unsubscribe rules and client vetting.

Source: emailmarketing.net — https://emailmarketing.net/learn/industry-best-practices/m3aawg-senders-bcp

If you send commercial email, or run an email service provider (ESP), this is the industry's agreed baseline for setting up your sending infrastructure, collecting consent, handling bounces and unsubscribes, and vetting clients. It is published by the Senders Committee of the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) as a Best Common Practices (BCP) document.

The current edition is *M3AAWG Sender Best Common Practices, Version 4.0 (August 2026)*, document M3AAWG-158, at https://www.m3aawg.org/senderbcp. It is a major rewrite that replaces Version 3.0 (February 2015) and Version 2.0 (October 2011), together with their executive summaries. Page references below are to the Version 4.0 PDF.

It is written for delivery and compliance professionals at ESPs and large senders, and for the marketing and management staff who approve mailing practices. It covers email only, and it states that it is not legal advice (Abstract, p.1). Its goal is **transparency**: recipients and mailbox providers should be able to tell legitimate mail from abuse (§1, p.2).

Two statements set the frame:

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

The conclusion (§6, p.22) adds that "the end user and their expectations should be the highest priority." What a law or a privacy policy allows matters less than what the recipient wants and expects.

At a minimum, senders must comply with mailbox providers' Acceptable Use Policies and with applicable national and regional law (§1, p.2; the regulatory resources are in Appendix B, p.25).

## What changed from Version 3.0

- **Structure.** Infrastructure now comes first, before address collection.
- **New guidance.** Domain reputation, warming and monitoring; IPv6; bringing your own IP addresses; monitoring of services; protocol security and personal data; list bombing; cold email.
- **New requirements tied to major mailbox providers.** SPF, DKIM and a passing DMARC result; one-click unsubscribe under RFC 8058; reverse DNS that exactly matches forward DNS.
- **Removed.** The Version 3.0 estimate of the share of synchronous bounces is gone. Sender ID, DomainKeys and Cisco's Identified Internet Mail are listed as deprecated (p.27).

Version 4.0 does not set complaint-rate or bounce-rate thresholds, retry schedules, retention periods, an unsubscribe deadline or an IP warm-up schedule. It does not address BIMI, ARC or AI-generated content.

## Infrastructure

### Email authentication

Authentication identifies the sender, so receivers can judge mail on the history of an authenticated domain and detect forgeries (§2.1, p.3). The document summarizes three mechanisms and points to the M3AAWG Email Authentication Recommended Best Practices (2020) for detail:

- **SPF** checks the sending IP address against the domain of the envelope sender (Return-Path).
- **DKIM** attaches a cryptographic signature that is checked against a domain in the headers.
- **DMARC** lets the owner of the From domain see who sends mail using it, and set a policy for mail that fails SPF and DKIM.

To meet the requirements of major mailbox providers, senders and their customers **must** send mail that has an SPF record for the envelope sender domain, carries a DKIM signature, has a DMARC record for the From domain, and passes DMARC through an aligned SPF or DKIM pass (pp.3–4). The other recommendations (p.4):

- Encourage customers to align both SPF and DKIM where they can.
- Check that customers' DNS records are correct at setup, and again periodically.
- Check at send time that each message will pass authentication, and fix it before sending if not.
- Sending platforms **must** sign with DKIM and authenticate with SPF using their own domain for customers who cannot authenticate their own.
- Sign with DKIM using both the platform's domain and the customer's domain, to benefit from DKIM-based feedback loops and reporting.
- Comply with all relevant RFCs.

See [M3AAWG Email Authentication BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-email-authentication-bcp) and [DMARC](https://emailmarketing.net/learn/authentication/dmarc) for deployment guidance.

### Bounce and NDR handling

Delivery is never guaranteed. A sending system **must** be able to receive and process returned mail, or non-delivery reports (NDRs), **at the same volume and rate at which it sends**, so plan resources for SMTP traffic in both directions (§2.2, p.4). ESPs should give customers the detailed NDR text, not only totals of "hard" and "soft" bounces, because customers need the real message to troubleshoot.

- Returns are usually **synchronous**: the receiver rejects the message during the SMTP conversation. Less often they are **asynchronous**: a bounce message arrives at the Return-Path address, possibly hours or days later. Most returns are synchronous, but the mix depends on the list, and business-to-business (B2B) mail can see more asynchronous bounces. Whichever way a bounce arrives, senders must be able to identify which address bounced.
- Returns carry a numeric **status code** and a **descriptive message**. RFC 5321 defines the basic SMTP replies, and RFC 3463 defines enhanced status codes. Codes generally follow the RFCs, but each receiver writes its own text, which may follow them only loosely. Senders must be able to process, categorize and report on **both**.

| Code class | Meaning | What the sender does |
|---|---|---|
| 2xx | Success: the message was accepted | Nothing |
| 4xx | Temporary failure: the message was not accepted | Put it back in the queue and retry later |
| 5xx | Permanent failure: the message was not accepted | Do **not** put it back in the queue |

**Temporary failures (4xx).** Causes include a busy receiver, or a receiver that noticed unusual patterns from an IP address and stopped accepting its mail for a while. Close the connection and try again later (p.5). The document leaves when and how often to retry to the sending software, but receivers of very large volumes expect senders to adjust in real time, for all mail from the same IP address at once. **Some receivers deliberately return a temporary failure, or greylist, a first message to see whether the sender follows the RFCs**, because spammers usually do not. Never treat 4xx as permanent.

**Permanent failures (5xx).** "User unknown" is the most common, and many 5xx replies describe a policy violation in their text. Whatever the text says, never retry the message.

**Handling NDRs for list hygiene** (pp.5–6):
- Status codes tell the mail server what to do with the message, but they were not designed for list managers and do not say whether to remove the **address**. Read the descriptive text to decide. It may also reveal a problem with infrastructure or content, or show that the sending IP address is on a blocklist and must be delisted before more mail gets through.
- Any organization sending large volumes **must** have a process for NDRs. If the receiver says the user does not exist, do not retry, and **suppress the address from future mailings**. Receivers use the volume of permanent failures as an input to reputation. Large volumes of hard bounces usually point to a badly managed registration process or to an old or misused list, and they lower an IP address's reputation score.
- Recommended removal rule: remove an address that keeps bouncing, with any failure code or text, over several consecutive campaigns. How many campaigns and over what period is the sender's choice, but the usual best practice is **at least two consecutive bounces over two weeks or more**, which allows for temporary server problems at the receiver.

### Complaint and feedback loop (FBL) handling

- ESPs receive most complaints through mailbox providers' automated **feedback loops**, and some directly at their abuse mailbox. They must have a system to handle **both**, and a process to decide what to do about them (§2.3, p.6).
- Complaints are a key factor in deciding whether customers break the sender's Terms and Conditions or are simply behaving badly.
- ESPs should join every automated feedback loop available to them, and monitor each one to confirm it keeps sending data.
- Reference: M3AAWG Recommendations for Senders Handling of Complaints. See the [M3AAWG document index](https://emailmarketing.net/learn/industry-best-practices/m3aawg-document-index) for the FBL ecosystem (formats, list of providers).

### Forwarding services

If an ESP gives smaller customers addresses on the ESP's own sending domain (used in message headers), it may need to forward replies to those customers. In that case, it should run a proper mail forwarding service (§2.4, p.6). For details, see M3AAWG Email Forwarding Best Common Practices, version 2 (https://www.m3aawg.org/documents/en/m3aawg-email-forwarding-best-common-practices-version-2).

### Domain reputation, warming and monitoring

Every domain name in a message, in the headers and in the body, contributes to the sender's reputation, and filters weigh it together with content and IP reputation (§2.5, p.6). A newly registered domain that sends a large volume soon after registration raises suspicion. So does an established domain that has never sent mail and suddenly sends a lot, because spammers use both tactics to avoid detection.

**Domain warming** (pp.6–7). A new domain has no sending history, and mailbox providers treat an unknown reputation with nearly the same caution as a bad one. Warming means raising volume gradually so providers can evaluate the mail. Warm a new subdomain too, even when the organizational domain already has a good reputation. The document calls artificial warming practices "not recommended" and possibly illegal. Its recommendations:

- Start with low volume and increase it slowly. It gives **6 weeks as an average** warm-up to consider, not a fixed rule.
- Spread each day's messages over the day rather than sending them in one batch.
- Send campaigns regularly until the domain is warmed up.
- Watch SMTP logs for deferrals and bounces. If deferrals spike, slow down for some or all receiving domains, and check that content and list are opt-in and engaged.
- Check reputation data for the domain and IP addresses with industry tools, and watch for spikes in unsubscribes and complaints.
- Watch opens and clicks. A large spike may be security appliances inspecting the mail, and continued spikes may need fixing. A drop may mean mail is going to the junk folder.

**Domain monitoring** (p.7). Keep monitoring domain reputation after warm-up. Appendix A (pp.24–25) lists tools, including Google Postmaster Tools, Microsoft SNDS, Yahoo Sender Hub, Sender Score, Cisco Talos, Google Safe Browsing, the Spamhaus DBL, SURBL and DNS Twist.

**Lookalike (cousin) domains** (pp.7–8). Avoid sending from domains that resemble your main brand domain, such as `example-promo.com` beside `example.com`. They teach users to trust variations of your domain, which makes phishing domains easier to believe, and each one multiplies the typo and homoglyph variants you have to watch. Register the obvious lookalikes defensively and do not send from them. Never use a cousin domain to get around reputation problems on your main domain: that is spammer behavior. Use a subdomain when you need to separate parts of the business. For the cases where lookalikes are acceptable for security purposes, M3AAWG has a separate best practices document.

**MX and A records, and landing pages** (p.8). Any domain used in the envelope sender or the From header should have an MX record. Some receivers refuse mail from a sending domain that has no valid A record. Every domain and subdomain in a message, including the click-tracking domain, should lead to the owner's organizational site or an anti-abuse page when typed into a browser.

**The customer's domain or the ESP's subdomain** (pp.8–9). ESPs should, wherever possible, have customers put their own domain or subdomain in the visible From header, so each customer builds its own reputation. Use subdomains named for the purpose of the mail, such as `offers.mybrand.com` for marketing and `info.mybrand.com` for transactional mail. Sending from the ESP's domain is a fallback for small senders who cannot change their DNS, and it is better than sending without authentication. In that case, the ESP should give each brand its own subdomain of a shared domain, such as `brand01.shared.esp.com`. One shared subdomain for all customers, or for each pool, is possible but not recommended, because it makes troubleshooting harder and hides the source of abuse.

**Consistency and alignment** (pp.9–10). Mailbox providers can use any domain in the message or the SMTP transaction to judge reputation: the envelope sender, the From header, the DKIM signing domain, the HELO name, the reverse DNS name, the Reply-To address and the links. Use one organizational domain or subdomain throughout, which DMARC may require anyway. Be careful with domains shared across senders, such as a click-tracking domain an ESP gives all its customers: if one sender gets it blocked, the others suffer too. Where unique domains are not possible, give each sender a unique subdomain. See [M3AAWG Sending Domains BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-sending-domains).

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

The IP guidance in the BCP is written for IPv4, and it is the minimum to follow (§2.6, p.10). Its intent is to make ownership transparent, and responsibility clear to reputation and filtering systems.

**Forward DNS** (pp.10–11)
- A name MUST be chosen that clearly identifies the domain of the responsible party: the **ESP or provider when the IP address is shared**, and normally the **customer or advertiser when it is dedicated** (in that case, the customer's domain administrator sets up the forward DNS).
- The name must clearly indicate a server, not generic pool space: `server03.espname.com`, not `pool-dhcp-456.espname.com`.
- If several names point to the same shared IP address, the chosen name is the "primary name."
- Except for dedicated IP addresses, all mail servers of the ESP or advertiser must use the same name, or a small set of names, at the "domain registry level", with subdomains to tell them apart: use `server1.espname.com` and `server2.espname.com`, **not** `espname01.com` and `espname02.com`.

**Reverse DNS** (p.11; see RFC 1912 on DNS operations)
- Every sending IP address must have reverse DNS (a PTR or IN-ADDR record) configured.
- Each IP address has only **one** reverse DNS name.
- It must **exactly match** the primary forward DNS name. Version 4.0 notes that major mailbox providers now require this for mail sent directly to them.

**HELO and EHLO** (p.11; these count in SPF authentication)
- The name must be a hostname that resolves. An IP literal in square brackets (`[]`) is not acceptable, except between internal mail servers.
- Dedicated IP address: the HELO name MUST exactly match the primary forward DNS name.
- Shared IP address, or NAT to several servers: the HELO name must match the primary name at least at the domain registry level; an exact match is fine. It is recommended to give each mail system or customer behind a NAT its own HELO subdomain (for example `server01.brand1.espname.com`), to help diagnosis.
- The domain used in the HELO name and reverse DNS should receive mail (an MX record and a mail server), with working `postmaster` and `abuse` addresses as RFC 5321 and RFC 2142 require. It should also have an A record and a web server that redirects to the owner's main domain.

**IPv6** (pp.11–12). Follow the IPv4 reverse DNS guidance as a minimum, keep valid PTR and MX records, and take extra care with domain reputation. A provider typically receives a /32, which it can divide into /48 or /64 networks for customers. The smallest allocation to give a customer is a /64. See [IPv6 Sending](https://emailmarketing.net/learn/operations/ipv6-sending).

**Bringing your own IP addresses** (p.12). Some providers let senders use IP addresses they own, which avoids warming new addresses and keeps the sender in control of its inventory. Few providers offer it. When they do:
1. Verify ownership and control of the addresses, through RDAP, a signed Letter of Authorization (LOA) or other means.
2. Accept no IPv4 range smaller than a /24.
3. The addresses must have a clean history.
4. Publish reverse DNS that points to the owner's domain, not the ESP's.
5. The previous provider must stop sending from the addresses before the new routing announcement completes.

See [IP Acquisition Diligence](https://emailmarketing.net/learn/esp-operations/ip-acquisition-diligence).

### Shared vs. dedicated IP environments

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

Reasons to choose **dedicated** (p.13):
- The quality of the mail or list is unknown or below average. Isolating it protects others, or lets you establish and track its quality.
- The quality of the mail is known to be above average. Isolating it protects it from the effects of others.
- Control over volume patterns. Mixing transactional and marketing mail, or several entities, creates irregular traffic, and **consistent volume is an integral part of IP reputation**, especially at free mailbox providers, large domains, and small businesses hosted by large providers. (Consistent volume is not usually a useful measure for small businesses that host their own mail and make automated decisions.)
- The entity wants full responsibility, rather than having its mail attributed to the ESP, or needs its own outbound MTA settings.
- Certification, allowlisting or other enhanced deliverability services that require a dedicated environment.

Reasons to choose **shared** (p.13):
- Combining volumes keeps an average sending volume consistent, which builds and maintains IP reputation.
- Reputation is shared, so the mistakes of any single sender are diluted.
- It costs less, which makes mailing economically possible for very small senders.

Guidance on provisioning (pp.13–14):
- Entities in a shared environment should have **similar content and metrics (complaint and bounce rates)**. Vetting needs extra care, because one entity's poor practices can "poison" the pool.
- In shared environments, **sign each entity's mail with DKIM using a unique domain or subdomain**. This lets receivers tell mail streams apart, allows each entity to take part in DMARC, and lets an entity keep the reputation it has earned if it is moved.
- Best practice, although the document admits it is hard: authenticate the ESP's domain **and** the individual entity's domain at the same time.
- ESPs that offer both models should define in advance the criteria for moving an entity from shared to dedicated, and monitor whether the criteria are met.
- Best practices for senders with dedicated IP addresses: reverse DNS specific to the entity (for example `entity.cust.esp.com`, which shows clearly who is responsible); a well-defined [IP warm-up](https://emailmarketing.net/learn/ip-management/ip-warm-up) process, applied consistently; help for entities to get allowlisted where that is possible; and help for entities to keep a consistent average sending volume, so that reputation builds up.

See also [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation) and [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation).

### Monitoring of services

Beyond checking that servers are up, a sender's platform should watch for signs of customer breaches, account takeovers, signup form abuse and reputation problems (§2.7, pp.14–15). ESPs are encouraged to combine automated rules with human review. The signals the document lists, which it says are not exhaustive:

- **Abnormal volume.** A customer sending **more than 40%** above its usual volume can be flagged. The cause may be an attacker, or a customer's mistake that calls for education.
- **Abnormal list growth.** A sudden jump after steady growth can mean compliance is slipping. Validate the added addresses.
- **Bounce rates for each mailbox provider.** Global rates show major problems. Rates for each provider reveal authentication failures, routing loops, missing or invalid PTR records, exceeded connection limits, and IP reputation or blocklist problems.
- **Authentication that does not comply** with the chosen mechanisms.
- **Sign-ins from unusual locations**, which can point to compromised accounts.
- **A missing unsubscribe link**, which matters under CAN-SPAM, CASL and the ePrivacy Directive, and for deliverability.
- **Unusual message sizes**, which can point to malware or harmful attachments.
- **Signup forms**: spikes in subscriptions for a customer, and the same address subscribed across several accounts.
- **Link redirects**: changes in click volume, many clicks on one recipient's links, and links flagged by anti-phishing vendors.
- **Content**: sudden changes or new URLs, abusive keywords, other anomalies, and hosted images with abusive content.

See [Outbound Monitoring](https://emailmarketing.net/learn/esp-operations/outbound-monitoring).

### Data security

Senders that store subscribers' addresses or other personal data are strongly encouraged to run a complete security program based on industry-standard practices (§2.8, pp.15–16). The document names OWASP and SANS as starting points, and the U.S. Federal Trade Commission (FTC) report on consumer privacy. Its Appendix A (p.24) adds the Online Trust Alliance "Data Protection and Breach Readiness Guide" and ISO/IEC 27002:2013 (Access Control; Communications and Operations Management; Information Security Incident Management). M3AAWG strongly recommends making security a primary consideration: stored email address data is valuable to criminals, even when it is "only" email addresses.

**Protocol security** (p.16). Encrypt every message stream in transit, whatever the type of sender. M3AAWG's TLS for Mail baseline covers opportunistic TLS, which remains open to machine-in-the-middle attacks. Its follow-up guidance covers DANE and MTA-STS, which give stronger assurance but tolerate faults less well. Images, videos and call-to-action links should all use HTTPS. Mailbox providers have suggested that resources without HTTPS can hurt reputation and placement. See [TLS Baseline](https://emailmarketing.net/learn/transport-security/tls-baseline) and [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts).

**Personal data** (pp.16–17). Which rules apply (GDPR, DPA, HIPAA and others) depends on where the sender's client is, where the recipient is or what nationality they have, and where the ESP operates. Links in a message, such as tracking, preference and unsubscribe links, get logged by network devices and servers, so they should hide the recipient's address and other personal data. Do not put personal data in a URL in clear text or in an easily reversed encoding such as base64. Use an encrypted value, or an identifier unrelated to the recipient that only the ESP can map. Landing pages should mask personal data they display (for example `a**z@example.com`), should not be easy to discover, and should use pseudonymization.

## WHOIS

- Keep accurate, up-to-date WHOIS (or rWHOIS) records for domains that take responsibility for large volumes of mail (§3, p.17).
- IP sub-allocations of **/29 or larger (IPv4)** and **/56 or larger (IPv6)** must be documented accurately and completely, as the policy of the Regional Internet Registry (RIR, for example ARIN) requires.
- **Anonymous or proxy domain registration defeats transparency.** Entities that do not intend to abuse messaging networks have no compelling business reason for deliberately vague WHOIS records.

## Consent: the three levels of opt-in

The address collection guidance applies to both marketing and transactional mail (§4, p.17). M3AAWG is also writing a separate best practices document on list maintenance.

The main rule: the sender must have the **explicit consent of the recipient before sending**, and before adding the recipient to any ongoing communications (§4.1, p.17). Each level below builds on the one before it.

| Level | Name | How it works |
|---|---|---|
| 1 | Single opt-in | The user provides an address, and scheduled mailings begin. No notification, and no confirmation of consent. |
| 2 | Single opt-in with notification (Better) | A notification or welcome message tells recipients they will receive messages. No confirmation of consent. |
| 3 | Confirmed opt-in (Best) | A confirmation message requires an action from the recipient (clicking a link or replying) **before any subscription messages are sent**. Also called "double opt-in" or "closed-loop subscription." |

### Level 1: Single opt-in requirements

Use single opt-in with extreme caution (p.18). Unconfirmed addresses, whether typos or outright forgeries, can be added without any check. That creates invalid consent, which leads to complaints, bounces and damage to reputation. If you use it:

1. The recipient must **knowingly** give consent when the address is collected.
2. Consent must be clear and obvious, not hidden in small print, legal jargon or on a separate page.
3. The sign-up must state clearly which specific type of list, or lists, the person is joining. Where possible, let recipients choose which lists to be included in or excluded from. The more control recipients have, the fewer abuse reports you receive.
4. Tell recipients the expected **frequency and type** of communications, and give them a choice of each. An unexpected increase in frequency often leads to more abuse complaints.
5. Use addresses **only for the purposes disclosed at signup**. A secondary purpose created later (for example, a new newsletter with different content) requires a separate opt-in, and it must **not** be opted into by default. Judge what counts as a secondary purpose from the recipient's point of view. Some jurisdictions legally require this separate permission.
6. Consider showing an example of the email the subscriber will receive, so that they recognize it when it arrives.
7. When the address is collected, consider keeping evidence of consent: the **IP address, the date of collection, and the website or event where it was collected**, and, in large companies, which department collected the address and how (p.19). This evidence should be easy to retrieve if you need to prove consent to an individual, an ISP, a blocklist (RBL) operator or a regulator, and the laws on storing personal data must be taken into account.

### Level 2: Adding the notification message

Send the notification or welcome message immediately, or within **24 hours** of the submission (p.19). It should:
- include the address submitted and any other information the user provided;
- be treated as a bounce if it bounces, with the address removed from the list;
- 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 IP addresses **kept separate from the regular bulk sending IP addresses**.

### Level 3: Confirmed opt-in

This is the highest standard (p.19). It stops typos and maliciously submitted addresses from entering ongoing mailings. In addition:
- when the user submits the form, tell them to check their email and act on the confirmation message;
- keep the confirmation email **simple and free of advertising**, so that it is not filtered as abuse;
- when a user changes their email address, confirm the new address in the same way.

See [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods).

### List bombing

In a list bombing attack, a script submits one victim's address to hundreds of signup forms, so confirmation and welcome messages flood the victim's mailbox until it stops working (§4.2, pp.19–20). Each form contributes little, so a single site rarely notices it is part of an attack. M3AAWG recommends layering several defenses:

1. A CAPTCHA the form cannot be submitted without.
2. Restrict which systems can submit to your backend, so the form cannot be mapped and automated.
3. Rate limits on repeated submissions from one IP address.
4. If you host many forms, watch for the same address being added to several of them.
5. For a service limited to one region, show the form only to IP addresses from that region.
6. A hidden field that only a bot would fill in; discard submissions that fill it.
7. A page-load timestamp or key; discard submissions that arrive too fast or without it.
8. Unusual field names, which scripts looking for common names miss.
9. Move a form that has been attacked to a new URL.
10. Consider adding the Form-Sub header proposed in an Internet-Draft (https://datatracker.ietf.org/doc/html/draft-levine-mailbomb-header-02) for receiving mailbox providers.

See [Subscription Bombing](https://emailmarketing.net/learn/esp-operations/subscription-bombing).

### Implied (implicit) consent

Implied consent is inferred from an interaction. The classic case is an email address collected at the point of sale without any notice that the address will be added to marketing lists. It is **not considered a best practice** and should be avoided where possible: it does not work for every sender, and it is likely to cause abuse complaints (§4.3, p.20).

If you use it, watch complaints, opens and clicks for that segment closely. It is better to add a distinct **unchecked** box for explicit consent when you collect the address, or to run a **permission pass (a confirmation campaign)** before sending more marketing mail. Whatever method you use, keep a record for each address of how it got on the list: the sign-up IP address, the time, a screenshot of the disclosure wording, and the privacy policies in force at the time of subscription. Data retention laws vary between jurisdictions.

### Email append (epending)

Matching a customer record to an email address that the customer never provided for that purpose is a **direct violation of core M3AAWG values** (§4.4, pp.20–21). It is abusive, it generates complaints, and it creates legal risk under privacy and anti-spam law. See the M3AAWG Position on Email Appending (updated 2019: https://www.m3aawg.org/sites/default/files/doc_files/m3aawg_apending_position_update-2019-01.pdf).

### Cold email

Version 4.0 summarizes M3AAWG's position on cold email in one paragraph (§4.5, p.21). It defines cold email as unsolicited mail from an otherwise legitimate business trying to start a relationship with someone who has no prior relationship with it, and it says M3AAWG views such email as abusive. For the full position, it refers to the separate M3AAWG Position on Cold Email: see [M3AAWG Position on Cold Email](https://emailmarketing.net/learn/reference/cold-email-position).

## Unsubscribe requirements

The list below follows the numbering in §4.6 (pp.21–22).

1. Make the unsubscribe process as clear and easy as reasonably possible.
2. Process **all** unsubscribe requests **without delay**, both to comply with the law and out of respect for the recipient.
3. Set expectations: state how long processing takes and which lists or types of communication are affected. The longer removal takes, the more likely it is that further email is judged abusive and reported.
4. Be able to process unsubscribe requests sent by email to the **From and Reply-To** addresses of your outbound mail.
5. The unsubscribe link should contain everything needed to complete the unsubscribe: the subscriber ID, which list (if there are several), and authentication tokens for each user if they are needed to stop third parties from unsubscribing people maliciously.
6. Use the **List-Unsubscribe header** (RFC 2369) in every message:
   - **mailto** version: an encoded address for each recipient. Any message received at that address can be treated as an unsubscribe for that recipient, even if it was not sent from the subscribed address.
   - **URL** version: a one-click link to the platform's unsubscribe function (it may be the same link as in the body). Encode any personal information in the link, to prevent misuse and make it as easy as possible to use.
   - **One-click unsubscribe**: to meet the updated requirements of major mailbox providers, senders "must implement one-click unsubscribe (List-Unsubscribe-Post)" as RFC 8058 describes. Version 3.0 did not require it. See [List-Unsubscribe](https://emailmarketing.net/learn/list-management/list-unsubscribe).
7. Decide on a policy for unsubscribes when no preference center can be shown: does the unsubscribe apply to all mail or to one list? The best practice default is to **remove the recipient from all mail**.
8. In a preference center with several options, the unsubscribe option should be **checked by default** for the lists the user currently subscribes to.
9. Use readable **text** descriptions, not images, next to one-click unsubscribe links.
10. Consider ways to unsubscribe offline (a postal address, a phone number), using local or toll-free numbers so that the cost to the individual is low or nothing.
11. Offers of new subscriptions shown to returning subscribers should be **unchecked** by default.
12. Subscribers **must be able to unsubscribe without logging in** or passing any security challenge. A preference center protected by a login is fine as an extra, but unsubscribing from a specific list must work outside any secure area.
13. **Strongly recommended:** include the recipient's subscribed email address in the message body. This is especially useful when several addresses forward to one mailbox. Take the laws on personal data into account when you do.
14. The subscriber's address "should not be visible within the unsubscribe link itself." Use an encoded reference instead of the address in clear text.

## 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 identify malicious senders before they send mail (§5, p.22).
- All ESPs **must** have a **post-send vetting** process, which monitors clients after they begin sending.
- Good vetting separates real spammers from customers who only need guidance on list hygiene. Vetting is essential to reputation and to reducing abuse.
- Detailed guide: M3AAWG Vetting Best Common Practices (https://www.m3aawg.org/sites/default/files/doc_files/MAAWG_Vetting_BCP_2011-11.pdf). See [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting).

## Glossary highlights (Appendix C, derived from RFC 5598)

| Term | Definition (shortened) |
|---|---|
| Dedicated IP | A static IP address that sends only for one sender, company or brand, which is responsible for all its content; its rDNS usually identifies the brand. |
| Shared IP | An IP address used by many senders, brands or ESP customers, usually at the same time; identified with the ESP that owns it. |
| Dirty mailing list | A list with addresses from poor acquisition or opt-in practices, or not kept up to date (poor handling of hard bounces or unsubscribes, or not mailed for a year or more), or both. |
| FBL | A mailbox provider's system that gives qualified senders copies of messages their users reported as spam, so the senders can fix the causes. |
| Hard bounce | A permanent failure: the address or domain no longer exists, or never existed. |
| Soft bounce | A temporary failure, caused for example by a full mailbox, a failed connection, a technical fault at the provider, or the provider **throttling the connecting IP address to slow delivery**. |
| Transactional messaging | Confirms a transaction or gives an individual status update (a bank alert, a password change), as opposed to bulk or marketing messaging. |
| Confirmation message | Part of confirmed opt-in: the new subscriber must click a link or reply, and is not added to the list without that action. |
| Confirmed opt-in | Also called double opt-in: the sender verifies that the owner of the submitted address asked to join, so nobody is subscribed without consent. |
| Subscription message or welcome email | Sent after signup, usually describing the content and frequency of the mailings; it should include an unsubscribe link. |

## Related articles

- [M3AAWG Email Authentication BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-email-authentication-bcp)
- [M3AAWG Sending Domains BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-sending-domains)
- [M3AAWG document index](https://emailmarketing.net/learn/industry-best-practices/m3aawg-document-index), which lists other M3AAWG documents for senders and ESPs, and FBL resources
- [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)
- [Two Worlds of Email Deliverability](https://emailmarketing.net/learn/strategy/two-worlds-of-email-deliverability)
- [IP Warm-Up Recommendations](https://emailmarketing.net/learn/ip-management/ip-warm-up)
- [Advanced IP Segmentation and Allocation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation)
- [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices)