MWMS Email Deliverability And Sender Reputation Governance Framework
System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.0
Primary Location: MCR
Parent Page: Content Brain
Authority: MWMS HeadOffice
Owner: Martyn
Last Reviewed: 2026-07-19
Applies To: newsletters, scheduled campaigns, lifecycle emails, transactional communications, retention messaging, reactivation messaging, and future owned email systems
Primary Brain: Content Brain
Supporting Brains: Ecommerce Brain, Customer Brain, Data Brain, Compliance Brain, Infrastructure Brain, Automation Brain, Finance Brain, Ads Brain, Sales Brain, Affiliate Brain, AIBS Brain
Developer Boundary: No Development Action Authorized By This Page
Source Of Truth: MCR
Source Origin: Durable deliverability, list quality, technical setup, campaign governance, lifecycle messaging, and sender reputation intelligence absorbed from Sam Piliero The Facebook Ads Blueprint bonus Email Marketing module by Max Sturtevant, combined with existing MWMS source quality, lifecycle messaging, communication pressure, consent, and publishing governance standards
Purpose
The MWMS Email Deliverability And Sender Reputation Governance Framework defines how MWMS protects the ability of approved email communications to reach intended recipients reliably, lawfully, and without degrading sender reputation.
Deliverability is not merely whether an email platform reports that a message was sent.
Deliverability depends on:
• sender identity
• domain authentication
• permission quality
• list quality
• engagement quality
• complaint behaviour
• bounce behaviour
• sending patterns
• message relevance
• communication pressure
• content quality
• technical configuration
• suppression discipline
• lifecycle conflict prevention
• evidence quality
• monitoring
• intervention
• revalidation
The purpose of this framework is to:
• protect sender reputation
• improve inbox placement confidence
• reduce spam complaints
• reduce hard and soft bounce exposure
• improve list hygiene
• prevent communication to invalid or unsuitable recipients
• strengthen consent traceability
• prevent overcommunication
• improve the reliability of newsletter, campaign, lifecycle, and transactional email systems
• separate deliverability evidence from vanity metrics
• support controlled remediation when performance declines
• prevent platform-specific procedures from becoming permanent Canon
• preserve long-term owned audience access
• reduce reputational and compliance risk
• improve economic interpretation of email performance
Deliverability is an operating governance function.
It is not a one-time technical setup task.
Scope
This framework applies to:
• marketing email
• newsletters
• scheduled campaigns
• promotional email
• educational campaigns
• lifecycle flows
• welcome sequences
• checkout abandonment
• browse abandonment
• post-purchase communication
• replenishment messaging
• reactivation and winback
• transactional email
• product updates
• affiliate email
• client email systems
• future AIBS email systems
• email sender domains
• authentication records
• dedicated and shared sending domains
• sender identity
• consent records
• subscriber status
• suppression status
• bounce handling
• complaint handling
• unsubscribe handling
• list hygiene
• inactive subscriber management
• sending volume
• sending cadence
• domain warming
• reputation monitoring
• deliverability testing
• incident response
• remediation
• revalidation
This framework does not govern:
• newsletter editorial production
• campaign copywriting
• lifecycle sequence architecture
• landing page design
• paid traffic bidding
• tool-specific DNS instructions
• provider-specific interface steps
• one platform’s deliverability score as final truth
• autonomous sending
• automatic removal of subscribers without policy
• technical implementation without authorised infrastructure review
Those remain governed by the relevant Content Brain, Ecommerce Brain, Infrastructure Brain, Compliance Brain, Data Brain, Automation Brain, and operational procedures.
Definition / Rules
Core Principle
Email deliverability is earned through consistent identity, valid permission, relevant communication, controlled sending behaviour, clean data, and fast response to negative signals.
A technically authenticated sender may still have poor deliverability.
A high open rate may coexist with poor sender reputation.
A successful send does not prove successful inbox placement.
A platform-reported delivery event does not prove that the message reached the primary inbox.
MWMS must treat deliverability as a confidence system built from multiple signals.
Deliverability Governance Model
MWMS uses the following deliverability governance model:
1. Sender Identity Layer
2. Authentication Layer
3. Permission And Consent Layer
4. List Quality Layer
5. Engagement Quality Layer
6. Communication Pressure Layer
7. Content And Message Integrity Layer
8. Sending Behaviour Layer
9. Bounce And Complaint Layer
10. Reputation Monitoring Layer
11. Deliverability Incident Layer
12. Remediation And Revalidation Layer
13. Economic Interpretation Layer
14. Human Approval And Change Control Layer
1. Sender Identity Layer
Every email system must have a defined sender identity.
Required identity fields include:
• sending brand
• sending domain
• from name
• from address
• reply-to address
• channel purpose
• message type
• business owner
• operational owner
• compliance owner
• provider
• authentication status
• sending reputation status
• issue status
• last reviewed date
Sender identity must remain stable enough for recipients and mailbox providers to recognise the sender.
The system must prevent:
• frequent unexplained from-name changes
• frequent from-address changes
• misleading sender names
• unauthorised use of third-party domains
• reply-to addresses that are not monitored
• sending from personal or unrelated domains without approval
• mixing unrelated brands under one sender identity without governance
Brand Recognition Rule
Sender identity should help recipients understand:
• who is sending
• why they are receiving the message
• how to reply
• how to manage preferences
• how to unsubscribe
Sender identity must not be deceptive.
2. Authentication Layer
Email systems should use appropriate authentication standards.
Relevant controls may include:
• SPF
• DKIM
• DMARC
• aligned sending domains
• custom tracking domains
• bounce domain alignment
• provider verification
• sending subdomain separation
• reporting addresses
• authentication monitoring
The framework is tool neutral.
It does not prescribe one provider-specific setup sequence.
Authentication Requirements
Authentication must:
• identify authorised sending systems
• protect against spoofing
• support domain alignment
• support mailbox provider trust
• support monitoring
• be documented
• be reviewed after provider or infrastructure changes
Authentication records must not be changed casually.
Changes require:
• owner
• reason
• planned effect
• risk assessment
• validation
• rollback plan
• post-change review
Authentication Failure Rule
If authentication is missing, misaligned, failing, or materially uncertain, the system must reduce sending confidence.
High-risk sending should be paused until the issue is understood.
3. Permission And Consent Layer
Deliverability depends on valid, expected, and traceable permission.
Consent records should preserve:
• channel
• signup source
• timestamp
• consent wording
• consent version
• geography
• method
• double opt-in status where used
• customer or prospect status
• withdrawal status
• preference
• frequency expectation
Email and SMS consent must remain distinct where required.
One channel opt-in must not be assumed to authorize another.
Expectation Alignment
The recipient should understand:
• what they signed up for
• who will contact them
• what type of content they will receive
• how often they may receive it
• how to unsubscribe
• how preferences may be changed
Consent obtained through misleading, hidden, coerced, or unclear mechanisms is not acceptable.
Permission Drift
The system must detect when actual sending behaviour no longer matches the original signup promise.
Examples include:
• newsletters becoming frequent promotions
• a product alert becoming general marketing
• one brand sending for another brand
• educational signup becoming high-pressure sales
• email-only consent being used for SMS
• low-frequency promise becoming daily sending
Permission drift increases complaints and reputation risk.
4. List Quality Layer
List quality is a primary deliverability control.
The system must evaluate:
• valid addresses
• invalid addresses
• hard bounces
• repeated soft bounces
• role-based addresses
• temporary addresses
• typo risk
• duplicate addresses
• spam traps
• bot or fraudulent signups
• inactive subscribers
• complaint history
• source quality
• incentive dependency
• customer quality
• engagement quality
• consent quality
List Growth Relationship
High subscriber volume does not prove high list quality.
A capture source may appear successful while producing:
• low engagement
• high complaints
• high unsubscribe
• low purchase quality
• high discount dependency
• invalid addresses
• short-lived accounts
• bot traffic
• poor sender reputation
List growth must be evaluated downstream.
Purchased And Unverified Lists
MWMS must not use purchased, scraped, rented, or otherwise unverified lists unless a lawful, explicit, and separately approved basis exists.
Default rule:
Purchased, scraped, and unverified lists are prohibited.
List Hygiene
List hygiene may include:
• invalid address removal
• duplicate merging
• bounce suppression
• complaint suppression
• unsubscribe suppression
• inactive segment review
• preference review
• source quality review
• bot removal
• role-address review
• test record removal
• employee record separation
Removal, suppression, and retention decisions must be governed and traceable.
5. Engagement Quality Layer
Engagement is a deliverability signal.
Relevant engagement signals may include:
• opens
• clicks
• replies
• site visits
• purchases
• conversions
• saves
• forwards
• preference updates
• message movement
• inactivity
• deletion without reading
• spam marking
• unsubscribes
Open Rate Caution
Open rate is directional only.
It may be distorted by:
• privacy protections
• image loading
• device behaviour
• provider scanning
• proxy opens
• bot activity
• preview panes
MWMS must not use open rate alone to determine engagement or list health.
Stronger engagement evidence may include:
• clicks
• replies
• purchases
• preference updates
• repeated site activity
• confirmed customer actions
Engagement Segmentation
The system may classify recipients as:
• highly engaged
• recently engaged
• occasionally engaged
• declining
• inactive
• reactivation candidate
• deliverability risk
• suppressed
Classification must be evidence-based.
6. Communication Pressure Layer
Communication pressure affects engagement, complaints, unsubscribes, and sender reputation.
The system must account for total communication across:
• newsletters
• campaigns
• lifecycle flows
• transactional email
• support messages
• SMS
• push notifications
• community notifications
One team must not evaluate one message in isolation where the recipient is receiving many others.
Pressure Review Questions
Before sending, ask:
• How many recent messages has this recipient received?
• Is the message materially relevant?
• Is the recipient already in an active lifecycle flow?
• Is the recipient dealing with a support issue?
• Has the recipient recently purchased?
• Is the message repetitive?
• Are complaint or unsubscribe rates rising?
• Is the promotion still relevant?
• Does the recipient fit the segment?
• Does the message match the signup promise?
One universal frequency rule must not become Canon.
Frequency must be calibrated by evidence.
7. Content And Message Integrity Layer
Content quality affects deliverability indirectly and sometimes directly.
Risk factors include:
• misleading subject lines
• false urgency
• false scarcity
• deceptive sender identity
• broken links
• link shorteners
• inconsistent branding
• excessive image dependence
• unreadable formatting
• hidden text
• poor mobile rendering
• suspicious claims
• misleading promotions
• excessive capitalisation
• excessive punctuation
• copied content
• malicious or compromised links
• unsupported financial, medical, or legal claims
The system must not reduce deliverability governance to a list of “spam words.”
Message quality is contextual.
Subject Line Integrity
The subject line must match the body.
A misleading subject line may increase opens temporarily while damaging:
• trust
• complaints
• unsubscribe
• sender reputation
• future engagement
Preview Text Integrity
Preview text must support the subject line and accurately describe the message.
Link Integrity
Every send should validate:
• destination
• HTTPS status
• redirect behaviour
• domain ownership
• tracking behaviour
• affiliate disclosure
• landing-page availability
• offer accuracy
• expiry status
Broken, suspicious, or misleading links increase risk.
Image Independence
The email should remain understandable when images do not load.
Essential information must not exist only inside images.
8. Sending Behaviour Layer
Mailbox providers evaluate sending patterns.
Relevant controls include:
• sending volume
• sending consistency
• sudden spikes
• domain age
• reputation history
• recipient quality
• segment size
• engagement level
• complaint level
• bounce level
• authentication
• content consistency
• provider changes
• IP reputation where relevant
Sudden Volume Change
Major increases in sending volume may create risk.
Before a major increase, consider:
• domain reputation
• list quality
• engagement
• segment quality
• campaign reason
• prior send history
• authentication
• provider capability
• infrastructure readiness
Volume must not be increased merely because a larger list is available.
Domain Warming
New or materially changed sending environments may require controlled volume growth.
Warming should prioritise:
• highest-quality recipients
• recent engagement
• valid permission
• consistent message type
• gradual increase
• complaint monitoring
• bounce monitoring
• authentication validation
No universal warming schedule should become permanent Canon.
Provider Migration
A provider migration may affect:
• authentication
• tracking domains
• bounce handling
• suppression
• reputation
• templates
• links
• reply handling
• unsubscribe handling
• event history
Migration requires a controlled plan and post-change validation.
9. Bounce And Complaint Layer
Bounce and complaint signals require immediate governance.
Hard Bounce
A hard bounce generally indicates a permanent delivery failure.
Hard-bounced addresses should be suppressed according to policy.
They must not remain in routine sending.
Soft Bounce
A soft bounce may indicate a temporary issue.
Repeated soft bounces require review.
One temporary failure must not automatically equal permanent suppression where evidence is insufficient.
Spam Complaint
A spam complaint is a high-risk signal.
Complaining recipients must be suppressed promptly.
Complaint analysis should review:
• source
• campaign
• message
• frequency
• signup promise
• consent
• segment
• incentive
• sender identity
• recent pressure
• technical issue
Unsubscribe
Unsubscribe must be respected.
The system must not:
• hide unsubscribe options
• delay suppression without justification
• resubscribe without valid permission
• continue marketing after withdrawal
• make preference management misleading
Complaint And Bounce Rates
No single universal threshold should become permanent Canon.
Thresholds may vary by:
• provider
• region
• list size
• message type
• business model
• historical baseline
MWMS should define operating thresholds in implementation standards, not this framework.
10. Reputation Monitoring Layer
Deliverability should be monitored using multiple sources.
Possible signals include:
• provider delivery reports
• bounce rate
• hard bounce count
• soft bounce count
• complaint rate
• unsubscribe rate
• click rate
• reply rate
• inbox placement testing
• domain reputation
• IP reputation where relevant
• authentication reports
• DMARC reports
• blocklist monitoring
• spam-folder placement
• engagement trend
• volume trend
• source quality
• segment quality
• sending latency
• throttling
• provider warnings
No one dashboard should be treated as complete truth.
Reputation Status
The system may classify sender reputation as:
• Healthy
• Stable
• Watch
• At Risk
• Critical
• Unknown
Every status should include:
• evidence
• owner
• review date
• current risks
• actions
• confidence
• revalidation date
11. Deliverability Incident Layer
A deliverability incident exists when there is credible evidence of:
• authentication failure
• domain reputation decline
• unusual bounce increase
• unusual complaint increase
• blocklisting
• spam-folder increase
• major engagement decline
• suppression failure
• unsubscribe failure
• sending to invalid recipients
• unauthorised sending
• compromised links
• unexpected volume spike
• provider suspension or warning
• duplicated sends
• cross-brand sending error
• lifecycle conflict causing excessive pressure
Incident Classification
Incidents may be classified as:
• Low
• Moderate
• High
• Critical
Critical incidents may include:
• sending after unsubscribe
• unauthorised list use
• compromised domain
• major authentication failure
• widespread duplicate sending
• material blocklisting
• high complaint event
• sending to an unverified list
• provider suspension
Incident Response
An incident response should define:
• detection time
• affected sender
• affected domain
• affected campaigns
• affected segments
• evidence
• probable cause
• immediate containment
• sending status
• owner
• remediation
• stakeholder notification
• validation
• reopening criteria
• final review
The system must prefer containment over continued sending when critical evidence exists.
12. Remediation And Revalidation Layer
Remediation may include:
• pausing sends
• reducing volume
• narrowing to engaged recipients
• fixing authentication
• fixing suppression
• removing invalid addresses
• removing duplicates
• revising consent handling
• revising signup promise
• revising frequency
• revising segments
• revising subject lines
• revising content
• fixing links
• reviewing providers
• reviewing tracking domains
• reviewing list sources
• repairing reply handling
• revalidating unsubscribe
• rewarming a sender
• moving high-risk traffic away from core domains where authorised
A remediation action must have:
• reason
• owner
• start date
• expected effect
• success condition
• evidence
• review date
• rollback or alternative
Revalidation
Deliverability systems should be revalidated when:
• provider changes
• sending domain changes
• authentication changes
• list source changes
• traffic source changes
• major campaign launches
• volume changes
• complaint rates rise
• bounce rates rise
• engagement declines
• consent language changes
• lifecycle architecture changes
• suppression logic changes
• tracking changes
• sender identity changes
• brand ownership changes
13. Economic Interpretation Layer
Deliverability performance must be interpreted economically.
The system should consider:
• revenue
• contribution margin
• refund rate
• complaint cost
• unsubscribe cost
• list attrition
• sender reputation cost
• customer support burden
• reactivation cost
• replacement acquisition cost
• downstream retention
• customer quality
A campaign with strong revenue and severe complaint or reputation damage may be strategically poor.
A smaller send to a high-quality segment may outperform a larger send economically.
Platform-attributed revenue must not be treated as unquestioned incremental profit.
14. Human Approval And Change Control Layer
High-impact deliverability changes require human approval.
Changes requiring review may include:
• new sending domain
• provider migration
• authentication change
• major volume increase
• new list source
• new consent mechanism
• suppression logic change
• reactivation of inactive subscribers
• use of a previously unused database
• new affiliate list
• cross-brand sending
• change in from-name or from-address
• dedicated IP change where relevant
• new transactional provider
• rewarming plan
No technical implementation is authorised by this framework alone.
Deliverability Record Standard
Each sender or email system should maintain:
• Sender Record ID
• Brand
• Domain
• Sending Subdomain
• Provider
• From Name
• From Address
• Reply-To Address
• Message Types
• Owner
• Compliance Owner
• Authentication Status
• SPF Status
• DKIM Status
• DMARC Status
• Tracking Domain Status
• Consent Basis
• List Sources
• Suppression Status
• Bounce Status
• Complaint Status
• Unsubscribe Status
• Engagement Status
• Volume Status
• Reputation Status
• Risk Status
• Last Incident
• Current Actions
• Last Reviewed
• Next Review
• Evidence Links
Deliverability Incident Record Standard
Each incident should maintain:
• Incident ID
• Detected Date
• Sender
• Domain
• Provider
• Severity
• Incident Type
• Evidence
• Affected Campaigns
• Affected Segments
• Estimated Scope
• Immediate Action
• Sending Status
• Owner
• Root Cause
• Remediation
• Validation
• Reopening Criteria
• Closed Date
• Final Outcome
• Follow-Up Actions
Relationship To Ecommerce Brain
Ecommerce Brain governs lifecycle messaging, list growth, customer state, and suppression.
This framework depends on Ecommerce Brain for:
• valid lifecycle entry
• current customer state
• consent state
• suppression state
• recent purchase
• complaint or refund state
• active flow
• replenishment state
• reactivation state
Deliverability governance must not operate independently from lifecycle relevance.
Relationship To Content Brain
Content Brain governs newsletters and campaign content.
Content Brain must follow deliverability requirements for:
• subject line integrity
• preview text integrity
• message relevance
• design clarity
• image independence
• link integrity
• segment suitability
• frequency pressure
• final approval
Content quality and deliverability governance are separate but connected.
Relationship To Customer Brain
Customer Brain may provide:
• preference
• engagement
• lifecycle stage
• communication tolerance
• complaint history
• relationship quality
• customer value
• support state
Deliverability decisions should consider customer relevance, not only technical metrics.
Relationship To Data Brain
Data Brain governs:
• event accuracy
• consent records
• identity resolution
• suppression records
• bounce events
• complaint events
• unsubscribe events
• segment membership
• sending records
• performance records
• source records
Poor data integrity reduces deliverability confidence.
Relationship To Compliance Brain
Compliance Brain governs:
• consent
• unsubscribe
• privacy
• disclosure
• lawful communication
• sensitive claims
• affiliate disclosure
• regulated content
Deliverability cannot override compliance.
Relationship To Infrastructure Brain
Infrastructure Brain governs:
• DNS
• domain configuration
• provider configuration
• sending infrastructure
• security
• system reliability
• technical logging
This framework defines governance requirements.
It does not authorise implementation.
Relationship To Automation Brain
Automation Brain may support:
• monitoring
• alerting
• suppression
• logging
• duplicate detection
• incident creation
• revalidation reminders
• report collection
Automation must not silently continue sending during a critical incident.
Relationship To Ads Brain
Ads Brain may create list growth and subscriber acquisition.
Deliverability governance should receive feedback about:
• source quality
• campaign quality
• incentive quality
• subscriber quality
• complaint risk
• downstream engagement
Cheap subscriber acquisition that harms sender reputation is not successful acquisition.
Relationship To Finance Brain
Finance Brain may assess:
• subscriber acquisition cost
• deliverability remediation cost
• provider cost
• list attrition cost
• complaint cost
• customer replacement cost
• contribution impact
• reputation damage
Deliverability decisions must consider long-term economic value.
Testing Framework
Deliverability testing may include:
• sender identity
• subject line
• preview text
• segment quality
• sending time
• volume
• authentication
• tracking domain
• reply handling
• link integrity
• design rendering
• image loading
• mobile rendering
• unsubscribe function
• preference centre
• bounce handling
• suppression
• inbox placement
Testing must be controlled.
A single test result must not become a permanent rule.
Platform And Tool Neutrality
This framework is platform neutral.
Klaviyo, Mailchimp, ConvertKit, Beehiiv, ActiveCampaign, HubSpot, SendGrid, Amazon SES, Postmark, and other providers may be used operationally.
Their interface steps, proprietary scores, and dashboard labels are not permanent Canon.
Permanent architecture must define:
• identity
• authentication
• consent
• list quality
• sending behaviour
• monitoring
• incident response
• remediation
• evidence
• ownership
It must not depend on one provider’s current interface.
Drift Protection
The system must prevent:
• treating sent status as inbox placement
• treating platform delivery as proof of primary inbox delivery
• using open rate as the sole engagement measure
• ignoring complaint signals
• ignoring bounce signals
• continuing after unsubscribe
• sending to purchased or unverified lists
• losing consent evidence
• using one consent for multiple channels without authority
• mixing unrelated brands under one sender identity
• frequent sender changes
• sudden uncontrolled volume increases
• sending to inactive recipients without review
• hiding unsubscribe
• misleading subject lines
• false urgency
• broken links
• image-only essential content
• duplicate sends
• duplicate subscriber records
• ignoring lifecycle conflicts
• allowing provider convenience to define governance
• absorbing provider-specific DNS or interface steps as Canon
• treating a high-revenue campaign as successful where reputation damage is severe
Architectural Intent
The MWMS Email Deliverability And Sender Reputation Governance Framework exists to protect long-term owned audience access.
Its role is to ensure that email systems remain:
• identifiable
• authenticated
• permission-based
• relevant
• measurable
• monitored
• suppressible
• recoverable
• economically interpretable
• human governed
Strong deliverability improves communication reliability.
Reliable communication access improves lifecycle, newsletter, campaign, and retention performance.
Deliverability governance must preserve trust before volume.
Future Expansion
Future development may integrate:
• automated DMARC reporting
• domain reputation monitoring
• cross-provider reputation scoring
• predictive complaint risk
• predictive bounce risk
• automated segment health scoring
• communication pressure scoring
• sender reputation confidence
• list-source quality scoring
• inbox placement sampling
• incident escalation
• automated remediation recommendations
• provider migration checklists
• warming confidence models
• cross-channel suppression
• economic reputation impact modelling
Future development does not automatically authorise autonomous sending or autonomous remediation.
Final Rule
Email deliverability must be governed as a long-term trust and access asset.
Every sending system must have:
• defined sender identity
• appropriate authentication
• traceable consent
• clean list controls
• suppression
• bounce handling
• complaint handling
• unsubscribe handling
• communication pressure controls
• monitoring
• incident response
• remediation
• human ownership
• revalidation
MWMS must prioritise permission, relevance, reputation, and customer trust over short-term sending volume.
Change Log
Version: v1.0
Date: 2026-07-19
Author: MWMS HeadOffice
Change:
Initial creation of MWMS Email Deliverability And Sender Reputation Governance Framework using durable intelligence absorbed from Sam Piliero The Facebook Ads Blueprint bonus Email Marketing module by Max Sturtevant.
Created formal governance covering:
• sender identity
• domain authentication
• SPF
• DKIM
• DMARC
• permission and consent
• list quality
• list hygiene
• engagement quality
• communication pressure
• content integrity
• subject line integrity
• sending behaviour
• volume changes
• warming
• provider migration
• bounce handling
• complaint handling
• unsubscribe handling
• reputation monitoring
• incidents
• remediation
• revalidation
• economic interpretation
• human approval
• tool neutrality
Rejected From Canon:
• Klaviyo-specific setup procedures
• provider-specific DNS walkthroughs
• universal benchmark thresholds
• universal warming schedules
• open rate as a complete deliverability measure
• platform-reported delivery as proof of inbox placement
• provider dashboard scores as final authority
• tool-specific interface instructions
CHANGE IMPACT
Pages Created:
• MWMS Email Deliverability And Sender Reputation Governance Framework
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
• Content Brain Page Registry
• Content Brain Copy Map
• MWMS Architecture Registry
• MCR Page Registry
• MCR Copy Map
• MWMS Course Absorption Decision Registry
• MWMS Brain Registry if specialist deliverability ownership is recorded
Canon Version Update Required:
No
System Map Update Required:
Yes
Review:
• Content Brain System Map
• Ecommerce Brain System Map
• Newsletter production relationship
• Lifecycle messaging relationship
• Infrastructure Brain relationship
• Compliance Brain relationship
• Data Brain relationship
• Automation Brain relationship
Change Log Entry Required:
Yes
Supabase Impact:
None
Plugin Impact:
None
Automation Impact:
None
AI Coordination Impact:
None
Employee Impact Check
Employees impacted:
• Newsletter Editor Employee
• Content Planner Employee
• Content Writer Employee
• Ecommerce Lifecycle Employee where future employee architecture exists
• Data Operations Employee
• Compliance Reviewer Employee
• Infrastructure Employee
• Automation Architect Employee
• Customer Intelligence Employee where future employee architecture exists
• Finance Employee where future employee architecture exists
Required behaviour updates:
• AI Employees must not treat platform sent status as proof of inbox placement.
• AI Employees must not use open rate as the sole engagement signal.
• AI Employees must preserve consent, source, suppression, bounce, complaint, and unsubscribe evidence.
• AI Employees must not recommend purchased or unverified lists.
• AI Employees must check lifecycle conflicts and communication pressure.
• AI Employees must not create misleading subject lines.
• AI Employees must not continue sending during a critical deliverability incident.
• AI Employees must not treat provider-specific setup instructions as permanent architecture.
• AI Employees must route high-impact deliverability changes for human review.
• AI Employees must not autonomously send email.
Evidence Reference:
Sam Piliero The Facebook Ads Blueprint bonus Email Marketing module by Max Sturtevant, including Deliverability Intro, Deliverability Metrics, Technical Deliverability Setup, Principles Of Good Email Design, and Proper How To Upload Emails To Klaviyo lessons.
END - MWMS EMAIL DELIVERABILITY AND SENDER REPUTATION GOVERNANCE FRAMEWORK v1.0