DKIM for third-party senders, explained plainly
What I learned setting up DKIM signing for tools like CampusGroups, Constant Contact, and Slate.
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 led projects to get DKIM signing working for several of them, including CampusGroups, Constant Contact, and Slate.
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
- Add the CNAME records the vendor gives you.
- Wait for DNS to propagate and let the vendor verify them.
- Turn on signing in the vendor's settings.
- Send a test message and check the headers for a DKIM pass.
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.