Can an email have multiple DKIM signatures?

What are the requirements?

Each DKIM signature is evaluated on its own merits

RFC 6376 states that a message can contain signatures from the same or different organizations and that verifiers SHOULD evaluate signatures independently. Each signature refers to its own signing domain through d=, DNS selector through s=, signing algorithm, body hash, and header list.

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=selector1;
 h=from:to:subject:date; bh=example-body-hash; b=example-signature
DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.net; s=provider1;
 h=from:to:subject:date; bh=example-body-hash; b=example-signature

The values above are illustrative only. Do not publish another organization's selector, DNS target, token, or signature value as your configuration.

A verifier retrieves the public key associated with each s= and d= pair, then evaluates that signature's signed headers and body hash. One signature can fail because a later system changed a signed part of the message while another signature still passes.

A passing DKIM signature must align to satisfy the DKIM side of DMARC

RFC 9989 is the current DMARC Proposed Standard and obsoletes RFC 7489. For DKIM evaluation, DMARC compares a passing DKIM authenticated identifier with the RFC 5322 From Author Domain using the domain-alignment rules in the DMARC policy.

This means a message can have several DKIM results with different DMARC value. For example:

• A signature with d=yourdomain.com can satisfy the DKIM side of DMARC when it passes and aligns with From: alerts@yourdomain.com.
• A signature with d=mail.example.net can pass DKIM but may not align with yourdomain.com.
• A failed aligned signature does not become valid because an unrelated signature passes.

The signature should survive the message path that matters

DKIM verification checks the message as received, not the message as it looked when the first sender submitted it. A later system that changes a signed header, message body, footer, or link can cause one signature to fail.

An extra signature is therefore not automatically a fault. The operational question is whether the intended signature remains valid at the recipient and, when DKIM supports DMARC, whether that signature aligns with the visible From domain.

For a wider security consideration, see DKIM replay attacks: what they are and what controls help. A valid DKIM signature proves that the signed content validated against the published key. It does not, by itself, establish that a later use of a message is authorized.

When does the requirement take effect?

There is no new mailbox-provider deadline for multiple DKIM signatures. The behavior is defined by RFC 6376 and applies whenever a message contains more than one DKIM-Signature field.

RFC 6376 was published as a Standards Track RFC in September 2011. Its rule that verifiers SHOULD evaluate multiple signatures independently is protocol behavior, not a temporary migration rule. RFC 9989 was published in May 2026 as a Proposed Standard and superseded RFC 7489 for DMARC. It defines the current DMARC interpretation of aligned DKIM identifiers.

A provider can make local filtering decisions beyond the protocol minimum. A DKIM pass in a header does not disclose every factor a receiver uses to accept, filter, or place a message.

How do I implement the requirement?

1. Identify the signature that should align with the visible From domain

Choose the system that can sign the final production message using the domain shown in the recipient-facing From header. This can be the sending platform or a final outbound gateway, depending on where intentional message changes occur.

Record the expected d= domain and selector for each production sending path. Do not assume that a platform's generic DKIM status means the delivered message carries an aligned signature.

2. Give independent signing systems separate selectors

Publish a distinct selector and key for each service or signing role. Separate selectors make it possible to identify which system signed a delivered message and to rotate or retire a key without affecting unrelated senders.

The public-key record has this general shape:

selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=example-public-key"

This is illustrative only. Generate the actual selector and key in the sending service that owns the private key. Do not reuse another tenant's record value.

3. Place the required signature after planned message modifications

If an outbound gateway adds a footer, rewrites links, or changes covered headers, the aligned signature that must survive delivery should be applied after those deliberate changes. A message can retain earlier signatures, but an earlier signature may fail if its signed content changes later.

Do not remove an existing DKIM signature solely because another one appears. First verify the delivered production message and confirm which signature supplies aligned DMARC authentication.

4. Retire transition signatures after production evidence is available

During a signing migration, keep the old public key available while mail signed with it can still be delivered or verified. Stop adding the old signature only after the new signature appears on the actual sending path and passes verification.

A DNS record can be correctly published while the application still signs with an old selector. Treat DNS publication and delivered-message behavior as separate checks.

How do I validate compliance?

Start with a message delivered through the exact production path. Open its raw source and list every DKIM-Signature field. For each signature, record the d= domain and s= selector, then compare it with the corresponding dkim= result in the message's Authentication-Results field.

Check four layers separately:

• DNS: confirm the expected selector record resolves through the authoritative DNS service and a public resolver.
• Vendor: inspect the sending service's current DKIM or domain-authentication status.
• Message: verify that the delivered message contains the intended signature and that it passes.
• DMARC: once aggregate reports accumulate, confirm that the aligned domain is appearing as expected in DMARC reporting.

For message-level testing, follow the process in How do you test and verify DKIM on a real email?. Compare the delivered message's d= value with the visible From domain and evaluate whether the domains align under the DMARC policy.

Check the DKIM selector behind the delivered signature

After you have identified the d= domain and s= selector in a delivered message, inspect that selector's public DNS record before changing a signing configuration.

Check the DKIM selector

A selector check can show the published public key. It cannot prove that the production sender used the key, repair a broken signature, monitor later message changes, or guarantee a receiver's placement decision.

If several systems sign your domains, the ongoing gap is broader than one selector lookup. Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step after a human reviews the evidence and applies the change.

Start with Palisade

Palisade does not autonomously change your DMARC policy, prove every future message will authenticate, or control a receiver's private delivery decision.