TISP-001 · Client Review Draft · Confidential
solynth.net
Solynth Technical Investigation & Solution Proposal

Email Deliverability Investigation & Solution Proposal

Client Edition · Joaquim Pedro · Tributte Recordz
Document
TISP-001
Title
Email Deliverability Investigation & Solution Proposal
Subtitle
Client Edition
Series
Solynth Technical Investigation & Solution Proposal
Revision
1.0
Status
Client Review Draft
Classification
Confidential
Client
Joaquim Pedro
Organization
Tributte Recordz
Author
Robert Curtis
Initiative
Solynth
Location
São João das Lampas, Sintra, Portugal
Date
28 June 2026
Copyright
© 2026 Robert Curtis
Website
https://solynth.net

TISP-001

Email Deliverability Investigation & Solution Proposal

Client Edition

Prepared for

Joaquim Pedro
Tributte Recordz

Prepared by

Robert Curtis
Founder, Solynth Initiative

São João das Lampas, Sintra, Portugal

28 June 2026

Something Is Wrong
Figure 1. Something Is Wrong
Retro pulp-style cover artwork for TISP-001.

Document Number: TISP-001
Revision: 1.0
Status: Client Review Draft
Classification: Confidential

Prepared exclusively for Joaquim Pedro and persons designated by him.

Joaquim Pedro
Figure 10. Joaquim Pedro
Client portrait included in the confidential client edition.

Copyright © 2026 Robert Curtis. All rights reserved.

Dedication

This investigation is dedicated to those engineers, technicians, scientists, mechanics, designers, entrepreneurs, and curious minds who continue to ask difficult questions before accepting convenient answers.

It is also dedicated to those who quietly help others solve problems without seeking recognition, believing that knowledge grows stronger when it is shared.

In memory of my friend and colleague,

Nick Frewin ("Beardo")

"My three tenets in life are to educate, entertain, and disturb."

May this document strive to accomplish all three.

Engineering Epigraphs

"Every machine tells a story. The trick is learning which part of the story is true."
Inspired by the spirit of the Golden Age of Science Fiction.

"Technology does not fail in isolation; people, processes, and systems fail together."
Inspired by Aldous Huxley's Brave New World.

"The engineer's task is not merely to repair yesterday's machine, but to design tomorrow's."
Inspired by James Blish's Cities in Flight.

"When evidence contradicts expectation, follow the evidence."
Inspired by the scientific outlook of Arthur C. Clarke.

Foreword

Engineering is frequently portrayed as the pursuit of the correct answer. Experience suggests otherwise. More often, engineering begins by asking better questions.

Most technical problems do not arrive neatly labelled. They present themselves as symptoms, unexpected behaviour, conflicting observations, incomplete information, and strongly held opinions. The responsibility of the engineer is not to defend assumptions but to investigate them objectively, gather evidence, document uncertainty honestly, and recommend practical paths forward.

This philosophy forms the foundation of Solynth.

The investigation documented in these pages began with a straightforward request from a trusted friend experiencing persistent email delivery problems. What initially appeared to be an SMTP issue quickly expanded into a broader examination of modern email infrastructure, including DNS authentication, sender reputation, cloud-hosted email services, bulk messaging platforms, and the increasingly complex relationship between them.

Rather than documenting only a conclusion, this report documents the investigation itself. Verified observations are separated from working hypotheses. Recommendations are presented independently from both. This distinction is intentional. Engineering is an iterative discipline, and today's understanding may evolve as tomorrow's evidence becomes available.

This publication marks the beginning of the Solynth Technical Investigation & Solution Proposal (TISP) series. Although future reports may address subjects ranging from software architecture and cybersecurity to business operations, infrastructure, project management, or engineering design, they will all follow the same guiding principles established here.

If these pages leave the reader with a deeper understanding of both the problem and the reasoning behind the proposed solutions, then they have fulfilled their purpose.

Robert Curtis
Founder, Solynth Initiative
São João das Lampas, Sintra, Portugal
28 June 2026

About Solynth

Solynth is not a company in the conventional sense.

