DKIM Failures in Mimecast & Proofpoint: The Selector-Level Playbook

An alert fires. Your DMARC monitoring service just flagged a legitimate invoice from your AP department, now sitting in a partner's quarantine. You pull the headers and see the dreaded `dkim=fail`. This shouldn't happen. Your Secure Email Gateway is supposed to be signing every outbound message.

This is a scenario we see constantly. Companies invest in powerful SEGs like Mimecast or Proofpoint, configure them to sign outbound mail, and assume DKIM is handled. But the SEG itself introduces a separate, complex point of failure for email authentication, distinct from your mail service provider like Google Workspace or Microsoft 365. The signature applied by your SEG is often the only one that matters for DMARC alignment, so when it breaks, everything breaks.

Fixing it requires moving beyond high-level dashboard checks and digging into the weeds of DNS selectors, signing policies, and raw email headers. This isn't a configuration problem; it's a full-blown incident. Let's treat it like one.

Why Your SEG Is Another DKIM Failure Point

When you route outbound mail through an SEG, you change the fundamental path of authentication. An email might originate from Microsoft 365, which applies its own `selector1._domainkey` signature. But then it hits the Mimecast or Proofpoint mail transfer agent (MTA). The SEG scans it for threats, potentially modifies the body or subject (like adding a `[EXTERNAL]` tag), and then—critically—applies its own, completely separate DKIM signature, defined by a selector you've configured, like `pp2024._domainkey`.

The receiving server, operating per RFC 6376, now sees two DKIM signatures. Because the SEG likely altered the email body, the original Microsoft 365 signature will fail its body hash verification. That's expected behavior. The receiver then falls back to the SEG's signature. If that second signature is valid and aligns with the `From` header domain, DMARC passes. If it fails, you're dead in the water.

This makes your SEG's DKIM key a single point of failure for your domain's reputation. It's no longer just about a forwarder breaking a signature on a calendar invite; this is your own authorized infrastructure causing the break. The ground truth of what's being evaluated is always in the `Authentication-Results` header of the delivered email. That's your starting point for any investigation.

Mimecast vs. Proofpoint: Two Paths to DKIM Signing

Mimecast: DNS Policies and Selector Management

Mimecast handles DKIM through its DNS Authentication policies. When you set one up for an outbound domain, Mimecast generates a private key that it keeps on its side and a public key for you to publish in DNS. You're given a choice of a TXT or CNAME record. Mimecast typically uses two selectors per definition, allowing for key rotation without downtime.

The most common failure mode in Mimecast isn't the key itself, but the policy application. The DNS Authentication definition has to be linked to a Policy. Is that policy correctly applied to your outbound sender group? Are there routing rules for, say, system-generated notifications that bypass the policy entirely? You can have a perfect DNS record and still have unsigned mail if the policy logic is wrong. You're debugging a rules engine, not just a DNS record.

Proofpoint: Organizational Keys and Granular Rules

Proofpoint's approach is conceptually similar, often managed under its Email Authentication settings. You generate an "Organizational Key" for a given domain, and Proofpoint provides the selector name and the public key TXT record to publish. Unlike Mimecast's paired selectors, Proofpoint typically generates a single key and selector at a time.

Where Proofpoint gets tricky is in the granularity of its rule-based signing. You can create a DKIM signing rule that applies only to specific envelope senders, IP ranges, or even messages matching a certain filter. This power is a double-edged sword. It's easy to create a rule that covers 95% of your mail flow but misses critical edge cases, like a legacy on-premise application relaying through Proofpoint from an unlisted IP. The result is intermittent, maddening DKIM failures that are hard to reproduce.

The Pre-Flight Check: Your Selector Validation Playbook

Before you lose hours poring over headers, start with a basic pre-flight check of the DKIM selector's DNS record itself. A malformed public key record is a common and easily fixed root cause. Use a command-line tool like `dig` or a public web-based validator.

Step 1: Confirm DNS Propagation and Record Type

First, just see if the record exists. Run `dig TXT yourselector._domainkey.yourdomain.com`. You should get a `NOERROR` status and a valid TXT record in the answer section. If you get `NXDOMAIN`, the record doesn't exist. SEGs frequently use CNAMEs to point your selector to a record they manage, like `yourselector.dkim.mimecast.net`. If you're using a CNAME, ensure the target it points to actually resolves.

