Opened Gmail's "Show original" on a Zendesk ticket reply and saw dkim=none. SPF passed. DMARC failed anyway.

The ticket went to spam. I found out three days later when the customer replied to a different email asking why we'd gone silent. (That was a fun conversation.)

Here's the thing: this happens constantly when you're using a CRM, helpdesk, invoicing tool, or any other SaaS that sends email on behalf of your domain. SPF isn't enough. Never has been. If DKIM shows "none" or is signed with the vendor's domain instead of yours, DMARC alignment breaks — and at p=quarantine or p=reject, your mail lands in spam or gets rejected outright.

We're the JustEmails team — JustEmails is built by Velocity Digital Labs. We see this exact problem in support tickets more than any other authentication issue, honestly. (Second only to teams wondering why Google Workspace costs so much.) It's invisible until you check raw headers. The vendor dashboard says "domain verified," SPF is passing, everyone assumes everything's fine. Nobody looked at DKIM alignment. This post walks through how to diagnose it, fix it, and verify the fix actually worked.

The Core Problem: SPF and DKIM Authenticate Different Things

Here's the thing most setup guides gloss over. SPF checks the Return-Path — the envelope sender — which is where bounces go. When a third-party tool sends on your behalf, the Return-Path is usually their domain, not yours. So SPF passes, but it passes for bounce.sendgrid.net or zendesk.com or hubspot.com. That doesn't align with your From address.

DKIM is different. DKIM signs the message headers with a private key, and the signature includes a d= tag specifying which domain's key to check. For DMARC to pass via DKIM alignment, that d= domain must match your visible From address (or be a subdomain in relaxed mode).

The math:

Your From address: support@yourdomain.com
DKIM d=: zendesk.com
Result: DKIM passes but DMARC alignment fails

Or worse:

