Staff have reported that the newsletter's performance dropped after the move to Braze, that resubscribed colleagues still aren't receiving it, and that replies are disappearing. Those reports are taken seriously and are addressed directly below. This briefing separates what the data actually shows from what the headline numbers appear to show — and lays out a concrete plan to resolve the genuine issues.
Three distinct concerns have been raised about the staff newsletter since it moved to Braze. They are stated here in plain terms because each one is legitimate and deserves a direct answer — not because any of them is being dismissed.
Braze is working, and it will work well for the staff newsletter. The open-rate drop is largely a measurement difference between two platforms that count opens differently — on the metric that is comparable, the change is modest and already recovering. The delivery and reply problems, however, are real — and they all trace to a single fixable cause: the newsletter currently shows c.outwardbound.org as its visible sender address. The plan in §4 resolves that cause directly.
The "40% to the 20s" comparison sets a Mailchimp number next to a Braze number — but the two platforms do not measure opens the same way. Comparing them directly is like comparing a temperature in Fahrenheit to one in Celsius and concluding it got colder.
Mailchimp's ~40–48% was a unique, human open rate — it counts each person once and strips out Apple Mail's automated opens.
Braze publishes two open-rate columns. The "Total Open Rate" column counts every open event — the same person opening twice counts twice, and machine opens are included. That is the column that shows values like 70%, 99%, even 106%. A figure above 100% is the clearest possible signal that this column is not measuring "what share of people opened." The comparable Braze figure is "Unique Open Rate," which is running around 30%.
So the honest comparison is not 40% vs. 20%. It is Mailchimp's unique opens (~46.7% weighted) vs. Braze's unique opens (~30.5% weighted) — and even that gap is partly methodology, because the two platforms still differ in how they treat machine opens.
Click rate is measured the same way on both platforms, which makes it the trustworthy spine of any comparison. On click rate, the staff newsletter went from a ~9.3% weighted average in Mailchimp to ~7.5% in Braze — a real but modest dip, not a halving.
Two things matter underneath that. First, the click rate was already declining inside Mailchimp before the migration — 14.9% in early January down to 5.7% by early March. That points to a newsletter content and call-to-action question, separate from the platform. Second, the Braze trajectory is climbing back: the first Braze send was the weakest, and the send two weeks later actually beat the Mailchimp click average.
The solid metric is click rate, the one measure that is comparable across both platforms. Open rate is shown only as faint context — it is not comparable across the platform boundary.
The disappearing replies, the missed safety email, the resubscribed staff who still don't receive the newsletter, and the Outlook warning are not measurement artifacts. They are real — and they all trace to a single configuration issue: the newsletter currently sends with c.outwardbound.org as its visible "from" address.
c.outwardbound.org is a send-only subdomain. It is built to send marketing email and to keep that sending reputation separate from corporate mail — but it has no inbox behind it. When a staff member replies to a newsletter, their reply is addressed to c.outwardbound.org, and there is nowhere for that message to land. It does not reach the sender.
The diagram below also explains an oddity staff have noticed: a thumbs-up reaction on the newsletter does get through, while a typed reply does not. That is because a reaction is not a normal email — within Microsoft's ecosystem it travels as a lightweight notification routed differently from a standard reply. The fact that the reaction arrives but the reply doesn't is not a glitch; it actually confirms the diagnosis — the problem is the reply address, not the newsletter itself.
This is the most counter-intuitive symptom, so it is worth being precise. Resubscribing a colleague in Braze controls one thing only: whether Braze sends them the email. It has no control over whether the recipient's mail system accepts and inboxes it.
If Outlook / Exchange has learned to distrust mail from c.outwardbound.org — because the address is unfamiliar, or because the newsletter was previously marked as spam by some recipients — Exchange can filter or quarantine the message before it ever reaches a Junk folder. That is why "I checked my junk and it isn't there" does not mean the email was delivered. It can be held in an administrative quarantine, routed away, or dropped entirely — all invisible to the recipient.
The newsletter is sent to the resubscribed staff member. Braze reports it as "sent."
The message reaches the recipient's Microsoft 365 mail system for evaluation.
Distrust of the unfamiliar c. sender diverts it — to quarantine, a rule, or nowhere.
It never reaches the inbox or the Junk folder. The recipient simply never sees it.
This is why confirming someone is "back on the list" in Braze is necessary but not sufficient — the block is happening on the receiving side, and it has to be diagnosed and cleared there.
Three coordinated workstreams, owned across Marketing/MarTech and IT. The first is the permanent fix; the second is an immediate bridge so staff stop losing newsletter mail today; the third hardens delivery so the fix holds as volume grows.
The root cause. The newsletter's visible "from" address moves off the sending subdomain and onto a real, recognizable outwardbound.org address, with replies routed to a genuine, monitored inbox. The technical sending subdomain stays where it is — it is supposed to be there — it simply stops being the address staff see and reply to.
The "from" change is the permanent fix, but it does not retroactively release mail already filtered, and it cannot instantly rebuild sender trust inside Exchange. This workstream stops internal staff from losing the newsletter today while the permanent fix takes hold.
A brand-new sending domain begins life with no reputation, and mail systems treat unproven senders cautiously. The weak first Braze send and the early delivery friction are textbook signs of a domain still warming up. This workstream makes sure the corrected setup is also a well-warmed one.
IT message trace, quarantine release, and a safe-sender rule so internal staff receive the newsletter right away.
The "from" address change in Braze, verified by a seed test to Outlook and Gmail before any live send.
Warm-up restructured, every stuck case resolved against trace data, consistent metrics going forward.
The concerns raised about the staff newsletter are taken seriously and have been investigated directly against the data. Here is where things actually stand.
Part One explains the perception, the data, and the plan. Part Two is the underlying technical reference — how Braze composes, signs, routes, and delivers email through the c.outwardbound.org sending subdomain, and why the fix in Part One §04 carries no deliverability risk. It is written for IT and MarTech readers who need the mechanism, not just the summary.
The sub-processor identity in this document is confirmed against our actual Braze configuration. Specific DNS record values shown later (record content, DKIM selectors, SPF includes) are illustrative patterns drawn from standard SparkPost setups — they communicate the structure correctly but should be replaced with verified values from our live DNS zone before this is treated as a definitive record of our published configuration.
SparkPost is the email sub-processor configured against our Braze workspace, confirmed via the Braze dashboard. This is what handles DKIM signing, IP selection, SMTP delivery, and bounce capture for all marketing email sent through Braze.
A note on SendGrid: SendGrid does appear elsewhere in the Outward Bound stack — it powers separate website-related sending work — but it is not the sub-processor for the Braze marketing send flow this document describes. The two should not be conflated.
For context: Braze customers can be on any of three sub-processors. The three options are Amazon SES (the platform default for new setups), SparkPost (our choice), or SendGrid. The high-level email flow is identical across all three; what differs is which IP ranges send the mail, which DNS records get published, and what appears in the Received: headers.
Specific DNS values shown in §3 (SPF includes, DKIM selectors, the DMARC policy string) are illustrative patterns based on standard Braze + SparkPost documentation. They have not been pulled from a live DNS lookup of outwardbound.org.
Each table that contains illustrative values is flagged with an illustrative badge so they aren't mistaken for verified records.
Every email actually carries two distinct "from" addresses, governed by two different RFCs. Recipients only see one of them; mail servers care mostly about the other. Misalignment between the two is the root cause of every concern this document addresses.
The visible "from" name, address, subject, and body are RFC 5322 headers. Recipient mail clients render them. The via c.outwardbound.org annotation is Gmail's note that the envelope and header domains don't match exactly — discussed in §5.
Braze is a customer engagement platform; it does not directly hand packets to the recipient's mail server. The actual MTA work — DKIM signing, IP selection, SMTP delivery, bounce capture — is done by Braze's email sub-processor. For Outward Bound, that's SparkPost. The diagram below traces the handoffs; the cards below the diagram list what gets stamped onto each message and what the recipient checks.
Braze (and every modern ESP) strongly recommends sending marketing email from a dedicated subdomain rather than the root domain. This isolates the sending reputation of marketing email from corporate mail (Outlook on outwardbound.org) and transactional mail. If a marketing campaign ever triggers spam complaints, blacklisting, or a deliverability incident, the impact stays on the subdomain — corporate inboxes on the root continue to function unaffected. The letter prefix itself (c. for campaigns, t. for transactional) is a convention; the meaningful work is that each is an isolated sending identity.
The same architecture described in §2 applies to each Outward Bound sending subdomain. Each gets its own DKIM key pair, its own SPF authorization, and its own bounce-handling path — and each inherits DMARC policy from the root outwardbound.org zone. This is what allows the federation to share a domain while keeping reputations cleanly separated.
The visible From address for every campaign should sit on the root domain (e.g. giving@outwardbound.org, enroll@cobs.outwardbound.org) — never on the bare sending subdomain. The sending subdomain belongs in the envelope and DKIM, not in front of donors and recipients.
DMARC policy inheritance: Because the DMARC record is published on the root outwardbound.org, all current and future subdomains inherit it automatically. No subdomain-level DMARC configuration is required to extend coverage to a new school. New subdomains do still need their own SPF and DKIM records published.
The recipient mail server's only source of truth about what we authorize is our DNS. The sub-processor provisions records on each sending subdomain (so the root zone's SPF doesn't have to enumerate every ESP), and our root-level DMARC policy governs how mismatches are handled. The DKIM check is what carries the alignment for the visible From address.
| Type | Host (pattern) | Value pattern | What it does |
|---|---|---|---|
| TXT | c.outwardbound.org | v=spf1 include:sparkpostmail.com ~all | Authorizes SparkPost's sending IPs to use this subdomain in the envelope. |
| TXT | scph<date>._domainkey.c.outwardbound.org | v=DKIM1; k=rsa; h=sha256; p=<public key> | DKIM public key published directly as a TXT record. SparkPost's convention is to inline the key rather than use a CNAME pointing back to its infrastructure. |
| CNAME | <bounce-host>.c.outwardbound.org | sparkpostmail.com | Custom bounce domain — where Return-Path resolves. NDRs land at SparkPost, get classified, and the bounce status flows back to Braze for list hygiene. |
| Type | Host (pattern) | Value pattern | What it does |
|---|---|---|---|
| TXT | _dmarc.outwardbound.org | v=DMARC1; p=<none | quarantine | reject>; adkim=r; aspf=r; rua=mailto:<reporting address> | Tells recipients how to handle unauthenticated mail. Relaxed alignment (adkim=r) means a subdomain match counts as alignment for the root. Current policy strictness should be verified. |
| MX | outwardbound.org | <M365 mail protection endpoint> | Where replies and human inbound mail to the root domain are delivered. Replies routed to root-domain From addresses land here. |
| TXT | outwardbound.org | v=spf1 include:spf.protection.outlook.com -all | Root SPF — for Outlook-sent corporate mail only. Does NOT need to include the marketing sub-processor (because the envelope from is on the subdomain, not the root). |
Recipient checks the Return-Path domain's SPF record. If the sending IP appears in c.outwardbound.org's SPF, pass.
Recipient fetches the public key from the TXT record at scph<date>._domainkey.c.outwardbound.org and validates the signature stamped by SparkPost.
Recipient compares the visible From domain (outwardbound.org) to SPF and DKIM domains. Under relaxed alignment, subdomain → root match passes.
Only one header changes — the visible From — but it changes everything recipients see, the destination of replies, and what gets cached in their address books. Authentication still passes because DMARC's relaxed alignment treats c.outwardbound.org and outwardbound.org as the same organizational domain.
A short checklist to run before sending the next campaign on the corrected configuration — and to keep as a paper trail when the same questions resurface later.
Email deliverability runs on a stack of acronyms. This section defines the ones used throughout this document in everyday terms — what each thing does, and why it matters. The diagram that follows shows how they relate, because the terms only make full sense in relation to one another.
Reading left to right: our systems hand a message off, it travels across the internet, and the recipient’s mail system checks it against records we publish before deciding where it lands.
The internet’s public directory. It maps domain names to addresses, and it also stores small text records that describe how a domain’s email should be handled.
Why it matters: DNS is where we publish the proof that email claiming to be from outwardbound.org is genuinely ours. Every other check on this list works by reading a record we put in DNS.
The actual sending engine that transmits email from one server to another. Our email platform (Braze) hands messages to an MTA, which signs them and delivers them; the recipient’s side has its own MTA that receives them.
Why it matters: The MTA is the part that does the technical work of authentication and delivery. When deliverability is discussed, the MTA’s reputation and configuration are usually what’s at stake.
The shared language mail servers use to hand email to one another across the internet. When one MTA passes a message to the next, it happens over SMTP.
Why it matters: SMTP is the “road” email travels on. It is also what carries the envelope information — including the hidden return address where bounces are sent.
A DNS record listing which servers are allowed to send email for a domain. The receiving system checks whether the message arrived from a server on that approved list.
Why it matters: SPF answers the question “was this sent from a server we authorized?” It is one of the two ways a recipient confirms an email is legitimately ours.
A tamper-proof digital signature added to every message. The MTA signs the email with a private key; the recipient checks that signature against a matching public key we publish in DNS.
Why it matters: DKIM answers “is this genuinely from us, and was it altered in transit?” In our setup, DKIM is the check that lets the visible address stay on the root domain while sending happens on the subdomain.
A DNS policy that ties SPF and DKIM together. It tells receiving systems two things: whether the visible “from” address lines up with what SPF and DKIM verified, and what to do with mail that fails — accept, quarantine, or reject.
Why it matters: DMARC is the rule that decides the consequence. Its “relaxed alignment” setting is what allows a subdomain and the root domain to count as the same organization — the technical basis for the fix in this document.
The automated “bounce” message returned when an email cannot be delivered — because an address is invalid, a mailbox is full, or a system rejected it.
Why it matters: NDRs are how senders learn delivery failed. In this document they appear twice: as normal bounce handling the platform manages, and as the failure that happens when someone replies to a send-only subdomain address.
The published technical standards that define how internet systems work. Email’s core behaviors — message format, addressing, delivery — are each specified in an RFC.
Why it matters: RFCs are the reason email from any provider works with any other. This document refers to them when distinguishing the visible “from” address (one RFC) from the hidden envelope address (another).
The platform used to design, manage, and send marketing or lifecycle email to a list of people — in our case, Braze.
Why it matters: The ESP is where campaigns are built and where the visible “from” address is configured. The ESP relies on an MTA underneath it to do the actual sending.
A third-party service that an ESP relies on to perform part of its job. Braze uses a sending sub-processor as its MTA — for Outward Bound, that is SparkPost.
Why it matters: It explains why “sending from Braze” really means Braze plus a sub-processor. The sub-processor’s infrastructure is what appears in the technical delivery records.
A dedicated branch of the domain — such as c.outwardbound.org — used only for sending bulk email, kept separate from the main domain that runs staff mail and the website.
Why it matters: Separation protects the main domain’s reputation. But a sending subdomain is built to send only — it has no inbox — which is exactly why replies to it fail.
A holding area where a mail system places suspicious messages — not the inbox, and not always the visible junk folder. Messages can sit there unseen by the recipient.
Why it matters: Quarantine is why “I checked my junk and it isn’t there” does not mean a message was delivered. It can be held administratively, out of sight.
The practice of gradually increasing email volume from a new sending address or server, so receiving systems learn to trust it instead of treating a sudden surge as suspicious.
Why it matters: A brand-new sending domain starts with no reputation. Warming explains why the earliest sends underperform and why a measured ramp-up is part of the plan.
The hidden address an email is technically sent “from” at the delivery layer — separate from the visible “from” a recipient sees. Bounces (NDRs) go here.
Why it matters: Email carries two “from” addresses. The Return-Path on the sending subdomain is correct and normal; the problem is only when the visible from also shows the subdomain.