Add SendGrid or Mailgun DKIM Without Breaking cPanel Email

You've decided to route WooCommerce order emails, password resets, or marketing mail through SendGrid or Mailgun instead of your server's own Exim. The ESP's setup wizard tells you to add a DKIM record. You do it, mail starts flowing — and a week later someone on your team can't send from their regular @yourdomain.com mailbox, or your own transactional mail starts landing in spam. This is one of the most common ways we see cPanel domains break their email reputation, and it's almost always fixable in fifteen minutes once you understand what actually went wrong.

Symptom: one email stream breaks when you set up another

The pattern is usually one of these:

• You added the ESP's DKIM record, and now regular mail sent from Webmail or Outlook through cPanel starts failing DKIM checks
• SPF passes for one sending source but fails for the other — SendGrid mail is clean, but cPanel mail now shows spf=softfail or vice versa
• You overwrote the TXT record cPanel created for its own default._domainkey selector, thinking it was the same thing as the ESP's record
• DMARC reports (if you're pulling them) show one sending source failing alignment while the other passes

None of this means SendGrid or Mailgun is broken. It means the domain now has two separate mail-sending identities sharing one DNS zone, and DKIM/SPF weren't set up to let both coexist.

Cause: DKIM is per-selector, not per-domain

This is the part most setup guides skip. A DKIM record doesn't live at a fixed address like yourdomain.com — it lives at:

<selector>._domainkey.yourdomain.com

cPanel's own mail server already publishes one, typically at default._domainkey.yourdomain.com, so that mail sent through Webmail, Outlook, or a WordPress contact form using local Exim can sign itself. SendGrid and Mailgun each want their own selector — SendGrid usually asks for records like s1._domainkey and s2._domainkey, Mailgun uses something like mg._domainkey or a custom subdomain such as mg.yourdomain.com.

The break happens one of two ways:

1. Someone pastes the ESP's record over cPanel's existing default._domainkey entry instead of adding a new one, because the setup wizard just says "add this DKIM record" without mentioning the selector name matters.
2. SPF gets a second, conflicting record instead of an added include:. SPF only allows one TXT record per domain — if your zone ends up with two separate v=spf1 lines, most receiving servers treat that as a permanent error and fail the whole check, for every sender.

Fix: add records side by side, don't replace

1. Check what's already in your DNS zone

In cPanel, go to Domains → Zone Editor → Manage for the domain, and list every TXT record. You're looking for one v=spf1 record and one or more _domainkey entries. Note the exact selector names already in use before you add anything.

2. Add the ESP's DKIM record under its own selector

Add it as a brand-new TXT (or CNAME, if the ESP provides one) record using the exact selector they give you — don't touch the existing default._domainkey record. For example, alongside cPanel's:

default._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

you'd add SendGrid's as a separate record:

s1._domainkey.yourdomain.com   CNAME   s1.domainkey.u1234567.wl123.sendgrid.net
s2._domainkey.yourdomain.com   CNAME   s2.domainkey.u1234567.wl123.sendgrid.net

Both can exist at the same time because they're different hostnames. Mailgun works the same way, usually with a selector like mta._domainkey or under a dedicated subdomain such as mg.yourdomain.com so it doesn't touch your root domain's records at all — if Mailgun offers that option, it's the cleanest choice.

3. Extend SPF instead of adding a second record

Edit your existing v=spf1 record and add the ESP's include. Don't create a new TXT record starting with v=spf1 — merge it into the one that's already there.

For Mailgun it's include:mailgun.org. Stay under 10 SPF lookups total or you'll trade this problem for a permerror from too many DNS lookups.

4. Verify both senders independently

Send one test email through Webmail (or a WordPress form using local mail) and one through the ESP's test tool, then check both at mail-tester.com or in Gmail's "Show original" view. You want to see dkim=pass with the correct selector listed in the d=/signature header for each source, and spf=pass for both.

5. Don't forget DMARC alignment

If your DMARC policy uses strict alignment (adkim=s or aspf=s), the signing domain in DKIM has to exactly match your visible From domain — a subdomain-based Mailgun setup (mg.yourdomain.com) can fail strict alignment even though DKIM itself passes. Relaxed alignment (the default, adkim=r) is fine for this case. Check your existing DMARC record in Zone Editor before assuming it's the default.

Prevention

• Keep a running note of every selector in use for the domain — when you add a third sender six months from now, you won't have to reverse-engineer the zone file first
• Never let an ESP's onboarding wizard "replace" a DKIM record; always add it as new
• Only ever have one v=spf1 record per domain, merged
• Re-run a mail-tester check after any DNS change to a mail-related record, even one that looks unrelated
• If you stop using an ESP, remove its DKIM and SPF include — stale entries widen your attack surface without helping deliverability

If you're not sure what's already live on a domain we host, open a ticket and we'll pull the zone file with you before you touch anything — it's a five-minute check that avoids an afternoon of "why did my order emails stop" later.