It is a collaborative engineering initiative—an idea built around the belief that complex problems are best understood and solved collectively.

Participants contribute from many different disciplines. Some work in software engineering. Others bring experience in infrastructure, systems administration, business operations, project management, mechanics, design, research, or entrepreneurship. Each investigation benefits from these different perspectives, encouraging thoughtful challenge rather than unquestioning agreement.

The purpose of Solynth is not simply to produce answers.

Its purpose is to improve understanding.

Every investigation begins by gathering evidence rather than defending assumptions. Verified facts are distinguished from reasonable hypotheses, and both remain separate from future proposals. This deliberate separation allows conclusions to evolve naturally as additional information becomes available while maintaining the integrity of the investigative process.

Equally important is the collaborative environment in which ideas develop. Many discussions begin around a shared table over coffee, a meal, or a glass of Portuguese wine before evolving into engineering diagrams, technical papers, software systems, or implementation plans. Experience suggests that durable solutions emerge most often when people with different backgrounds work together respectfully toward a common objective.

Each Technical Investigation & Solution Proposal documents a genuine engineering challenge, the investigation undertaken, the evidence collected, the reasoning applied, and one or more practical paths toward implementation.

Solynth is therefore best understood not as a business entity but as an ethos—a continuing commitment to curiosity, collaboration, careful engineering, and the open exchange of ideas.

Further information and future publications will be available through:

https://solynth.net

The Solynth Charter

Every Solynth investigation seeks to answer three questions.

  1. What do we know?
  2. What do we not yet know?
  3. What is the most practical path forward based upon the evidence currently available?

Root Cause Analysis and Best Solution Proposal are treated as complementary engineering activities rather than sequential tasks.

Sometimes the root cause can be demonstrated conclusively.

Sometimes it cannot.

Engineering should continue to move forward honestly in either case. Recommendations should always reflect the strength of the available evidence, clearly identifying verified observations, informed judgement, and remaining uncertainty.

The objective is not simply to repair systems.

The objective is to understand them well enough to improve them.

Executive Summary

This Technical Investigation & Solution Proposal documents an investigation into repeated email delivery problems affecting Tributte Recordz during bulk customer communications.

The investigation began after Yahoo Mail returned SMTP error 421 4.7.0 [TSS04], indicating that messages from the originating outbound server were being temporarily deferred because of unexpected sending volume or user complaints.

Rather than immediately replacing components or changing providers, the investigation first examined the existing technical environment. Public DNS records were reviewed, including MX, SPF, DKIM, and DMARC authentication. Public blacklist services were consulted to determine whether the originating infrastructure had been identified as a source of abusive email. The available evidence suggested that the domain's published authentication records were correctly configured and that the observed sending IP address was not listed on the major public DNS blacklists examined.

These findings shifted the investigation away from simple DNS misconfiguration and toward broader questions involving sender reputation, bulk email practices, shared infrastructure, and the interaction between multiple hosted platforms.

At the time of writing, the environment under investigation includes Namecheap Private Email, MailChimp, Shopify messaging components, and Yahoo Mail. The precise interaction between these services has not yet been conclusively established. Further engagement with the respective service providers is therefore recommended before assigning a definitive operational root cause.

Running in parallel with the Root Cause Analysis is a Best Solution Proposal. Rather than relying upon a general-purpose mailbox provider for sustained campaign-based email delivery, this report recommends evaluating Amazon Simple Email Service (SES) as a purpose-built outbound email platform designed specifically for authenticated, reputation-managed delivery at scale.

This recommendation should not be interpreted as proof that the existing infrastructure is defective. Instead, it reflects the engineering judgement that specialised outbound delivery platforms are increasingly better suited to modern campaign-based communications than traditional hosted mailbox services.

Finally, this report introduces the Solynth Technical Investigation & Solution Proposal methodology itself. Future publications will apply the same investigative approach to engineering, infrastructure, software, operational, and business challenges while maintaining a clear distinction between evidence, reasoning, and recommendation.

Investigate It Objectively
Figure 2. Investigate It Objectively
Pulp science-fiction illustration introducing the forensic method.
Email Delivery Ecosystem
Figure 7. Email Delivery Ecosystem
Authentication, reputation, and sending behaviour determine deliverability.

