The Sending Side: Permission, Infrastructure, and Reputation
This chapter examines the sender-side conditions that make authenticated email trustworthy in practice: recipient permission, clear expectations, list operations, infrastructure identity, and the way responsibility is shared with an Email Service Provider. The focus is not on adding more technical labels to a message, but on understanding what the sender must make observable and maintainable before a receiver can interpret those labels. By the end, you should be able to connect consent, unsubscribe and return handling, DNS identity, IP provisioning, vetting, and per-entity authentication to the quality of a mail stream.
A message can have an aligned DKIM signature and still arrive as an unwelcome surprise. A vendor can be authorized to send for a brand while using an IP whose identity is difficult to attribute. A shared platform can deliver one customer's excellent mail alongside another customer's complaints. These are not exceptions to the identity model; they are the operational conditions that determine what the identity means over time.
The sender side begins before the SMTP connection. It begins when someone gives an organization an address, decides what they expect in return, and later tries to stop or change that relationship. It continues through the names and domains attached to the sending infrastructure, the controls applied to vendors and customers, and the processes that respond when recipients or receivers say that something went wrong.
Recipient Permission Becomes Operational State
For bulk and marketing mail, M3AAWG identifies explicit consent as the best practice: the recipient should knowingly agree to receive messages at the address provided. The guidance distinguishes a basic single opt-in from confirmed opt-in, in which the recipient must take an affirmative action—such as clicking a confirmation link or replying—before being added to ongoing mailings. The value of confirmation is concrete. It prevents a typo or a maliciously submitted address from silently becoming part of a list that will continue to send.
Consent is not a vague feeling that a company may infer once and preserve forever. The sender guidance says the purpose of the messages should be clear at collection, along with their type and potential frequency. An address collected for product updates should not automatically become permission for a different newsletter simply because the organization later decides that the additional communication would be useful. From the recipient's point of view, the question is whether the arriving message matches the expectation created when the address was given.
That expectation affects the technical system through observable behavior. Recipients who do not recognize a message are more likely to report it as unwanted or abusive. Complaints then become part of the evidence available to senders, Email Service Providers, and mailbox providers. The exact effect of a complaint signal is not defined as one universal formula in the supplied standards, but the operational direction is clear: a sender that creates avoidable surprise is making its future mail harder to distinguish from abuse.
The same logic applies to implied consent. A customer may provide an address during a purchase without being told that it will be added to ongoing marketing. The sender may regard the relationship as obvious; the recipient may not. M3AAWG does not treat this as best practice and recommends watching the resulting complaints and engagement signals if an organization uses it, while working toward explicit consent. The important lesson is not that every mailing relationship has one perfect legal category. It is that the sender should test its assumption against what recipients were actually told and how they respond.
Unsubscribe is the other half of expectation management. A sender should make the process clear and easy, process requests without delay, and explain what will happen and when. A preference center may offer choices among several lists, but the recipient should not have to log in or complete a security challenge merely to stop a specific stream. M3AAWG also recommends the List-Unsubscribe mechanism in message headers and supports mail-based or URL-based paths that contain enough information to identify the subscription safely.
These details change the system's future state. If a recipient has requested removal but the sender's systems apply the change slowly, later messages can generate complaints even though the original subscription was legitimate. If a preference center makes the scope of removal unclear, the recipient may choose the broadest possible interpretation or continue reporting messages that appear not to respect the request. A sender that treats unsubscribe as a user-interface afterthought is allowing stale consent to remain active in its sending system.
Return handling adds another time-based distinction. A receiver may reject a message during the SMTP conversation, or the sender may later receive a bounce through the return-path. A 4xx status generally indicates a temporary failure for which the sender should queue and retry; a 5xx status indicates a permanent failure and normally should not be retried. The descriptive text can provide additional information about a policy, infrastructure, or reputation problem, so the sender needs to process more than the first digit of a code.
An address that repeatedly produces a permanent failure, especially an unknown-user response, should be suppressed rather than sent to again. A temporary failure should not be treated as proof that the address is invalid. Confusing these states can damage the mail stream in both directions: repeated retries to nonexistent addresses create avoidable volume, while suppressing a temporarily unavailable recipient discards a relationship that may still be valid. The sender must retain enough capacity to receive returns as well as send messages, because feedback cannot influence the system if it has nowhere to go.
The records behind these decisions matter as well. M3AAWG recommends keeping information about how each address entered a list, including the originating IP, time and date, collection context, and the disclosure language shown at signup. This is not a request to preserve every possible detail indefinitely. It is a recognition that a sender may later need to explain why a particular stream was considered permitted, investigate a complaint, or correct one segment without disturbing the rest of the list.
The diagram is not a catalogue of separate departments. It shows where state crosses an organizational boundary. The recipient owns the expectation that a message should be wanted. The sender or brand owns the purpose of the communication and the decision about which lists remain active. The ESP may operate the systems that execute that decision, but delegation does not erase the brand's responsibility for what it authorizes. The receiver observes the resulting stream and sends back signals that may reach either the brand or the provider.
Infrastructure Must Make Responsibility Legible
Once a sender has a legitimate reason to mail, the technical path should make responsibility easy to identify. M3AAWG recommends forward DNS names that identify the responsible party and indicate that the host is a mail server, reverse DNS for the sending IP, and resolvable HELO names. In a shared environment, the naming may identify the provider at the appropriate domain level and use subdomains to distinguish customers or systems. In a dedicated environment, the name can be specific to the entity that controls the IP.
These naming practices do not authenticate the message by themselves. SPF and DKIM provide the formal domain-level evidence described earlier. Clear forward DNS, reverse DNS, and HELO naming serve a different purpose: they make the sending infrastructure attributable to the people and organizations who must diagnose it. When a receiver or an abuse contact sees a problem, a name that clearly points to the responsible operator is more useful than an opaque pool label. Transparency supports communication and investigation even where it does not produce a DMARC result.
IP provisioning adds a reputational boundary. A dedicated environment gives one entity exclusive use of the outbound path and responsibility for its mail. That isolation can be useful when the quality of a sender's lists is unknown, when the sender needs control over volume, or when it wants its reputation assessed separately from an ESP. It can also support entity-specific DNS and MTA settings. But isolation is not a substitute for quality: a dedicated IP still needs warming, consistent volume, proper authentication, and active handling of complaints and bounces.
A shared environment has a different logic. Combining several entities can create a steadier overall volume and make sending economically feasible for smaller organizations. It also means that reputational consequences are shared. A sender with poor list practices can affect other entities in the pool; M3AAWG therefore recommends vetting customers and, where possible, grouping senders with similar content and complaint and bounce metrics. The aim is not to pretend that all customers are one sender. It is to keep the shared environment from becoming an attribution and quality bottleneck.
The choice between shared and dedicated infrastructure is consequently a choice about boundaries and costs. A dedicated path can isolate a sender's behavior but may make irregular or low volume more visible and require more operational work. A shared path can stabilize aggregate volume and lower cost but requires stronger platform governance because one customer's behavior can spill over to others. The supplied guidance does not establish that one environment is always better. It says that the environment should match the entity's quality, volume, control, and reputational needs.
Authentication should preserve that distinction among entities. In a shared environment, M3AAWG recommends using a unique domain or subdomain for each entity's DKIM responsibility. The receiver can then distinguish the individual streams that originate from one pool, and a customer can carry a domain-linked reputation if it later moves to another environment. An ESP may also consider signing with its own domain as well as the customer's aligned domain, allowing separate reputation assessments. Those signatures do not change the requirement that a valid aligned identifier must support the customer's visible From domain when the customer wants DMARC to pass.
The ESP's governance process is therefore part of deliverability. M3AAWG says large-volume providers need both pre-send and post-send vetting. Before a customer mails, the provider should identify practices that could create abuse; after mailing begins, it should monitor enough behavior to distinguish a malicious sender from a customer who needs help with list hygiene. Complaint handling and feedback-loop processing are not merely support functions. They are how the provider decides whether a customer is preserving or degrading the shared system.
This creates a chain of responsibility rather than a single owner. The brand decides what recipients were promised and which vendors may send. The ESP operates sending infrastructure and may control the pool, queue, and complaint process. The domain owner controls the DNS records that authorize and align identities. The receiver evaluates the resulting message and may use local reputation and filtering knowledge. A failure can cross several of these boundaries: a brand may authorize a vendor, the vendor may use an unaligned return-path, the shared IP may carry other customers' complaints, and a receiver may see only the final combination.
A concrete example makes the distinction clearer. Imagine a software company whose billing platform sends account notices through an ESP. The visible From address uses the company's domain, but the billing platform's DKIM signature is aligned only with the ESP's domain. The message may be authorized by contract and may contain accurate, useful information, yet it fails the domain relationship required for DMARC. The technical repair is an aligned authentication path. Now change the case: the signature is aligned, but the company's list includes old addresses that repeatedly bounce and recipients who were never told they would receive product promotions. Authentication may pass, but the sender-side operating problem remains. The two cases look similar from the recipient's mailbox but require different owners and different evidence.
The most useful sender-side model has three connected questions. First, was this communication expected? That points to consent, purpose, frequency, unsubscribe, complaints, and list hygiene. Second, can the receiver attribute the stream? That points to domain alignment, DNS names, IP boundaries, per-entity signatures, and vendor governance. Third, does the organization act on what it learns? That points to feedback loops, bounce classification, vetting, and the repair process.
These questions also clarify the role of reputation. Reputation is not a free-floating property that an organization can improve by moving to a different IP or changing a paragraph. It is built from repeated observations associated with identities and infrastructure: who sends, what recipients expect, how often mail fails, how complaints are handled, and whether the sender corrects problems. A different IP may change the attribution boundary, but it does not erase the sender's list or governance problems. A perfect authentication record may identify the sender more reliably without making an unwanted stream welcome.
By the time a message reaches a receiver, the sender has already created a large amount of hidden state: the source and purpose of each address, the current subscription status, the vendor responsible for the stream, the domain and IP identity presented to other systems, and the response rules for complaints and returns. Authentication exposes only part of that state. The sender's operational discipline determines whether the exposed identity corresponds to a mail stream that recipients and receiving systems can reasonably trust.
A pass or fail is therefore easier to interpret when it is placed beside the sender-side facts. The next useful judgment is not whether one signal is green, but whether the expectation, attribution, and authentication layers agree. If they do not, the operator should repair the layer that failed instead of changing all three at once. That combined model—what the recipient expected, who claims the domain, how the stream is identified, and what the receiver can observe—provides the basis for testing a message outcome without treating any single pass as a complete verdict.