Added a New CRM or Helpdesk? Verify It Signs DKIM With Your Own Domain

You connected a new CRM or helpdesk, sent a few test emails, and they reached the inbox. The vendor's setup page shows green checks for SPF and DKIM. Then your DMARC aggregate reports list that same tool as failing, or once the domain moves to p=reject, its mail starts bouncing. The usual cause is that the tool authenticates as its own domain, not yours. DMARC only counts authentication that lines up with the domain in the From header. This guide focuses on checks you can run yourself from a terminal, before the tool goes live and again after the vendor says setup is complete.

Why SPF and DKIM can pass while DMARC fails

SPF checks the envelope sender, also called the Return-Path or MAIL FROM address. This is where bounces go, and it is not the address recipients see. When a SaaS platform sends on your behalf, the envelope sender is typically a bounce address on the vendor's own domain. SPF passes, but it passes for the vendor's domain. DKIM works the same way. Every DKIM signature carries a d= tag that names the domain doing the signing. Until you set up custom DKIM, many platforms sign with d= set to their own domain. The signature is valid. It just vouches for the wrong domain. DMARC asks a stricter question. At least one of SPF or DKIM must pass, and the domain it passed for must align with the From header domain. Alignment has two modes:

Relaxed, the default, accepts the same organizational domain. A signature with d=mail.example.com aligns with From: [email protected].
Strict requires an exact match, so d=mail.example.com would not align with example.com.

For third-party senders, DKIM is usually the practical route to alignment. You rarely control the vendor's bounce infrastructure. Some vendors offer a custom return-path domain, but that depends on the vendor. DKIM with your domain in d= works regardless of where bounces go. This also explains a common point of confusion at the support desk. A customer shows a vendor dashboard that says verified and assumes the job is done. That checkmark often means the vendor can see your DNS records. It does not prove that delivered messages carry an aligned signature. Two places hold the real answer: public DNS and the headers of a message that actually arrived.

Confirm the selector record is published in public DNS

The vendor gives you one or more host names under _domainkey. The part before ._domainkey is the selector, a label that tells receivers which key to fetch. Vendors publish keys in one of two ways:

A CNAME that points to a key the vendor hosts and can rotate.
A TXT record that contains the public key directly.

Use the exact names from the vendor's instructions. The selector below is a placeholder.

BASH

# Replace crm1 and example.com with the exact selector and domain from the vendor
dig +short CNAME crm1._domainkey.example.com

# Querying TXT follows a CNAME and returns the key the receiver will actually use
dig +short TXT crm1._domainkey.example.com

# Ask a public resolver too, so a stale local cache does not mislead you
dig @1.1.1.1 +short TXT crm1._domainkey.example.com

# Check for a doubled name in case the DNS panel appended the zone a second time
dig +short TXT crm1._domainkey.example.com.example.com

For a CNAME setup, the first command returns the vendor's target host name. The TXT query then shows that target followed by the key. For a TXT setup, the TXT query returns the key directly. In both cases you should see a string that starts with v=DKIM1 and includes a p= tag with a long base64 value. Long keys are often split into several quoted chunks. That is normal, because receivers join the chunks back together. Three results deserve a closer look:

Empty output means the record is not published, has not propagated, or sits at the wrong name.
Output from the doubled-name query means the record exists at the wrong name. This happens when someone types the full host name into a panel that appends the zone automatically. The fix is to re-enter it as crm1._domainkey only.
A present but empty p= means the key is revoked. Receivers treat signatures under that selector as failing.

Also note that a name holding a CNAME cannot hold other records. If the panel refuses the CNAME, an old TXT record may already exist at that selector name.

Check the alignment mode in your DMARC record

Next, confirm how strict your DMARC policy is. A vendor that signs with a subdomain of yours works under relaxed alignment but fails under strict.

BASH

dig +short TXT _dmarc.example.com

# Illustrative output format:
# 'v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=r'

If adkim is absent, DKIM alignment is relaxed. If it reads adkim=s, the vendor's d= value must match your From domain exactly. That matters when the vendor asks you to sign as a subdomain while the tool sends from the apex domain. Choose one of two fixes: change the From address to the subdomain, or relax DKIM alignment. Make that decision on purpose. Keep subdomains in mind as well. If the tool sends from something like help.example.com, the apex policy may still apply to that subdomain through the sp= tag or inheritance. Check which policy actually covers the From domain the tool uses.

Read the signature on a message that actually arrived

DNS tells you the key exists. Only a delivered message tells you the vendor uses it. Send a test from the CRM or helpdesk to a mailbox you control. Use a real workflow, such as a ticket reply or a notification, not only the vendor's test button. Some tools route different message types through different sending setups. Save the raw source of the message. Most webmail clients offer a show original or download message option. Then pull out the parts that matter:

BASH

# message.eml is the saved raw source, headers included
grep -i '^From:' message.eml

# List the d= value of every DKIM signature; headers are folded, so look a few lines down
grep -i -A4 '^DKIM-Signature:' message.eml | grep -oE '[[:space:];]d=[^;]+'

# The receiver's own verdict on SPF, DKIM, and DMARC
grep -i -A8 '^Authentication-Results:' message.eml

These grep patterns are a quick filter, not a parser. If the output looks odd, read the headers by eye. The signal you want in Authentication-Results is dkim=pass with header.d= set to your domain or one of its subdomains, along with dmarc=pass. It is fine to see more than one DKIM signature. Many platforms keep signing with their own domain and add yours. DMARC passes as long as one aligned signature verifies. For a closer walkthrough of these fields, see Reading Authentication-Results Headers to Fix DMARC Alignment. If the only passing signature is header.d= on the vendor's domain while your selector resolves correctly in DNS, the vendor has not switched to signing with your key yet. On many platforms, signing changes only after you complete a verify or enable step in their dashboard. Records alone are not enough. Check the vendor's documentation for that step instead of waiting for DNS to fix it. SPF in the same header will probably show a pass for the vendor's bounce domain. That is expected and does not hurt when DKIM aligns. This is also why adding the vendor's include: to your SPF record seldom fixes DMARC for these tools. If the envelope sender is their domain, your SPF record is never consulted for that message. The extra include still counts toward SPF's limit of 10 DNS lookups. Only add it if the vendor's documentation says mail actually leaves with your domain as the envelope sender.

Confirm it in aggregate reports before you enforce

One good test message proves the setup can work. Aggregate reports show whether it works for everything the tool sends. After the change, watch the reports for the tool's sending IPs. The DKIM results for that source should show your domain with a pass, and the DMARC evaluation should show alignment. A mix of aligned and unaligned rows from the same vendor usually means one message type or sending pool has not switched over yet. If the domain already enforces p=quarantine or p=reject, do this before the tool goes live, not after users report missing mail. A broader pre-enforcement checklist is in What to Audit Before Switching DMARC Policy from None to Reject. The practical habit is short. Whenever a new tool starts sending as your domain, check three things. First, the selector resolves from a public resolver with a non-empty key. Second, your DMARC alignment mode fits the domain the vendor signs with. Third, a real message from the tool shows dkim=pass with your domain in header.d=. A vendor dashboard checkmark is a useful starting point, but the delivered headers are what confirm the setup.