Problem Statement

The purpose of this investigation is to determine the most probable causes of repeated email delivery failures affecting Tributte Recordz while conducting legitimate customer communications through modern cloud-hosted messaging platforms.

The investigation began following repeated SMTP responses from Yahoo Mail reporting:

421 4.7.0 [TSS04] Messages temporarily deferred due to unexpected volume or user complaints.

Although the message itself appears straightforward, it provides only a high-level indication that Yahoo's inbound filtering systems have temporarily delayed acceptance of messages originating from a particular sending infrastructure. It does not, by itself, identify the precise operational cause.

Modern email delivery is no longer determined solely by correct DNS configuration. Reputation, authentication, historical behaviour, user complaints, bounce rates, message content, sending velocity, infrastructure sharing, and provider-specific policies all influence whether a message is accepted, delayed, quarantined, or rejected.

Consequently, this investigation deliberately avoids premature conclusions. Instead, it seeks to eliminate potential causes systematically while documenting both verified observations and remaining uncertainties.

The objective is not simply to restore successful email delivery. The objective is to understand the system well enough to recommend a more robust long-term architecture.

Scope of Investigation

This report examines the publicly observable technical environment supporting outbound email delivery for Tributte Recordz.

Specifically, the investigation considers:

This report does not attempt to perform forensic analysis of proprietary MailChimp, Shopify, Namecheap, Amazon, or Yahoo internal systems. Such information is not publicly available and requires cooperation from the respective providers.

Where direct evidence is unavailable, this report clearly distinguishes engineering judgement from verified fact.

Investigation Methodology

The investigation followed a structured engineering approach designed to eliminate the simplest explanations before considering more complex possibilities.

The process consisted of the following stages:

  1. Capture the reported SMTP error.
  2. Identify the originating infrastructure.
  3. Examine DNS authentication.
  4. Validate published MX records.
  5. Verify SPF configuration.
  6. Verify DKIM configuration.
  7. Verify DMARC configuration.
  8. Examine public blacklist reputation.
  9. Identify all participating cloud platforms.
  10. Develop working hypotheses.
  11. Recommend immediate actions.
  12. Develop a future-state architecture.

Each stage was documented before proceeding to the next. This prevented assumptions made during later stages from influencing the interpretation of earlier observations.

The Investigation
Figure 3. The Investigation
Step-by-step forensic flow for the Yahoo 421 deliverability issue.

Verified Evidence

At the time this report was prepared, the following observations had been independently verified using publicly available diagnostic tools.

SMTP Error

Yahoo Mail reported repeated temporary delivery deferrals using SMTP response:

421 4.7.0 [TSS04]

The accompanying message referenced unexpected sending volume or user complaints.

This response indicates a temporary reputation-based delivery decision rather than a permanent rejection.

MX Records

Public DNS records confirmed that the domain publishes valid MX records pointing to Namecheap Private Email infrastructure.

Observed MX servers included:

No obvious MX configuration errors were identified.

SPF

The published SPF record was found to be syntactically valid.

The investigation confirmed:

Observed policy:

v=spf1 include:spf.privateemail.com ~all

The record appeared consistent with Namecheap Private Email recommendations.

DKIM

Initial testing failed because no selector had been supplied during the lookup.

After repeating the test using the correct selector:

default._domainkey

a valid 2048-bit RSA public key was successfully located.

The investigation therefore concluded that DKIM was correctly published for the tested selector.

DMARC

The domain published a valid DMARC record.

Observed policy:

v=DMARC1; p=reject;

The syntax validated successfully.

No structural problems were identified.

The published policy demonstrates an intention to reject unauthenticated messages rather than merely monitor them.

Public Blacklists

The reported sending IP address:

162.0.218.229

was tested against approximately sixty publicly available DNS blacklist services.

No public blacklist listings were identified during the investigation.

Although blacklist status alone cannot guarantee good sender reputation, it eliminates one common cause of immediate delivery failures.

