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.
| Why NCU does not use SPF for third-party senders |
|
DKIM satisfies everything SPF was designed to do — and does it more securely. Under DMARC, a correctly aligned DKIM signature is sufficient for authentication on its own. SPF is not needed, and adding it introduces risks that DKIM does not. The table below summarizes the key differences; the sections that follow explain each in detail.
| |
DKIM |
SPF |
| Cryptographic proof of origin |
Yes — message is signed with a private key |
No — IP address check only |
| Survives email forwarding |
Yes |
No — breaks on forwarding by design |
| Tenant-isolated per sender |
Yes — unique key pair per selector |
No — shared IP blocks, no cryptographic boundary |
| DNS complexity risk |
None |
Hard 10-lookup limit — exceeding it breaks auth for entire domain |
| Lifecycle / offboarding risk |
Low — key rotation is controlled |
High — orphaned includes persist in DNS after contracts end |
| Sufficient for DMARC alignment |
Yes — on its own |
Yes — but not needed when DKIM is present |
| Shared IP reputation exposure |
None |
Yes — other tenants on shared IPs can affect your deliverability |
1. Cross-tenant impersonation via shared IPs
Adding a vendor's SPF include: to a domain record authorizes their entire sending IP infrastructure. On shared email platforms, any other customer on those same IP pools can forge the domain in the envelope sender and pass SPF authentication. This is a documented vulnerability (CVE-2024-7209), not a theoretical edge case. DKIM's private/public key architecture eliminates this risk entirely — only the holder of the private key can produce a valid signature.
2. No cryptographic or payload integrity
SPF only authenticates the connecting IP address at the SMTP envelope layer. It provides no cryptographic proof that the message content is intact, cannot detect tampering in transit, and does not authenticate the visible From: header that recipients see. DKIM signs the message itself — any modification to the content after signing invalidates the signature.
3. DNS 10-lookup limit (PermError risk)
RFC 7208 limits SPF evaluation to a hard maximum of 10 DNS lookups per check, including all nested include: references. Exceeding this limit returns a PermError — receiving mail servers stop evaluating and treat SPF as failed, which DMARC interprets as a failure for the entire domain. Each vendor SPF include added consumes lookups from this budget. Organizations with multiple third-party senders routinely hit this limit, causing legitimate mail to fail authentication silently.
4. Orphaned access after vendor offboarding
When a vendor contract ends, their SPF include often remains in DNS indefinitely unless manually removed. This leaves permanent sending authorization for decommissioned infrastructure. In practice, DNS hygiene on SPF records is inconsistent — abandoned includes accumulate over time, expanding the authorized sending surface without any corresponding business relationship. DKIM keys are explicitly provisioned per vendor and can be cleanly revoked by removing the DNS record.
5. SPF breaks on email forwarding
SPF fails whenever legitimate email passes through a forwarding relay, mailing list, or intermediate security gateway — because the forwarding server's IP is not listed in the original domain's SPF record. This is a fundamental design limitation, not a misconfiguration. DKIM signatures travel with the message and remain valid through forwarding, making DKIM the reliable authentication mechanism for real-world mail flows.
6. No tenant isolation
SPF operates on IP CIDR blocks shared across all customers of a sending platform. There is no cryptographic boundary between tenants. DKIM requires a unique private/public key pair per sender — the selector and key are specific to a single authorized relationship. This means each vendor's authorization is isolated and independently revocable, with no risk of one vendor's key being used to authenticate another's mail.
7. Shared IP reputation exposure
Because SPF authorizes IP blocks rather than cryptographic identities, NCU's domain reputation becomes partially dependent on the behavior of every other customer sharing those IPs. If another tenant on the same sending platform generates spam complaints or poor engagement, the shared IP's reputation suffers — and NCU's mail delivered from that IP pool can be penalized by receiving spam filters as a result. DKIM-only authorization means NCU's reputation is determined solely by NCU's own sending behavior.
| 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 →