How a German EdTech platform serving 2 million learners across 40 countries built a multi-domain email architecture that simultaneously resolved filtering at corporate gateways, university IT departments, and consumer Gmail — three inbox environments with conflicting filtering logic.
A German EdTech platform based in Berlin serves 2 million learners across 40 countries through a mix of self-paced online courses, instructor-led cohorts, and corporate-training contracts. Email is operational infrastructure for this business: assignment deadlines, course completions, certificate deliveries, instructor messages, and — increasingly — compliance-relevant notifications for regulated continuing-education credit. In early 2024, internal analytics confirmed a three-way delivery problem that the platform had been working around for over a year without resolving it.
At corporate-subscriber gateways (primarily Microsoft 365 and Google Workspace tenants with aggressive filtering policies), course notifications were being filed as promotional and filtered to junk folders that most employees never review. At university-sponsored learner accounts (where students used an academic email address provided by their institution), university IT departments were outright blocking email from the platform's commercial sending domain — a pattern common across German, Nordic, and Baltic universities that maintain strict whitelists for external senders. At consumer Gmail, inbox placement had dropped to 68% because the mix of promotional and operational email on the same sending reputation had slowly degraded the domain's standing.
Presenting Problems
- Corporate gateway inbox placement at 61% — course notifications routed to junk at Microsoft 365 and Google Workspace enterprise tenants
- University domain blocks: roughly 44% inbox placement at academic institutions, with complete blocks at several major German and Scandinavian universities
- Consumer Gmail inbox placement at 68% — the passive-learner segment (users who had not engaged in 90+ days) was triggering Gmail's engagement-based filtering
- Single sending domain (platform.com) used for course notifications, marketing upsells, instructor messages, and administrative email — no separation
- Marketing complaint rate at 0.15% was dragging down reputation for operational email that had a complaint rate of 0.02%
- No visibility into per-recipient-type placement — the platform could not distinguish corporate from academic from consumer delivery without manual log analysis
The engagement did not start as an emergency. The deliverability problem was slow-compounding rather than acute, and the platform had tolerated it for 14 months. What triggered the migration was a corporate client — one of Germany's largest industrial employers with a 30,000-seat contract — threatening non-renewal because learners at their domain were missing assignment deadlines. Speed mattered, but not at the expense of architectural precision.
-
Week 1: Domain architecture design and DNS staging
Three new subdomains registered and configured:
courses.platform.defor academic and course-operational email,news.platform.defor marketing and promotional content, andcertificates.platform.defor certificate delivery and verification. Each subdomain received its own SPF, DKIM, and DMARC record — independently configurable, independently monitored. The parent domain retained a strict DMARC policy (p=reject) with subdomain protection (sp=reject) to prevent any unauthorized subdomain spoofing. -
Week 2: IP provisioning and PTR configuration
Seven dedicated IPs provisioned across two datacenter regions (Frankfurt primary, Amsterdam secondary) for GDPR data residency and failover capacity. Four IPs assigned to courses.platform.de, two to news.platform.de, one to certificates.platform.de. Reverse DNS (PTR) was configured with academically-oriented naming for the course IPs — a subtle but meaningful signal for university mail administrators who review external sender profiles before whitelisting.
-
Weeks 3–6: Course notification IP warming
The most engaged learner cohort (users who had completed at least one course in the previous 30 days) was migrated first to establish positive reputation on the new IPs. Warming ramped from 5,000 messages per day per IP to 40,000 per day over four weeks. Corporate and consumer traffic was migrated progressively during this window; university traffic was deliberately held back until reputation was established, to avoid exposing new IPs to the strictest filtering environment before they had warmed.
-
Weeks 7–9: University outreach and full cutover
With course IPs fully warmed and stable on corporate and consumer segments, the university segment was migrated with parallel outreach to IT administrators at the ten largest academic tenants. The outreach included technical documentation (SPF, DKIM, DMARC records, PTR records, sending patterns) and a request for domain whitelisting. Seven of the ten universities whitelisted within two weeks; the remaining three required a formal DPA review that completed by Week 9.
Technical Assessment: Infrastructure Layers Examined
The pre-migration audit focused specifically on the three inbox environments this platform had to serve. Each has its own filtering logic, reputation signals, and remediation paths, and the single-domain configuration in place made it impossible to isolate signals from any one of them.
Corporate Gateway Behaviour
Corporate Microsoft 365 tenants with aggressive filtering policies (Mimecast, Proofpoint, or Microsoft's own ATP in strict mode) evaluate sender reputation at the domain level, not just the IP level. A mixed-reputation domain sending both marketing and operational content is penalized because the corporate gateway cannot distinguish "course completion notification" from "upsell campaign" without content inspection — and content inspection at scale is expensive. The gateway's default is to classify the entire domain's traffic based on the highest-complaint stream. With a 0.15% complaint rate from marketing, the entire platform.com domain was treated as promotional.
The migration to courses.platform.de for operational email, with a complaint rate below 0.02%, moved corporate gateway inbox placement from 61% to 94% within six weeks of warming completion. The marketing traffic on news.platform.de retained its 0.15% complaint rate but no longer contaminated operational reputation — the corporate gateways filter news.platform.de more aggressively, which is the correct behaviour for promotional content.
University Mail System Whitelisting
University IT departments across German-speaking Europe, the Nordics, and the Baltics commonly operate on an explicit-whitelist model for external commercial senders. This is not something that can be worked around through reputation or authentication alone — the sending domain must be known to the university IT administrator and explicitly approved. Several of the major universities serving the platform's learners (LMU Munich, University of Helsinki, University of Vilnius among them) had blocked platform.com entirely because it had never been whitelisted.
The outreach process during Weeks 7–8 produced a reproducible playbook: a technical one-pager documenting the platform's sending domain, dedicated IPs, authentication configuration, and a statement that the infrastructure is operated under a DPA compliant with GDPR data residency within the EU. This document, sent to the IT administrator's listed contact address, produced whitelisting within 7–14 days in seven of ten attempts. The remaining three institutions required a formal DPA review through their procurement office, which completed inside two additional weeks.
Consumer Gmail Engagement Filtering
Gmail's engagement-based filtering degrades inbox placement for domains with a high proportion of recipients who do not open, click, or otherwise interact with recent mail. The platform's learner base included a substantial passive-learner segment — users who had registered, taken one or two courses, and then disengaged without unsubscribing. These accounts were still receiving course catalogue updates and re-engagement campaigns, and their low interaction rate was a drag on Gmail reputation for the entire domain.
The solution had two components. First, the domain split moved course notifications (which passive learners rarely open but never complain about) onto operational infrastructure where the metric that matters is spam rate, not open rate. Second, the marketing domain news.platform.de implemented a strict engagement-based sending policy: recipients with no opens in 120 days were removed from marketing campaigns and offered a re-engagement path via courses.platform.de, where the email was transactional course activity rather than promotional content. This segmentation lifted consumer Gmail inbox placement from 68% to 91% for the course stream.
Infrastructure Rebuild: Configuration Decisions
Three configuration decisions shaped the outcome more than any single technical choice:
Independent DMARC policies per subdomain. Each subdomain runs its own DMARC record with its own aggregate-report destination. This means reputation signals and authentication failures are segmented by business function rather than aggregated at the parent domain. The aggregate reports for courses.platform.de are reviewed by the operations team; those for news.platform.de by the marketing team; those for certificates.platform.de by the compliance team. Each team sees the signals relevant to their stream without noise from the others.
PTR records calibrated for audience. The reverse DNS entries for each IP reflect the subdomain they serve. Course-notification IPs resolve to names like mx-courses-01.platform.de — immediately parseable by a university IT administrator reviewing an unfamiliar sender. Marketing IPs resolve to mx-news-01.platform.de. This is not a technical requirement for delivery, but it is a professional signal that sophisticated receiving infrastructure reads. A PTR record of vm-14872.host.example.net on an IP sending academic email communicates the wrong thing.
Per-subdomain feedback loop enrollment. FBL subscriptions were registered separately for each subdomain at every major ISP (Yahoo, Microsoft, Comcast, AOL). Complaint data flows to the team responsible for the stream. A complaint on news.platform.de is a marketing-team signal; a complaint on courses.platform.de is an operations-team signal about notification frequency or UX. Segregating this data at the feedback-loop level meant neither team could hide behind aggregated metrics that averaged their stream's performance with an unrelated one.
platform.com/unsub — the old domain, which was now marked as medium-risk at Gmail. The link shortener and redirect chain were signalling to Gmail that this "new" domain was associated with the old one. Updating the templates to point unsubscribe URLs to courses.platform.de/unsubscribe produced a measurable reputation improvement within 72 hours.
Operational Monitoring: What Changed Permanently
The multi-domain architecture requires more sophisticated ongoing monitoring than a single-domain configuration. Three practices were embedded into the platform's operations team workflow:
Per-subdomain Postmaster Tools review. Each of the three sending subdomains has its own Google Postmaster Tools property, its own Microsoft SNDS IP list, and its own review cadence. Course-notification reputation is reviewed every business day. Marketing-stream reputation is reviewed twice a week. Certificate-delivery reputation is reviewed weekly but any deviation triggers same-day investigation because certificate failures have direct business impact (learners cannot receive verified credentials).
University whitelist maintenance. The whitelist obtained from 10 major academic tenants is a relationship, not a one-time action. When the platform deploys a new IP, that IP needs to be communicated to the whitelisting administrators in advance — universities with strict allowlists will block a previously-unknown IP even if the sending domain is whitelisted. The operations team maintains a contact registry for the 23 academic tenants representing more than 70% of university-affiliated learner volume.
Quarterly engagement re-segmentation. The passive-learner threshold (users with no opens in 120 days) is re-evaluated quarterly against the platform's actual curriculum calendar. A learner who has not opened mail in 120 days during a summer term may simply be on academic break; a learner who has not opened during the active term is genuinely disengaged. The threshold is adjusted seasonally to prevent false-positive suppression that would harm re-engagement opportunities.
inbox placement (from 61%)
inbox placement (from 44%)
inbox placement (from 68%)
(from 97.1%)
"Students were missing assignment deadlines because notifications were going to spam, and our corporate clients were threatening non-renewal over it. The multi-domain architecture separated our operational email from our marketing in a way that fixed both problems simultaneously. The university whitelist work took longer than the technical migration, but it was the piece that mattered most for our academic subscribers."
— Head of Product, EdTech PlatformThe technical changes in this engagement were straightforward. The more significant work was establishing the monitoring discipline that prevents the gradual drift that caused the original problems — an infrastructure that meets today's ISP requirements but has no ongoing review process will fall behind those requirements within 12-18 months.
— Cloud Server for Email Infrastructure TeamEdTech platforms operate in an unusual email environment: they serve multiple inbox types simultaneously, each with its own filtering logic. Corporate gateways reward low-complaint operational sending and penalize mixed-reputation domains. Academic institutions operate on an explicit-whitelist model that cannot be bypassed by reputation or authentication alone — it is a relationship management problem, not a technical one. Consumer Gmail filters based on per-recipient engagement signals aggregated at the domain level. No single domain can optimize for all three, because optimizing for one constrains the others.
The operational separation that solved the delivery problem — courses, marketing, and certificates on independent subdomains with independent reputation — also produced a secondary benefit that the product team had not anticipated: each stream now has clean analytics. The marketing team can see actual marketing performance without being confounded by the much higher engagement rates of operational email. The operations team can detect notification issues without marketing-campaign noise. Architecturally, segmentation is a delivery tool; organizationally, it is an accountability tool.