MXToolbox Decision Tree
Figure 4. MXToolbox Decision Tree
Reusable diagnostic decision tree for MX, SPF, DKIM, DMARC, and blacklist checks.

Preliminary Conclusions

Based upon the evidence gathered during the initial investigation, several common explanations can reasonably be excluded.

The investigation found no evidence of:

These findings significantly reduce the likelihood that the observed Yahoo behaviour is the direct result of a simple DNS configuration error.

Attention therefore shifts toward more complex aspects of modern email delivery, including sender reputation, campaign behaviour, complaint rates, shared outbound infrastructure, recipient engagement, and provider-specific reputation algorithms.

The next stage of this investigation considers those broader operational factors and evaluates practical engineering responses that remain effective regardless of which individual component ultimately proves to be responsible.

Root Cause Analysis

Engineering Perspective

At this stage of the investigation, sufficient evidence has been gathered to eliminate several common technical causes while simultaneously identifying a number of remaining operational possibilities.

An important principle of engineering investigations is that the absence of evidence should not be confused with evidence of absence. Accordingly, this report distinguishes clearly between verified observations and engineering hypotheses.

The available evidence supports the conclusion that the domain's published authentication records are correctly configured and that no obvious public reputation problems are visible through commonly available blacklist services. Nevertheless, Yahoo continues to defer message acceptance under its internal reputation systems.

The investigation therefore enters its analytical phase.

Working Hypotheses

The following hypotheses are presented in approximate order of likelihood based upon the currently available evidence.

The ordering should not be interpreted as proof.

Hypothesis 1 — Sender Reputation

The most probable explanation is that Yahoo has developed an unfavourable reputation score for one or more components involved in the outbound delivery chain.

Unlike public DNS blacklists, mailbox providers maintain proprietary reputation systems which incorporate factors including:

These systems are not publicly visible.

Consequently, a sender may possess an excellent DNS configuration while simultaneously experiencing poor delivery due to internal reputation scoring.

Current confidence:

High

Hypothesis 2 — Shared Infrastructure

Namecheap Private Email provides shared outbound infrastructure.

Shared infrastructure inevitably introduces the possibility that one customer's behaviour influences the reputation experienced by another.

The investigation has found no evidence that this is occurring.

However, the possibility cannot presently be excluded.

Current confidence:

Moderate

Hypothesis 3 — Campaign Behaviour

MailChimp campaigns may trigger reputation systems through characteristics unrelated to DNS configuration.

Examples include:

No evidence presently suggests that Tributte Recordz intentionally engages in undesirable mailing practices.

Nevertheless, campaign analytics should be reviewed before excluding this possibility.

Current confidence:

Moderate

Hypothesis 4 — Multi-platform Interaction

The current delivery architecture includes multiple independent cloud providers.

These include:

Each maintains independent reputation systems.

Interactions between these systems may produce operational behaviours that are difficult to observe externally.

Current confidence:

Moderate

Hypothesis 5 — DNS Configuration

The investigation currently considers DNS configuration an unlikely primary cause.

MX records, SPF, DKIM and DMARC all appear correctly published.

Although future evidence could modify this assessment, DNS no longer appears to be the principal investigative direction.

Current confidence:

Low

Adapt Rather Than Patch
Figure 5. Adapt Rather Than Patch
Retro illustration for moving from patchwork fixes toward resilient architecture.

Recommended Immediate Actions

The investigation recommends completing the following activities before undertaking major architectural changes.

1. Namecheap

Open a support request asking:

2. MailChimp

Request campaign diagnostics.

Specifically determine:

3. Shopify

Clarify which messages originate from Shopify itself and which are delegated to MailChimp.

Determine whether:

share identical sender identities.

4. Yahoo

Only after completing the previous investigations should Yahoo be approached.

Questions should include:

Parallel Engineering Track

One of the defining characteristics of the Solynth methodology is that Root Cause Analysis and Best Solution Proposal proceed simultaneously.

Traditional investigations often insist upon proving every aspect of the root cause before discussing improvements.

Practical engineering frequently benefits from pursuing both activities in parallel.