DKIM: none (the vendor didn't sign the message at all)
Result: no DKIM to align, fall back to SPF, SPF doesn't align either, DMARC fails

That's why your helpdesk replies land in spam even though you've got SPF and DMARC set up "correctly." (If you're not at p=reject yet, our guide to ramping DMARC from p=none to p=reject covers that path.)

Step 1: Identify Which Senders Aren't Signing With Your Domain

Before you start adding DNS records, figure out where the problem actually is. Three ways to find unsigned senders:

Check DMARC aggregate reports. If you've got rua=mailto: in your DMARC record (and you should), you're getting daily XML reports showing every source sending as your domain and whether each passed SPF/DKIM with alignment. Tools like dmarcian, Postmark DMARC Digests (free tier), or Valimail parse these into readable dashboards. Look for sources where DKIM shows "fail" or "none" — those are your problem senders.

Send a test and check raw headers. From each third-party tool that sends as your domain — HubSpot, Zendesk, Freshdesk, QuickBooks, Stripe, Intercom, whatever you use — send a test email to a Gmail account. Open it, click the three dots, "Show original." Scroll to the authentication results:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=s1;
       spf=pass (google.com: domain of bounce@em1234.yourdomain.com designates ...)
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

That's what you want. If instead you see:

dkim=none (no signature)

or:

dkim=pass header.i=@sendgrid.net

...you've found the problem. The message either isn't signed, or it's signed with the vendor's domain, not yours.

Check your vendor's authentication status page. Most SaaS tools have a "Domain Authentication" or "Email Authentication" section in settings. HubSpot shows a green checkmark when custom DKIM is configured. Zendesk shows "Verified" next to each authentication method. If you see "Not configured" or "Pending" next to DKIM, that's your answer.

Step 2: Enable Custom DKIM in the Vendor Dashboard

Every major email-sending SaaS supports custom DKIM. The exact flow varies, but the pattern is the same:

Find the domain/email authentication settings
Enter your domain
Get CNAME or TXT records to add to your DNS
Add them
Click verify

Sounds simple. In practice, I've spent more hours than I'd like to admit hunting for the right settings page in various vendor dashboards. Here's what it looks like for common tools:

SendGrid: Settings → Sender Authentication → Authenticate Your Domain. They give you three CNAMEs — two for DKIM selectors (s1._domainkey, s2._domainkey) and one for link branding. Example:

s1._domainkey.yourdomain.com  CNAME  s1.domainkey.u12345678.wl.sendgrid.net
s2._domainkey.yourdomain.com  CNAME  s2.domainkey.u12345678.wl.sendgrid.net

HubSpot: Settings → Website → Domains & URLs → Connect a domain → Email Sending. They give you two CNAMEs for DKIM plus SPF include. The DKIM selector is usually hs1._domainkey and hs2._domainkey.

Zendesk: Admin Center → Channels → Email → Domain forwarding → SPF/DKIM. They provide a CNAME for zendesk1._domainkey.yourdomain.com pointing to their servers. One quirk: Zendesk also requires you to add their include: to your SPF, which you probably already did during initial setup.

Freshdesk: Admin → Email → Advanced Settings → Outgoing email domain authentication. Similar CNAME flow — selector is usually freshdesk._domainkey.

Stripe: Stripe is interesting because they send from their own domain by default (notifications@stripe.com), but if you use Stripe Invoicing with your own branding, you can configure custom sending via Settings → Business settings → Email branding. They'll give you CNAME records for DKIM.

Intercom: Settings → Email → Domain → Add domain. They provide three CNAMEs — one for envelope domain, two for DKIM selectors.

The key: don't just add the records and move on. After DNS propagates (give it 15 minutes to an hour, though some registrars take longer — I've seen GoDaddy take 4+ hours), go back to the vendor dashboard and click the verify button. (If you're setting up custom domain email from scratch, our complete custom domain email setup guide walks through the full DNS stack.) Most vendors cache DNS lookups, so they won't notice your new records until you explicitly ask them to check again.

This is annoying. You'd think they'd just poll automatically. They don't.

Step 3: Verify the Fix With "Show Original"

Once the vendor shows "verified" or a green checkmark, send another test email and check raw headers. You're looking for:

dkim=pass header.i=@yourdomain.com header.s=s1

The header.i=@yourdomain.com part is critical. That means the DKIM signature used your domain — alignment will work. If you see header.i=@sendgrid.net or similar, custom DKIM isn't actually enabled, even if the dashboard says it is.

Common reasons custom DKIM doesn't take effect:

DNS propagation isn't complete — wait and try again
You added the records to the wrong zone (e.g., to yourdomain.com when you should have added them to a specific subdomain the vendor told you about)
Typo in the CNAME target
The vendor requires you to re-send a verification email after adding records, and you didn't click the button
You're testing with a message sent before the records propagated — send a fresh test

Pro tip: Gmail's "Show original" displays authentication results at the top, but you can also ctrl-F for DKIM-Signature to see the actual signature headers and check the d= value directly. I do this more than I'd like to admit — raw headers are ugly but they don't lie.

The Subdomain Delegation Pattern

Sometimes custom DKIM on your apex domain isn't possible or practical. Maybe:

The vendor genuinely doesn't support custom DKIM (rare in 2026, but some smaller tools)
You want to isolate sender reputation — if the vendor has deliverability issues, you don't want it affecting your main domain
You're using multiple vendors and SPF is hitting the 10-lookup limit
Your IT policy requires separation between transactional and marketing sends

In these cases, subdomain delegation works. The idea: create a subdomain like mail.yourdomain.com or notifications.yourdomain.com, point its MX and authentication entirely to the vendor, and let them manage everything.

Setup:

Create the subdomain records the vendor specifies (usually MX, SPF, DKIM, and sometimes DMARC)
Configure the vendor to send from notifications@mail.yourdomain.com instead of notifications@yourdomain.com
Let the vendor's authentication cover that subdomain entirely

Example for a helpdesk on a subdomain:

mail.yourdomain.com      MX    10   mail.zendesk.com
mail.yourdomain.com      TXT   "v=spf1 include:mail.zendesk.com -all"
zendesk1._domainkey.mail.yourdomain.com   CNAME   zendesk1._domainkey.zendesk.com
_dmarc.mail.yourdomain.com   TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

Now support@mail.yourdomain.com authenticates entirely through Zendesk's infrastructure, with its own DMARC policy. Your apex domain's reputation stays untouched.

The trade-off: the From address changes from support@yourdomain.com to support@mail.yourdomain.com. Some brands find that awkward.

Honestly? I think it's fine. Customers don't parse the subdomain. They see your domain name, they trust it. But it's your call.

When to use subdomains vs. apex:

Use apex when the vendor supports custom DKIM and you want the cleanest From address
Use subdomains when you want isolation, can't get custom DKIM working, or are hitting SPF lookup limits

SPF Lookup Limits and Why They Matter Here

Quick detour, because this trips people up. SPF records have a 10-lookup limit. Each include: counts as a lookup, and nested includes count too. include:_spf.google.com alone burns 3-4 lookups because Google's SPF includes other records.

When you add a new vendor, check if you're over the limit:

dig +short TXT yourdomain.com | grep spf
# then check the includes

Or use MXToolbox's SPF lookup tool — it counts lookups for you. If you're at 9 and add a 10th, you'll probably be fine. At 11+, SPF fails entirely for some receivers.

Solutions:

Remove vendors you no longer use. There's always a forgotten Mailchimp include from 2019. Always.
Use SPF flattening services (they resolve includes to IP addresses, reducing lookup count — but you need to update when vendor IPs change)
Move some senders to subdomains, each with their own SPF record

This matters because you can't fix DKIM by just adding more SPF includes. They're separate mechanisms. But if adding a vendor's include: pushes you over 10 lookups, you've now broken SPF too — and that's worse than where you started.

What If the Vendor Doesn't Support Custom DKIM?

Rare in 2026, but it happens with smaller tools. You have three options:

Option 1: Accept DMARC failure on that sender. If you're at p=quarantine, this vendor's emails might land in spam. At p=reject, they'll bounce. You can set a subdomain policy (sp=none) or use pct= to limit enforcement while you figure it out. But this is a short-term workaround, not a real fix.

Option 2: Ask about subdomain delegation. Even if they don't support custom DKIM on your apex, they might let you point a subdomain's MX to their servers and handle authentication there.

Option 3: Switch vendors. Look, if a SaaS tool that sends email can't authenticate properly in 2026, that's a red flag about their overall infrastructure. The big players all figured this out years ago. Maybe it's time to evaluate alternatives. (We've got a guide on SMTP vs API for transactional email if that's the context.)

I know switching vendors is annoying. Nobody wants to hear "just migrate to a different tool." But email deliverability affects everything downstream. If your helpdesk replies go to spam, you've got a customer support problem masquerading as a vendor problem.

After the Fix: Ongoing Monitoring

This part is easy to skip. Don't.

DKIM keys can rotate. Vendors update their infrastructure. Certificates expire. The fix you ship today might break in six months if you're not watching.

Keep DMARC reporting on (rua=mailto: in your DMARC record). Run a monthly check — either manually with "Show original" on test emails, or through a monitoring tool. When a vendor rotates keys or changes selectors, you'll see DKIM failures in your aggregate reports before customers start complaining.

If you're running multiple domains across multiple products — like we do at Velocity Digital Labs with JustAnalytics, JustBrowser, and ClickzProtect — centralize your DMARC reporting into one parser. (If you're migrating off Google Workspace entirely, our Google Workspace migration runbook covers DKIM rotation as part of the cutover.) Checking seven inboxes for XML attachments isn't sustainable.

Frequently Asked Questions

Why does my third-party sender show DKIM 'none' when SPF passes?

SPF and DKIM authenticate different things. SPF checks the Return-Path (envelope sender), which is often the vendor's domain, not yours. DKIM signs the message headers with a cryptographic key. If the vendor hasn't configured custom DKIM signing with your domain, the message either has no DKIM signature at all (DKIM 'none') or is signed with the vendor's domain (DKIM passes but fails DMARC alignment). For DMARC to pass via DKIM, the d= domain in the signature must match — or be a subdomain of — your visible From address.

How do I find which DKIM selector a vendor uses?

Check the vendor's documentation or domain authentication settings page. Common selectors include s1, s2, k1, selector1, selector2, or the vendor name itself (hubspot, zendesk, freshdesk). Once you find it, you can verify by querying DNS: dig TXT selector._domainkey.yourdomain.com. If there's no record returned after you've added the CNAME they gave you, DNS hasn't propagated yet or you added it to the wrong host.

Should I use a subdomain for third-party senders instead of my main domain?

Subdomain delegation is a solid pattern when: (1) the vendor doesn't support custom DKIM, (2) you want to isolate reputation — a vendor sending spammy email won't tank your main domain's reputation, or (3) you have multiple vendors and don't want to manage a dozen DKIM records on your apex. The trade-off is the From address shows support@mail.yourdomain.com instead of support@yourdomain.com, which some people find less clean. If the vendor supports custom DKIM, use it on your main domain first. Reserve subdomains for vendors that can't or won't support proper authentication.

What if my vendor says they don't support custom DKIM?

Ask if they support subdomain delegation — you point a subdomain's MX and authentication to them, and they manage everything on that subdomain. If they don't support that either, you have two options: (1) accept that email from this vendor will fail DMARC alignment and rely on SPF alone, which is fragile at p=reject, or (2) switch vendors. In 2026, any email-sending SaaS that doesn't offer custom DKIM or subdomain delegation is either very small or very behind. The big players — HubSpot, Zendesk, Intercom, SendGrid, Mailgun, Freshdesk, Stripe — all support it.

Try JustEmails

Custom domain email hosting for $49/year — unlimited domains, unlimited email accounts, 10 GB storage, full IMAP/SMTP. Auto SPF/DKIM/DMARC setup so you're not debugging authentication issues from day one.

Start your 7-day free trial → · How it compares

DKIM Shows 'none' or Unsigned? Fixing Authentication for Third-Party Senders