A working diagram of how Braze composes, signs, routes, and delivers email on behalf of outwardbound.org — and how dedicated sending subdomains (c., t., and the planned per-school subdomains) fit into the picture. Built to ground deliverability and authentication conversations in the actual mechanism, not the symptoms.
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.
These are the recurring conversations that come up whenever someone receives a Braze-sent email and notices something unusual in the From line, the Reply behavior, or a Gmail annotation. Each is answered in detail in §6; the diagram sections that come before exist to make those answers stand on a shared mechanical understanding.
Braze sends marketing email from a dedicated subdomain by design. That subdomain owns its own DKIM signature, SPF authorization, and bounce-handling — which is what makes the marketing reputation isolated from corporate mail on the root domain. Where things go wrong is when the visible From address (what recipients see) drifts onto the subdomain too — that's a workspace configuration setting, not a fix in DNS or authentication.
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 recipient interacting with one of our emails can produce three different return paths — a human reply, a server-generated bounce, or an address-book-driven new email. The diagram below separates them so each can be reasoned about independently.
The questions below are the recurring ones raised whenever a Braze-sent email is examined for technical correctness. Each is answered against the architecture in sections 01–05.
When the visible From shows the subdomain, it's because the Braze workspace's default From address — or an individual campaign or Canvas override — was set on the subdomain. The sending infrastructure is working as designed; the configuration is just pointing the visible From at the wrong layer of the architecture.
The correct setup is visible From on a recognizable root-domain address (e.g. giving@outwardbound.org) while envelope, DKIM, and bounce path stay on the subdomain. This is set at both the workspace default level and pinned at each campaign / Canvas level so future workspace setting changes can't silently regress it.
Two distinct NDR paths exist in this architecture, and they behave very differently:
Server-generated bounces (Path B in §5) are sent to Return-Path, which points to the bounce mailbox on the subdomain. Braze captures these, marks the user as bounced, and the recipient never sees an NDR loop. This is correct and working — and it's the actual purpose of the subdomain Return-Path.
Recipient-initiated bounces (Path C) happen when a recipient sends new mail to a cached subdomain address. This is the failure mode worth taking seriously, because the sending subdomain has no inbound MX record — there is nowhere for that mail to land. When the visible From is set correctly on the root domain, no new emails leave with the subdomain in the From field, so no new entries get cached this way going forward.
Gmail's "Other contacts" and Outlook's recipient cache both auto-populate from the visible From address. Any recipient who interacted with an email that had the subdomain in From may have @<subdomain>.outwardbound.org cached.
Going forward: No new emails populate the cache with the subdomain. Every future send caches the correct root-domain address instead, and that's what surfaces first in autocomplete on subsequent interactions.
Existing cached entries: These age out naturally as recipients receive newer emails from the correct address. Most clients down-rank stale entries fairly aggressively. No cleanup is possible from our side — we can't reach into anyone's address book — but the impact decays over weeks rather than years.
Not necessarily. Gmail displays the "via" annotation whenever the Return-Path domain (envelope From) differs from the visible From domain — even when DMARC passes. After the From change:
• Visible From: outwardbound.org
• Return-Path: c.outwardbound.org
The organizational domains match (so DMARC is happy), but the literal domains differ (so Gmail's annotation logic may still trigger). Per Google's documentation, the "via" annotation cannot be removed; it's an informational signal. A seed send confirms the actual rendered behavior before going live.
If the annotation does persist, it's far less alarming than the misconfigured state because the address itself now clearly reads as Outward Bound. The annotation just adds context about which infrastructure carried the mail.
No. DMARC's relaxed alignment mode treats subdomains and the root as the same organizational domain. With DKIM signing on d=c.outwardbound.org and the From on @outwardbound.org, alignment passes via DKIM. SPF on the Return-Path subdomain continues to authenticate normally. No DNS changes are required for the From change itself; it's a Braze workspace and campaign configuration change only.
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.