While evidence continues to accumulate, future-state architectures can be evaluated, implementation effort estimated, operational risks reduced, and migration strategies prepared.

This approach shortens recovery time without compromising investigative integrity.

Best Solution Proposal

Based upon the available evidence, this report recommends evaluating a dedicated transactional email platform designed specifically for authenticated outbound delivery.

The reference implementation selected for this investigation is:

Amazon Simple Email Service (SES)

Amazon SES Setup Flow
Figure 8. Amazon SES Setup Flow
Minimum viable setup path from AWS account through monitoring.

Amazon SES separates mailbox hosting from outbound message delivery.

Its principal advantages include:

Most importantly, SES is engineered specifically for large-scale authenticated outbound messaging rather than conventional hosted mailboxes.

This aligns closely with the operational requirements observed during this investigation.

Proposed Migration Philosophy

The recommendation is not to replace existing business systems.

Rather, existing systems should continue performing their intended roles while delegating outbound email delivery to infrastructure specifically designed for that purpose.

A possible future architecture becomes:

Shopify

↓

MailChimp

↓

Amazon SES

↓

Recipient Mail Providers

rather than relying exclusively upon traditional hosted mailbox infrastructure.

This approach reduces dependence upon shared outbound relay environments while improving visibility into delivery performance.

Solynth Engineering Observation

One of the more valuable outcomes of this investigation extends beyond the immediate technical problem.

The investigation demonstrates that many modern operational issues no longer originate within a single product.

Instead, they emerge from interactions between multiple independently managed cloud services.

Successful engineering therefore increasingly requires understanding systems rather than individual components.

That philosophy forms the foundation of Solynth's investigative methodology.

Transition to Future Architecture

The next section of this report develops the proposed future-state architecture in greater detail.

It examines how Amazon SES—and eventually multiple interchangeable delivery providers—could be incorporated into a provider-independent email delivery framework managed through the Solynth initiative.

The objective is not merely to solve today's delivery issue, but to establish a resilient architecture capable of adapting to future operational requirements while minimising dependence upon any single vendor.

Future-State Architecture

The investigation undertaken for Tributte Recordz identified an important distinction between traditional mailbox hosting and modern outbound email delivery.

Historically, a single provider often supplied domain hosting, mailboxes, SMTP services, and outbound delivery. Modern cloud platforms increasingly separate these responsibilities into specialised services that can be combined to suit operational requirements.

The recommended future architecture therefore treats outbound email delivery as an independent service rather than an incidental feature of mailbox hosting.

This approach improves resilience, simplifies troubleshooting, and reduces dependence upon any single provider.

Solynth Email Delivery Architecture
Figure 6. Solynth Email Delivery Architecture
Future provider-agnostic architecture for managed email delivery.

Proposed Reference Architecture

A future Solynth-managed email architecture may consist of the following logical components:

The intention is not for Solynth to become an email provider.

Instead, Solynth acts as an engineering and orchestration layer that helps customers configure, monitor, migrate, and troubleshoot industry-standard delivery platforms.

Customers retain ownership of:

This architecture avoids vendor lock-in while allowing future migration with minimal operational disruption.

Future Provider Options

Although Amazon SES has been selected as the reference implementation within this report, several mature alternatives also exist.

Examples include:

Each platform has different strengths, pricing models, APIs, and operational characteristics.

Future Solynth investigations may evaluate these providers independently using the same evidence-based methodology applied throughout this report.

Recommendations

Immediate

Short Term

Medium Term

Long Term

Engineer a Better Future
Figure 9. Engineer a Better Future
Optimistic retro-futurist closing image for the Solynth methodology.

Engineering Philosophy

"My three tenets in life are to educate, entertain, and disturb."

— Nick Frewin ("Beardo")

The Solynth initiative aspires to honour that philosophy.

Every investigation should educate by explaining the evidence.

Every publication should remain engaging enough that readers wish to continue learning.

Every conclusion should be willing to challenge assumptions when the evidence suggests a better explanation.

Good engineering is not measured solely by whether a problem is repaired.

It is measured by whether future engineers inherit a clearer understanding than those who came before them.

