THE UNIVERSITY OF NORTH CAROLINA AT
CHAPEL HILL
3500 Administrative Office Building
104 Airport Drive
Chapel Hill, NC 27599
Request for Information (RFI) No.: RFI120325AMG
Title: MassMail Modernization / Replacement
Refer ALL inquiries regarding this RFI to:
Name: Alicia Grieger
Title: IT Category Manager
E-mail Address: agrieger@email.unc.edu
Issue Date: December 3, 2025
Due Date and Time: January 5, 2026 at 12:00 PM
Eastern Time (ET)
RESPONSE SUBMITTAL
Vendor’s response to this RFI must be submitted by the due date and time listed above, via the North Carolina
electronic Vendor Portal (eVP), located at https://evp.nc.gov/.
Additional information can be found via the North Carolina eProcurement Vendor Training link:
https://eprocurement.nc.gov/training/vendor-training.
Questions or issues related to using the eVP should be directed to the North Carolina eProcurement Help Desk
– reference the following link: https://eprocurement.nc.gov/contact.
QUESTIONS
Questions may be submitted via e-mail to the contact listed above until December 12, 2025 at 12:00 PM ET (the
“Written Questions Deadline”). Please enter “RFI No. RFI120325AMG – Questions” in the subject line of your
e-mail. A summary of all questions received by the Written Questions Deadline and answers to those questions
will be posted to eVP as an addendum to the RFI on or about December 19, 2025.
EXECUTION
VENDOR NAME:
STREET ADDRESS:
CITY & STATE:
TYPE OR PRINT NAME OF PERSON SIGNING:
TYPE OR PRINT TITLE OF PERSON SIGNING:
AUTHORIZED SIGNATURE:
P.O. BOX:
ZIP:
TELEPHONE NUMBER:
E-MAIL:
DATE:
1
1.0 INTRODUCTION
The University of North Carolina at Chapel Hill (“the University”) is evaluating the modernization or replacement
of its existing in-house MassMail system. The current solution consists of several .NET-based microservices
coordinating audience selection, workflow approval, email campaign creation, delivery, analytics, and reporting.
The University is seeking detailed vendor input on contemporary high-volume, enterprise-grade bulk email
communication solutions that support complex workflows, directory integration, accessibility, compliance, and
strict delivery performance targets.
This Request for Information (RFI) is being issued solely to collect information which may be used by the
University to inform the direction and scope of a potential future solicitation.
2.0 DISCLAIMER
This RFI is issued for information and planning purposes only and does not constitute a solicitation. Responses
to this RFI are not offers and cannot be accepted by the University to form a binding contract. Subject to Section
11.0 (Trade Secrets) of this RFI, all responses to this RFI shall become the property of the University when
received, and the University may use any information included in any response for purposes of developing any
future solicitation.
THE UNIVERSITY MAKES NO COMMITMENT TO PURCHASE ANY PRODUCTS OR SERVICES UNDER
THIS RFI. THE UNIVERSITY WILL NOT PAY FOR INFORMATION RECEIVED IN RESPONSE TO THIS RFI.
THE VENDOR WILL SOLEY BEAR ANY COSTS INCURRED IN PREPARATION AND SUBMISSION OF A
RESPONSE TO THIS RFI.
3.0 DEPARTMENT BACKGROUND
MassMail is managed by Identity & Access Management (IAM) in partnership with University
Communications and ITS Operations. It is the official mechanism for distributing formal campus notices and
broad informational messages to students, employees, retirees, affiliates, and other university populations.
The current system:
• Sends ~7.5 million messages per year.
• Supports audiences derived from LDAP/Active Directory, HR systems, student systems, and file-
based uploads.
• Implements multi-step approval workflows, preventing self-approval.
• Uses Microsoft 365 / Exchange Online for final message delivery.
• Relies on .NET microservices, including:
o Gateway API (UI proxy and orchestration)
o MassMail DAL API (business logic, SQL, audience resolution)
o MassMail Activity API (tracking pixel and open events)
o LDAP API (directory-sourced audience data)
o SQL Server database and SQL Service Broker for background processing
• Operates within strict performance constraints:
o Delivery of campus-wide campaigns must complete in ≤ 20 minutes.
o Audience counts in UI must update in ≤ 2 seconds.
o Campaign processing must begin immediately when queued.
The University intends to maintain these capabilities, strengthen compliance and observability, and improve
overall system reliability, usability, and scalability.
2
4.0 CURRENT STATUS
The in-house MassMail implementation contains the following characteristics:
Architecture & Services
• Gateway API and Self-Service API that route UI requests and apply permissions.
• MassMail DAL API handling campaign persistence, workflow actions, comments, audience resolution,
analytics, suppression, and system configuration.
• MassMail Activity API provides open detection via tracking pixel requests.
• Directory Services Integration pulls LDAP user, affiliate, and student population data into MassMail-
local tables for query performance.
• SQL Service Broker handles background message dispatch.
• Microsoft 365 / Exchange Online is the authoritative sending system.
Campaign Workflow
• 4-step campaign wizard (basic info, audience, content, summary).
• Approval workflow supporting multiple approvers across employee/student segments.
• Templates for approval, denial, comment, cancellation notices.
• Test messaging before approval.
Audience Targeting
• Students (graduate, undergraduate)
• Employees (faculty, staff, DDD)
• Affiliates (contractors, volunteers, retirees, visiting scholars)
• TEST group
• Exclusions and include-only logic
• De-duplication across multiple sources
• Real-time counts
• LDAP-driven population tables
Performance
• Strict delivery SLA: complete within 20 minutes
• Audience count refresh: ≤ 2 seconds
• Monthly volume: 277K–1.07M messages
• Concurrency: current system processes one campaign at a time
• 25% scalability growth requirement
Compliance & Security
• FERPA protections for student email addresses
• Role-based access control and separation of duties
• SSO/OIDC authentication
• Logging to Splunk
• WCAG 2.2 AA UI accessibility requirement
• Strict sender verification (SPF/DKIM/DMARC)
• No PHI content (MassMail not HIPAA-related)
3
5.0 PROBLEM STATEMENT
The University seeks a replacement solution that preserves the functional richness of MassMail but eliminates
several current limitations:
• The current system is highly coupled to on-premises environments, increasing operational burden.
• Current workflow and audience logic are rigid and costly to modify.
• Analytics are basic compared to industry-standard engagement platforms.
• Delivery infrastructure is tightly bound to Exchange Online, limiting alternative routing.
• Background processing relies on SQL Service Broker, which is difficult to scale horizontally.
• UI and workflow improvements require significant custom code.
• Performance demands peak at levels that strain the existing service.
• Accessibility and usability improvements require substantial resources.
The University seeks vendor input on modern enterprise solutions capable of reducing or eliminating these
limitations.
6.0 DESIRED END STATE
A future solution should:
1. Preserve and improve core functionality
• Role-based campaign creation and multi-step approval workflows (no self-approval).
• Rich HTML content creation with accessibility guidance.
• Audience management with dynamic directory integration.
• Real-time population counts and de-duplication.
• Delivery tracking, analytics, and audit trails.
2. Meet strict performance targets
• End-to-end delivery SLA of ≤ 20 minutes for campus-wide sends.
• Audience count refresh ≤ 2 seconds.
• Scalable to 10M+ messages annually with a 25% growth margin.
3. Integrate seamlessly
• SSO/OIDC authentication
• LDAP/AD attribute-driven audience selection
• Microsoft 365/Exchange compliance (or equivalent transport validation)
• Splunk and Opsview monitoring
• Public records and eDiscovery exports
4. Improve maintainability and reliability
• Reduce custom code where possible
• Provide robust APIs and webhook support
• Improve observability and failure recovery workflows
5. Strengthen governance & compliance
• FERPA-compliant data handling
• Sender authentication safeguards
• Role-based access and audit trails
• Automated suppression for bounces and invalid addresses
4
7.0 RFI QUESTIONS
The University requests detailed responses to the following:
1. Architecture and Scalability
1. Describe your solution’s architecture (SaaS, on-prem, hybrid).
2. Explain how your system manages large-scale sends (≥7M/year).
3. Describe how your platform ensures delivery within defined SLAs (≤20 minutes).
4. How does your platform handle spikes to 1M+ messages/month and scale beyond?
5. Explain your system’s strategy for:
o Horizontal scaling
o Queue management
o Retry logic
o Back-pressure
o Concurrency limits
6. How does your solution ensure sender verification (DMARC, SPF, DKIM)?
7. Can your system integrate with Microsoft 365/Exchange Online, or provide equivalent safeguards?
2. Workflow and Functional Capabilities
1. Describe your workflow/approval engine and customization options.
2. Can multi-step review and separation of duties be enforced without vendor involvement?
3. How does your system handle:
o Comments
o Reviewer notes
o Change requests
o Test messaging
4. Can your system support:
o Cloned campaigns
o Saved drafts
o Repeating campaigns
o Department-specific templates
5. Can templates include both content and audience logic?
3. Audience Targeting, Directory Integration, and Data Connectivity
1. Explain your integrations with:
o LDAP / Active Directory
o HR systems
o Student systems
o External data sources
2. Can your system dynamically import or sync audiences?
3. Can the platform:
o Prevent duplicates
o Apply suppression rules
o Handle FERPA-protected data
4. Describe API endpoints and webhooks available for automation.
5. How do you ensure data minimization and privacy protections?
4. Security, Privacy, and Compliance
1. Provide details on FERPA compliance capabilities.
2. How is sensitive data protected at rest and in transit?
3. What safeguards protect against:
5
This is the opportunity summary page. It provides an overview of this opportunity and a preview of the attached documentation.