How is DKIM precedence determined when double signing emails?
Updated on 11 Aug 2026: We updated this guide for RFC 9989 and clarified how receiver limits and DMARC alignment affect double-signed email.
DKIM precedence is not something the sender controls. When an email has two DKIM signatures, the receiving system evaluates each signature it chooses to process independently. There is no DKIM tag that says "use this signature first" or "ignore the other one". If both signatures verify, both can appear as passed in Authentication-Results.
The practical answer is this: for DMARC, the signature that matters is any passing DKIM signature whose d= domain aligns with the visible From domain under DMARC's domain matching rules. For filtering and reputation, mailbox providers can use any passing signing domain that gives useful evidence. A brand-domain signature supplies a domain-specific identity, while the weight assigned to each result belongs to the receiver.
When reviewing a double-signed message, ask which signatures pass, which one aligns with the visible From domain, and whether the brand signature stays intact after every system that touches the message.
The short answer
No DKIM precedence flag exists
A sender cannot declare DKIM precedence inside the message. Receivers validate signatures according to local policy, record the results they produce, and then use those results for authentication and filtering decisions.
- Validation: the shared ESP signature and the customer or brand signature are independent checks.
- DMARC: a single passing signature aligned with the visible From domain is enough for the DKIM side of DMARC.
- Reputation: receivers decide how much value to give each signing domain, and that scoring is receiver-specific.
- Processing order: RFC 6376 permits any order, and a verifier can stop after a successful result or cap its work for resource protection.
This is why "precedence" can feel confusing. DKIM verification has a clear cryptographic result, but the business meaning of that result depends on the receiver's next step. DMARC has a published alignment rule. Spam filtering has private receiver logic. Reputation systems can combine domain identity, IP behavior, complaint patterns, engagement, volume, and history.
A common ESP setup adds two signatures: one with the ESP's shared or platform domain, and one with the sender's brand domain. The shared signature proves the ESP handled the mail. The brand signature proves the sender's domain authorized the message. Those are different identity signals, not two versions of the same vote.
What matters most
Receiver logic varies, but these signals show the practical value of each DKIM outcome.
Best
Brand match
The brand-domain DKIM signature passes and aligns with the visible From domain.
Useful
ESP pass
The shared ESP signature passes and proves the platform handled the message.
Warning
Brand fail
Only the ESP signature passes, so DMARC fails unless DKIM alignment exists or SPF passes with alignment.
Critical
No pass
No DKIM signature passes, leaving an aligned SPF result and receiver trust signals to carry the message.
What receivers check
A DKIM signature tells the receiver which domain signed the message, which selector points to the public key, which headers were signed, and what body hash should verify. With double signing, each signature selected for evaluation gets its own syntax, key retrieval, body hash, and header signature checks.
Example double-signed headerstext
DKIM-Signature: v=1; a=rsa-sha256; d=esp.example; s=network; h=from:to:subject:date; bh=...; b=... DKIM-Signature: v=1; a=rsa-sha256; d=brand.example; s=brand; h=from:to:subject:date; bh=...; b=... From: Brand <news@brand.example>
In that example, the first signature uses esp.example. The second signature uses brand.example. If both verify, the receiver has two valid DKIM identities. For DMARC, the second one qualifies because its signing domain aligns with the visible From domain.
Flowchart showing a receiver checking both DKIM signatures before DMARC and reputation scoring.
The DKIM specification does not let the sender rank signatures. RFC 6376 says verifiers should evaluate signatures independently and can process them in any order. A verifier can stop after one signature succeeds, continue checking others, or limit attempts to control resource use. Double signing therefore creates multiple available identities, not a guarantee that every receiver will report every signature.
Shared and brand signatures
The main difference is ownership. A shared signature belongs to the sending platform or network. A brand signature belongs to the domain that the recipient sees in the From header. Both can be valid, but they answer different questions.
Shared ESP signature
- Owner: the ESP or sending network controls the signing domain and selector.
- Purpose: it proves the platform handled the message and did not change signed content later.
- DMARC value: it helps DMARC only when the signing domain aligns with the visible From domain.
- Tradeoff: it can mix many senders under one identity, so the signal is not specific to the brand domain.
Brand signature
- Owner: the sender's domain controls the DNS key and the identity attached to the mail.
- Purpose: it proves the visible sender domain authorized the message.
- DMARC value: it satisfies the DKIM side of DMARC when it passes and aligns with the From domain.
- Tradeoff: it requires correct DNS, selector rotation, and signing coverage across every stream.
If an ESP offers both, keep both during migration. The shared signature gives continuity for platform handling. The brand signature supplies the domain identity needed for DKIM alignment with DMARC. Once the brand signature is stable, the shared signature remains a separate platform identity, but it does not replace the aligned brand result.
|
|
|
|
|---|---|---|---|
ESP pass, brand pass | Pass | Brand present | Keep both |
ESP pass, brand fail | Depends on alignment and SPF | Brand failure | Fix brand |
ESP fail, brand pass | Pass when brand aligns | Brand works | Review ESP |
Both fail | Depends on aligned SPF | No DKIM identity | Stop rollout |
Compact comparison of common double-signing patterns.
How DMARC changes the answer
DMARC does not ask which DKIM signature has precedence. Under RFC 9989, it checks whether one or more authenticated identifiers have alignment with the Author Domain in the visible From header. Any DKIM signature that passes and has alignment can satisfy the DKIM side of DMARC.
For a message from news@brand.example, a passing signature from brand.example satisfies the DKIM side of DMARC. A passing signature from esp.example does not, unless it has the required alignment relationship with the visible From domain.
Example receiver resulttext
Authentication-Results: mx.receiver.test; dkim=pass header.d=esp.example header.s=network; dkim=pass header.d=brand.example header.s=brand; dmarc=pass header.from=brand.example
That result shows two DKIM passes, but the DMARC pass is supported by the aligned brand-domain result. If the brand signature failed and SPF did not pass with an aligned MAIL FROM domain, DMARC would fail even though the unaligned ESP signature passed.
A branded return-path domain helps the SPF side of DMARC because the MAIL FROM domain can match the visible From domain. It does not change DKIM signature order, and it does not make an unaligned ESP signature count for DKIM alignment. For broader domain checks, a domain health check can catch missing DNS records, bad SPF includes, and DKIM selector issues before the rollout reaches real recipients.
Infographic showing brand DKIM satisfying DMARC while ESP DKIM remains extra evidence.
How strict and relaxed DKIM alignment work
A valid signature counts for DMARC only after its d= domain passes the alignment test set by the domain's adkim policy. The default is relaxed alignment. A published adkim=s setting requires strict alignment.
|
|
|
|
|---|---|---|---|
Relaxed | mail.brand.example | brand.example | Aligned when both share the same Organizational Domain |
Strict | mail.brand.example | brand.example | Not aligned |
Strict | brand.example | brand.example | Aligned |
Either | esp.example | brand.example | Not aligned |
How DKIM alignment changes which signature can support DMARC.
How to verify which signature matters
The fastest way to answer this for a real sender is to inspect a delivered message, not the ESP settings screen. Send a live message to a mailbox you control, view the full headers, and read the Authentication-Results lines added by the receiver.
- Send: use the same campaign path, envelope domain, and From domain that production mail uses.
- Open: inspect full headers rather than the simplified authentication panel.
- Compare: note every DKIM header.d value reported and whether each one passed.
- Alignment: check each passing signing domain against the visible From domain under the published DMARC alignment mode.
- Repeat: test newsletters, automations, transactional mail, and forwarded mail separately.
For the DNS side, use Suped's DKIM checker to confirm that the selector resolves, the public key parses, and the record is valid. That does not prove a specific outbound platform signed the email, so combine DNS validation with a real delivered-message test.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
If the brand signature is missing, the issue is usually in the sending platform setup, not DNS. If the signature exists but fails, look for modified signed headers, body changes after signing, stale public keys, selector typos, or line wrapping problems introduced by a downstream system.
Compare the result against aggregate DMARC reports as well. Header testing confirms a single path, while reports show whether the same source behaves consistently across real production volume.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
A clean test should show the selector, the public key, and the validation checks clearly. The delivered headers should then show the same selector and signing domain in the receiver's result. When those two views disagree, use the delivered headers for message behavior and the DNS checker for record health.
Operational rules for double signing
Double signing is useful when it reduces risk during migration, gives the ESP its platform identity, and gives the brand its own domain identity. It becomes confusing when teams treat the shared ESP signature as a replacement for the brand signature.
Do not rely on header order
Some senders place the network signature first and the brand signature second because that matches the way their ESP signs the message. That order can be reasonable for consistency, but it is not a precedence instruction to the receiver.
Keep the brand-domain signature valid on every stream, keep the ESP signature if the platform adds it cleanly, and measure results by signing domain. The brand signature is the one to protect for DMARC enforcement and domain identity. The ESP signature is supporting evidence when it passes.
- Selectors: use separate selectors for ESP and brand keys so ownership and rotation stay clear.
- Headers: always sign From as DKIM requires, then sign other headers that will remain stable after signing, such as Subject, Date, To, MIME-Version, and Content-Type.
- Body changes: avoid appending footers or making tracking changes after DKIM signing.
- DMARC policy: move to quarantine or reject only after aligned brand-domain pass rates are stable.
- Monitoring: track results by source, selector, signing domain, and visible From domain.
For more background on why platforms add two signatures, the guide on double DKIM signing explains the main use cases. The guide on multiple DKIM signatures covers how to read the results when more than one signature appears.
Where Suped fits
Suped's DMARC monitoring turns these header-level details into ongoing operational checks. A one-off header review answers one message. DMARC reporting shows whether each source and sending path keeps producing the expected aligned result over time.
In Suped, the practical workflow is to add the domain, monitor aggregate DMARC results, separate verified and unverified sources, and investigate failures that affect DKIM, SPF, or DMARC. Suped also supports hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, blocklist (blacklist) monitoring, and MSP multi-tenancy for teams managing many domains.
Manual review
- Scope: one message at a time, usually after someone notices a problem.
- Evidence: raw headers, DNS lookups, and manual comparison across sources.
- Risk: quiet DKIM failures can persist until a campaign or policy change exposes them.
Suped workflow
- Scope: monitored mail streams, sources, and authentication results.
- Evidence: source breakdowns, issue detection, fix steps, and policy staging.
- Risk: alerts surface DKIM and DMARC drops before enforcement creates user-visible loss.
For teams moving from a shared ESP signature to a brand-domain signature, DMARC monitoring provides the ongoing control point. It shows whether the brand signature is present across legitimate senders, whether SPF still covers the return-path identity, and whether policy changes are safe.
Views from the trenches
Best practices
Keep the brand signature valid and tied to the visible From domain before enforcing DMARC.
Use a shared ESP signature as extra evidence, not the primary identity for your domain.
Check Authentication-Results after sending, because inbox views often hide useful details.
Document selector ownership so key rotation does not break one signature silently during launches.
Common pitfalls
Treating header order as policy creates false certainty and weak troubleshooting habits.
Assuming one passing DKIM signature means DMARC passes when the domain does not match.
Letting an ESP-only signature carry identity can slow brand reputation learning over time.
Removing the shared signature without checking downstream mailing and forwarding paths.
Expert tips
Track pass rates by signing domain so brand and network keys have separate health signals.
Rotate selectors on a planned schedule and keep old public keys live through the tail.
Prefer relaxed DMARC matching during rollout, then tighten only after clean evidence.
Use alerts for sudden DKIM drops because broken signing can spread across campaigns.
Marketer from Email Geeks says receivers validate both the shared network key and the brand key when both signatures appear on the same message.
2020-04-28 - Email Geeks
Expert from Email Geeks says there is no DKIM standard setting that lets a sender choose evaluation order for multiple signatures.
2020-04-29 - Email Geeks
What to do next
DKIM precedence in double-signed email comes down to receiver evaluation, not sender preference. Multiple signatures can validate independently. DMARC uses any passing signature that aligns with the visible From domain. Reputation systems can use additional results, but the aligned brand-domain result is the one to protect first.
Test real delivered mail, then monitor the pattern over time. If the ESP signature passes but the brand signature fails or disappears, fix the brand signature before raising DMARC policy. If both pass, keep the setup documented, rotate selectors carefully, and watch aggregate reports for sudden source-level changes.
Decision rule
When double signing works, keep an aligned brand-domain DKIM signature as the source of DMARC trust and treat the shared ESP signature as supporting evidence.