Conclusion

The original question presented to this investigation appeared deceptively simple:

Why are legitimate customer emails being deferred by Yahoo?

The investigation demonstrated that the answer cannot be reduced to a single DNS record or configuration setting.

Modern email delivery depends upon an ecosystem of authentication, reputation, infrastructure, user behaviour, cloud services, and operational practices.

The evidence gathered during this investigation eliminated several common causes while identifying a number of plausible operational explanations requiring further engagement with the relevant service providers.

Rather than waiting for complete certainty before acting, this report also proposed a future-state architecture capable of improving operational resilience regardless of which individual component ultimately proves responsible.

This dual-track approach—Root Cause Analysis alongside Best Solution Proposal—forms the basis of the Solynth Technical Investigation & Solution Proposal methodology.

It is hoped that this document provides Joaquim Pedro with not only a practical path toward resolving the immediate issue, but also a framework for making future technical decisions with greater confidence.

Appendix A: MXToolbox Investigation Log

This appendix documents the practical troubleshooting sequence used before recommending Amazon SES. The purpose is to separate DNS and authentication problems from sender reputation or bulk-sending problems.

The tool used was MXToolbox SuperTool. The same tests can also be performed with dig, nslookup, Google Admin Toolbox, or other DNS tools, but MXToolbox is simple enough to use from a phone.

A1. Original Error

The reported Yahoo SMTP error was:

421 4.7.0 [TSS04] Messages from 162.0.218.229 temporarily deferred due to unexpected volume or user complaints

This told us two important things.

First, 421 means temporary deferral rather than permanent rejection.

Second, Yahoo named the IP address it was concerned about: 162.0.218.229.

That meant both the domain's DNS records and the reputation of the specific sending IP needed to be checked.

A2. MX Records

MXToolbox query used:

mx:tributterecordz.com

Result:

mx1.privateemail.com
mx2.privateemail.com

Both were Namecheap Private Email servers.

Interpretation:

The domain's incoming mail routing looked correct. This did not explain Yahoo's outbound delivery complaint, but it confirmed that the domain was using Namecheap Private Email in the expected way.

A3. SPF

MXToolbox query used:

spf:tributterecordz.com

Result:

v=spf1 include:spf.privateemail.com ~all

MXToolbox reported:

Interpretation:

SPF was correctly configured for Namecheap Private Email. SPF was not the obvious cause of the Yahoo deferral.

A4. DMARC

MXToolbox query used:

dmarc:tributterecordz.com

Result:

v=DMARC1; p=reject;

MXToolbox reported:

Interpretation:

DMARC was present and enforced. The published record used p=reject, which is the strongest DMARC policy. This was not a missing-DMARC problem.

A5. DKIM

Initial DKIM testing failed because DKIM requires a selector.

An attempted selector of Dkim returned no record.

That did not prove DKIM was missing. It only proved that the selector Dkim was not correct.

A second test used:

dkim:tributterecordz.com:default

Result:

A valid DKIM record was found.

MXToolbox reported:

Interpretation:

The correct DKIM selector was default. DKIM was present and valid.

A further test using:

dkim:tributterecordz.com:privateemail

returned no DKIM record.

That was not a problem because the valid selector had already been identified as default.

A6. Public Blacklist Check

MXToolbox query used:

blacklist:162.0.218.229

Result:

The IP was checked against approximately sixty public blacklist services.

It was listed zero times.

Interpretation:

The outbound IP was not publicly listed by the major blacklist checks run through MXToolbox.

This does not prove Yahoo trusts the IP. Yahoo and other large providers maintain internal reputation systems that are not the same as public DNS blocklists.

A7. IP Comparison

The MX records resolved to Namecheap Private Email inbound mail servers:

162.255.118.7
162.255.118.8

The Yahoo error referenced:

162.0.218.229

Interpretation:

Yahoo was not complaining about the domain's incoming MX servers. Yahoo was complaining about the outbound relay that sent the message.

That distinction matters. It shifts attention away from incoming mail routing and toward outbound sending behaviour, relay reputation, and campaign practices.

A8. Overall Result