Step 2: Check Key Strength and Syntax

Once you have the record, inspect the contents. The key-value pairs are separated by semicolons. The `p=` tag contains the Base64-encoded public key. Is it a 1024-bit or 2048-bit key? Anything less than 1024-bit is obsolete, and 2048-bit is the modern standard. Some strict receivers may penalize shorter keys. Also, watch out for syntax errors. Copy-pasting the record from a web UI can introduce spaces or incorrect line breaks that invalidate the record.

v=DKIM1; k=rsa; t=y; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu...[key data]...AQAB — Example DKIM TXT record with Test Mode enabled

Step 3: The Treacherous 'Test Mode' Flag (t=y)

Look for `t=y` in the record. This flag means "test mode." It's intended for initial setup to prevent signing issues from causing mail to be rejected. However, RFC 6376 explicitly states that receiving validators "SHOULD NOT treat signatures from keys with the 't=y' flag as secure." If this flag is left in a production key, many major receivers (including Google and Microsoft) will return a `dkim=temperror` or `dkim=permerror` with a note like `(key in test mode)`. You have effectively nullified your own DKIM signature.

Anatomy of a Failure: How 't=y' Undermined DMARC

Let's make this concrete with a real incident. A company with a `p=reject` DMARC policy suddenly found all their invoices, sent through Proofpoint, were being rejected by a key customer. Their DMARC reports lit up with failures. The team was convinced the customer's mail gateway was broken.

They were wrong. We pulled the raw headers from a bounced message. The `Authentication-Results` header, added by the customer's MX, told the whole story. Because the company's Proofpoint-generated DKIM key had the `t=y` flag, the customer's gateway correctly interpreted it as a temporary error. Since mail routed through Proofpoint also fails SPF alignment (the SMTP `MAIL FROM` is a Proofpoint address, not the `From` header domain), DMARC had zero aligned, passing authenticators. The `p=reject` policy did exactly what it was told to do.

Authentication-Results: mx.partner.com; dkim=temperror (key in test mode) header.s=pp2024 header.d=yourcompany.com; spf=fail (sender IP is 1.2.3.4) smtp.mailfrom=out.proofpoint.com; dmarc=fail action=reject header.from=yourcompany.com;

The fix was painfully simple. An admin had generated a new DKIM key in Proofpoint but forgotten to uncheck the "Test Mode" box before handing the DNS record to the infrastructure team. Removing the `t=y;` from the TXT record in public DNS resolved the entire incident within an hour of TTL expiration. A two-character mistake cost them a full day of failed financial communications.

Ground Truth: Matching DNS to Live Email Headers

DNS checkers are vital, but they only confirm what's publicly available. They don't prove that your SEG is actually *using* that key to sign messages. For that, you need to go to the source: the `DKIM-Signature` header itself.

Send a test email from an account routed through your SEG to an external mailbox you control (like Gmail or Outlook.com). Once it arrives, view the original message source. You're looking for the `DKIM-Signature` header block added by your gateway.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourdomain.com; s=mimecast2024q1; h=From:To:Subject:Date:Message-ID; bh=...; b=...

Pay close attention to the `d=` (domain) and `s=` (selector) tags. Does the selector in the header—`mimecast2024q1` in this example—match the one you just validated in DNS? If you expect your Proofpoint policy to sign with `pp-prod` but you see a signature from `selector1._domainkey.onmicrosoft.com`, it means the SEG signing rule didn't trigger and the original Microsoft signature was preserved (and likely failed). The chain of `Received` headers will provide the final piece of the puzzle, showing you the path the email took and which MTA added which header.

The takeaway

Secure Email Gateways don't simplify DKIM; they relocate the complexity. Your authentication integrity is no longer just a set of DNS records but a state machine of routing logic, signing policies, and key management, all layered on top of each other. A failure in one component cascades, often leading to DMARC failure and legitimate mail being blocked.

Treat your SEG's DKIM selectors like you treat your TLS certificates. Audit them proactively, not reactively. Check for weak keys, stray test flags, and mismatches between policy and reality. A dedicated analysis platform like MailSleuth.AI can automate the correlation of header artifacts and DNS states, but nothing replaces the fundamental skill of reading the headers and knowing what to look for.