SPF passes. DKIM resolves. DMARC has a policy published. Every online checker gives your domain a clean bill of health. And yet clients keep telling you their emails are landing in spam, or getting quarantined by Google Workspace and Exchange on the receiving end.

This is usually why: the domain routes outbound mail through more than one third-party service (an email signature tool like Exclaimer, an outbound security gateway like Hornetsecurity, marketing platforms such as HubSpot or Klaviyo, a CRM like Salesforce), and deliverability breaks somewhere in that chain, in ways the standard DNS checks won’t show you.

Here’s how I audit mail flow when the DNS records all check out but recipient servers still disagree with them.

What to check first

Before digging into the mail flow itself, rule out the baseline authentication requirements:

  • SPF record syntax and limits. Stay strictly under the 10 DNS lookup limit, and end the record with ~all or -all.
  • DMARC policy. Confirm _dmarc.yourdomain.com has a published policy (p=quarantine or p=reject, not just p=none).
  • Core DKIM selectors. Confirm your primary mail provider’s selectors (Microsoft 365’s selector1/selector2, or Google’s google) resolve to valid public keys.

If all three pass, the problem is almost certainly a header modification or alignment failure introduced by one of the services sitting between you and the recipient.

Where multi-service mail flows actually break

1. Exclaimer server-side signatures and DKIM

Exclaimer doesn’t sign or re-sign mail itself, and it doesn’t apply ARC seals. When a server-side signature modifies the message body, that invalidates any DKIM signature already on the message, so Exclaimer strips it before handing the message back to Microsoft 365 or Google Workspace. Your primary platform then applies a fresh DKIM signature to the modified message on its way out. That’s expected behaviour, confirmed in Exclaimer’s own documentation, and it normally needs no extra configuration on your end.

Where it actually goes wrong is mail flow, not a setting you forgot to tick:

  • Routing bypasses the signing step. If a connector sends the message out through a path that skips the platform’s normal outbound signing (rather than returning it to M365 or Google Workspace for the final leg), it leaves unsigned.
  • A gateway sits after the fresh signature. If mail is routed to a third-party security gateway (Hornetsecurity, Mimecast, Proofpoint) after M365 or Google Workspace has re-signed it, any further body or header change the gateway makes will break that signature too.

2. Missing DKIM selectors on outbound gateways (Hornetsecurity)

If you use an outbound security filter like Hornetsecurity at the tail end of your mail flow, it scans, may add disclaimers, and can modify headers, all of which invalidate the DKIM signature applied earlier by Microsoft 365 or Google Workspace. To stay valid, the gateway has to re-sign the message using its own DKIM keys, not the ones your primary platform used.

Hornetsecurity handles this by asking you to delegate two selectors to them by CNAME:

hse1._domainkey.yourdomain.com  CNAME  hse1._domainkey.hornetsecurity.com
hse2._domainkey.yourdomain.com  CNAME  hse2._domainkey.hornetsecurity.com

If you’ve added Hornetsecurity to your SPF record (include:spf.hornetsecurity.com) but haven’t published those two CNAMEs, the gateway can’t sign on your domain’s behalf. Recipient servers see a modified message with an invalid or missing signature, and DMARC fails.

The fix: every gateway handling outbound mail needs its DKIM selector CNAMEs published in your DNS and activated in its portal, not just added to SPF.

3. DMARC alignment versus a plain pass

The confusion I see most often is treating SPF/DKIM passing as the same thing as SPF/DKIM alignment.

  • Pass means the sending IP is authorised by the domain in the Return-Path, or the DKIM signature is cryptographically valid for some domain.
  • Alignment means that domain (the Return-Path for SPF, the d= tag for DKIM) actually matches the domain in the message’s From: header.

DMARC needs a pass and alignment on at least one of SPF or DKIM. If a marketing tool (HubSpot, Salesforce) sends using your From: address but relies on its own default return path or an unaligned DKIM key, DMARC fails the moment you set p=reject, even though SPF or DKIM technically passed on their own terms.

4. Stray and malformed DNS TXT records

A common setup mistake: pasting a vendor’s include domain directly into DNS as its own standalone TXT record (24946813.spf07.hubspotemail.net as a record in its own right, instead of appending include:24946813.spf07.hubspotemail.net to the existing v=spf1 record).

Compliant SPF resolvers ignore TXT records that don’t start with v=spf1, so this won’t break SPF outright. But it leaves orphaned records sitting in your zone that look like syntax anomalies to stricter security appliances and spam filters, and that’s the kind of thing that quietly drags down sender reputation over time.

Step-by-step audit checklist

  1. Map the exact outbound hop order. Client → Microsoft 365 / Google Workspace → Exclaimer connector → Microsoft 365 / Google Workspace (signing) → outbound security gateway (Hornetsecurity) → recipient.
  2. Inspect the raw headers of a quarantined message. Look at Authentication-Results for dkim=fail (body hash did not verify) or dmarc=fail.
  3. Verify gateway-specific DKIM selectors. nslookup -type=cname hse1._domainkey.yourdomain.com should resolve to the gateway’s DKIM host.
  4. Clean up DNS. Remove orphan TXT strings and make sure there’s exactly one v=spf1 record per domain.
  5. Check your own inbound gateway settings. If internal mail is being quarantined within your own tenant, make sure your inbound filter’s IPs are listed under Inbound Gateway settings, so SPF checks evaluate the original sender rather than the relay.

← back to blog index