The diagnostic checks showed:

The evidence did not support the idea that the domain's basic DNS authentication was broken.

A9. Practical Conclusion

Once MX, SPF, DKIM, DMARC, and public blacklist checks passed, the likely problem moved from "bad DNS" to "sending behaviour or sending infrastructure."

For ordinary one-to-one mail, Namecheap Private Email may be adequate.

For hundreds of promotional messages to prospective customers, it is the wrong class of tool. That type of mail benefits from a bulk or campaign-capable provider with bounce handling, complaint tracking, unsubscribe enforcement, and reputation management.

That is why Amazon SES became the recommended minimum viable next step.

Appendix B: Amazon SES Implementation Cookbook

Amazon SES is the reference implementation proposed in this report. This appendix outlines the minimum viable setup.

B1. Create or Use an AWS Account

Joaquim should create his own AWS account or use one he already controls.

Recommended controls:

B2. Open Amazon SES

Open Amazon Simple Email Service in the AWS console.

Choose a single AWS region for the initial implementation and keep the configuration there.

B3. Create a Domain Identity

Create a verified domain identity for:

tributterecordz.com

Domain verification is preferable to single-address verification because it allows properly authenticated mail from addresses on the domain.

B4. Enable Easy DKIM

Use SES Easy DKIM.

SES will generate DNS records, usually CNAME records.

These records must be added at the domain's DNS provider.

B5. Add DNS Records

Log into the DNS provider.

Add the SES records exactly as shown.

Do not alter the random hostnames or values.

Wait until SES reports the domain identity and DKIM as verified.

B6. SPF

If SES will send mail for the domain, SPF should authorize Amazon SES.

A typical SES include is:

include:amazonses.com

If the domain already has an SPF record, do not create a second one. Combine includes into the existing record.

B7. DMARC

Keep DMARC in place.

Before sending volume, confirm that live messages pass:

B8. Custom MAIL FROM

Configure a custom MAIL FROM domain such as:

bounce.tributterecordz.com

SES will provide DNS records for this.

Custom MAIL FROM improves alignment and bounce handling.

B9. Request Production Access

New SES accounts generally begin in sandbox mode.

To send real mail to unverified recipients, request production access.

The request should explain:

B10. Create SMTP Credentials

Create SES SMTP credentials.

These are not the same as the AWS login.

Record:

Use TLS.

B11. Configure Website or Campaign Tool

Configure Shopify, MailChimp, or the relevant outbound tool to send via SES where supported.

Use sender addresses from the verified domain.

B12. Add Unsubscribe Handling

All promotional mail should include a visible unsubscribe link.

Bulk mail should support list-unsubscribe headers wherever possible.

B13. Warm Up Sending

Do not immediately send large volumes from a fresh configuration.

Start with a small number of known, engaged recipients.

Increase gradually while monitoring:

B14. Monitor Continuously

Track:

Bad addresses should be suppressed.

Unsubscribed recipients should never be mailed again.

Appendix C: Support Ticket Checklist

C1. Namecheap

Provide:

Ask:

C2. MailChimp

Provide:

Ask:

C3. Shopify

Provide:

Ask:

C4. Yahoo

Approach Yahoo only after the provider checks have been completed.

Provide:

Ask:

Appendix D: Future Solynth Email Delivery Architecture

The long-term Solynth opportunity is not to become a mail relay.

The opportunity is to provide an engineering layer that helps customers configure and manage legitimate delivery providers.

Potential Solynth capabilities include:

Supported providers may include:

Each customer would retain ownership of:

Solynth would provide the investigation methodology, configuration assistance, monitoring framework, and documentation.

Appendix E: Reference Material

This investigation was informed by:

No proprietary logs from Namecheap, MailChimp, Shopify, Yahoo, or Amazon were available at the time this client review draft was prepared.

Where conclusions extend beyond directly observable evidence, they have been explicitly identified as hypotheses or engineering judgement.

Revision History

Revision Date Author Summary
1.0 28 June 2026 Robert Curtis Initial client review draft prepared for Joaquim Pedro and Tributte Recordz.

End of TISP-001.md