DKIM for third-party senders, explained plainly

A lot of college email is not sent by the college mail server. Event platforms, newsletter tools, and admissions systems all send on the college's behalf. I worked DKIM setup for CampusGroups and Slate with the vendors and CUNY Central. CampusGroups passes DKIM, SPF, and DMARC as of September 2026. Slate is waiting on a Central ticket. Constant Contact is still open.

The short version

DKIM lets a receiving server check that a message was signed by a key the domain owner published. When a third-party service sends as your domain, it needs its signing key published in your DNS.

The CNAME pattern

Most services give you one or two CNAME records. Each one points a selector under your domain to a key the service hosts. Publishing a CNAME instead of the raw key means the vendor can rotate keys without asking you to edit DNS again.

The order that works

1. Add the CNAME records the vendor gives you.
2. Wait for DNS to propagate and let the vendor verify them.
3. Turn on signing in the vendor's settings.
4. Send a test message and check the headers for a DKIM pass.

What actually broke

The selector CNAME was published on the wrong host and had to be moved.

Student mail bounced with 550 5.7.1 relaying denied until the vendor's sending IPs were added to the Proofpoint allowed relay.

One stu-mail MX record pointed at another campus's Proofpoint cluster.

When mail still bounces

Authentication is only half of it. Gateways like Proofpoint can still hold or reject mail, so bounce messages and relay logs are the next place to look.