Body
Learn about the technical requirements for third-party platforms and vendors authorized to send email on behalf of North Central University, including how our email authentication works, what your technical team needs to configure, and the steps required before your platform can go live.
How NCU email authentication works
When your platform sends email that appears to come from an NCU address, the receiving mail server checks whether that message was actually authorized by NCU. This verification process is called email authentication, and NCU uses two standards to enforce it: DKIM and DMARC.
DKIM (DomainKeys Identified Mail) works like a digital signature — your platform cryptographically signs each outgoing message to prove it came from an authorized source. DMARC is the policy layer that tells receiving mail servers what to do if that signature is missing or invalid.
NCU does not use or support SPF (Sender Policy Framework) for third-party senders. This is a deliberate security decision. As long as your platform is configured for DKIM correctly, your messages will pass authentication and reach recipients without issue — SPF is not needed.
SPF is not supported — do not request SPF changes
Your platform may prompt you or your team to request an SPF record update from NCU. Do not submit that request. NCU does not add SPF entries for any third-party platform — and that won't change.
If your platform requires SPF to function, it is not compatible with NCU's email environment. Your technical team should configure DKIM-based authentication as described below instead.
| What your technical team needs to configure |
|
If you're not the technical person responsible for your platform's email setup, forward this page to them. The three requirements below are what they'll need to address before submitting anything to NCU IT.
If you are the technical contact — configure DKIM signing on your platform according to the following requirements, then use the request form at the bottom of this article to send your parameters to NCU IT.
1. Record type — CNAME delegation strongly preferred
What this means: Rather than giving NCU a static key to publish, your platform provides a pointer (a CNAME record) to its own infrastructure. This lets your platform rotate its cryptographic keys on its own schedule without NCU needing to make DNS changes each time.
Provide CNAME targets pointing to your platform's infrastructure when submitting your parameters.
Fallback: If your platform cannot support CNAME delegation, provide a standard TXT record containing a minimum 2048-bit RSA public key. Note that future key rotations under this method will require coordination with NCU IT each time — this adds overhead for both sides.
2. Selector name — must be unique to your platform
What this means: A selector is a label in the DNS record that identifies which DKIM key to use. Because NCU may authorize multiple platforms, each one needs its own distinct label so they don't conflict.
Provide a distinct, platform-specific selector string — typically your platform's name or a unique identifier it assigns. Generic defaults are not accepted.
|
Not accepted — generic selectors
default
s1
mail |
|
Accepted — platform-specific selectors
salesforce1
hubspot-ncu
em7890 |
3. DMARC alignment — required
What this means: The domain in your platform's DKIM signature must match the domain shown in the From: address that recipients see. If your platform signs messages using its own domain instead of NCU's, the signature won't align — and the message will fail authentication regardless of whether DKIM is technically present.
Technically: the d= tag in the DKIM signature header must match or align with the domain in the visible From: header.
Platforms that cannot sign on behalf of a customer's domain — only their own — are not compatible with NCU's email environment and cannot be authorized.
Note: NCU IT may assign a sending subdomain
In some cases, NCU IT may provision a vendor-specific subdomain (e.g., service.northcentral.edu) for your platform to send from rather than the primary domain. This is done at IT's discretion to isolate sending reputation. If a subdomain is assigned, your platform must be capable of sending from and aligning DKIM to that subdomain. Your NCU IT contact will communicate this during the setup process if applicable.
Once you submit your parameters, NCU IT handles all DNS configuration on our end. You do not need to create or modify any DNS records yourself — this section is provided for reference so your technical team knows what NCU will be publishing.
The record will follow this structure, using the selector name and target you provide:
| Record Type |
Hostname / Name |
Target / Value |
| CNAME (preferred) |
[your-selector]._domainkey.northcentral.edu |
[your-platform-dkim-target].com |
| TXT (fallback) |
[your-selector]._domainkey.northcentral.edu |
v=DKIM1; k=rsa; p=[2048-bit-public-key] |
| Validation and go-live process |
|
After NCU IT applies your parameters, there are three steps before your platform is cleared for production. Plan for up to 24–48 hours between submission and go-live.
|
1
|
Propagation window. Allow up to 24 hours after NCU IT confirms your record is published. DNS changes don't take effect instantly — they distribute across the internet gradually.
|
|
2
|
Validation test. Your platform sends a test email to a validation mailbox that NCU IT provides. This confirms the DKIM signature is working end-to-end before any real mail goes out.
|
|
3
|
Sign-off. NCU IT reviews the test message headers to confirm dkim=pass and DMARC alignment. Once confirmed, your platform is authorized for production traffic and you'll receive written sign-off from your NCU IT contact.
|
Do not begin sending production email until NCU IT provides written authorization
Messages sent before authorization is confirmed may be rejected or flagged as suspicious. Wait for explicit written sign-off from your NCU IT technical contact before enabling your platform for production use.
NCU IT is responsible for configuring and maintaining the DNS records that authorize your platform. The following responsibilities remain with you and your platform.
Reply-to address
What this means: When a recipient replies to an email your platform sends on NCU's behalf, where does that reply go? Some platforms default to routing replies to their own system rather than back to NCU. This can cause confusion for recipients who believe they are replying to NCU directly.
NCU does not require a specific reply-to configuration, but you will be asked to disclose your platform's reply-to behavior during the setup process. If replies will not be routed to an NCU-controlled address, your NCU staff contact should be aware and agree to that arrangement before authorization is granted.
Bounce handling
What this means: When a message cannot be delivered — due to an invalid address, a full mailbox, or a server rejection — a bounce notification is generated. Your platform is responsible for receiving and acting on those bounces. Unmanaged bounces (continuing to send to addresses that have bounced) can harm NCU's domain reputation with receiving mail servers.
You will be asked to provide the address or mechanism your platform uses to handle bounces. Most established platforms manage this automatically — your technical team should be able to confirm how it works for your specific configuration.
Sending volume
What this means: High sending volumes with poor deliverability — low engagement, high bounce rates, or spam complaints — can negatively affect NCU's overall domain reputation, which impacts all email sent from NCU addresses, not just yours.
You will be asked to provide an estimated sending volume (approximate messages per month) during setup. If your volume or use case changes significantly after authorization, notify your NCU IT contact.
CAN-SPAM compliance
What this means: The CAN-SPAM Act establishes requirements for commercial email, including providing a working unsubscribe mechanism, honoring opt-out requests promptly, and including a valid physical mailing address in messages. These obligations apply to commercial email sent using NCU's domain regardless of which platform sends it.
Compliance with CAN-SPAM and any other applicable email regulations is the responsibility of your organization and platform — not NCU IT. You will be asked to acknowledge this as part of the setup request.
Once your platform is configured and your technical team has the DKIM record parameters ready, use the form below to submit them to NCU IT. You'll need to provide your selector name, record type (CNAME or TXT), and the full target or key string.
If you're not sure what to submit, loop in your platform's technical support team — they should be able to provide these values directly.
Submit your request as early as possible. In most cases, NCU IT will need to connect with you before any configuration begins — plan for at least 3–5 business days from the time a complete, verified request is received. Timelines vary depending on the information provided and any back-and-forth required to clarify or complete the request.
Submit Third-Party Email Sender Parameters →