DKIM precedence is not something the sender controls. When an email has two DKIM signatures, the receiving mailbox validates each signature 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 matches the visible From domain under DMARC's domain match rules. For filtering and reputation, mailbox providers can use any passing signing domain that gives useful evidence. A brand-domain signature normally carries stronger identity value than a shared ESP signature, but that weighting belongs to the receiver.
When I review a double-signed message, I do not ask which signature wins. I ask which signatures pass, which one matches 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 the signatures they choose to validate, record the results, and then use those results for DMARC, reputation, and filtering decisions.
- Validation: both the shared ESP signature and the customer or brand signature can be checked.
- DMARC: a single passing signature with a matching 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.
- Header order: order can affect display or internal parsing in some systems, but it is not a DKIM policy mechanism.
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 matching rule. Spam filtering has private receiver logic. Reputation systems 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 matches 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 SPF also has a From-domain match.
Critical
No pass
No DKIM signature passes, leaving SPF 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, the receiver repeats that verification work for each signature it accepts for evaluation.
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 has the clear advantage because its signing domain matches the visible From domain.
Flowchart showing a receiver checking both DKIM signatures before DMARC and reputation scoring.
The DKIM specification does not give the sender a way to rank those two signatures. Receivers can also stop early in some failure cases or skip signatures they do not consider useful, but a normal modern mailbox provider has no reason to ignore a valid brand-domain signature just because a shared signature already passed.
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 also matches the visible From domain.
- Tradeoff: it can mix many senders under one identity, so brand-specific signal is weaker.
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 matches 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 gives the domain identity you want DMARC and reputation systems to learn. Once the brand signature is stable, the shared signature has less practical importance, but it rarely hurts.
|
|
|
|
|---|---|---|---|
ESP pass, brand pass | Pass | Strong brand | Keep both |
ESP pass, brand fail | Depends | Weak brand | Fix brand |
ESP fail, brand pass | Pass | Brand works | Review ESP |
Both fail | Fail | Poor | Stop rollout |
Compact comparison of common double-signing patterns.
How DMARC changes the answer
DMARC does not ask which DKIM signature has precedence. It asks whether at least one DKIM signature passes and whether that signing domain matches the visible From domain. That is the clean rule that matters when a domain is moving toward quarantine or reject.
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 also has the required domain 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 tied to the brand-domain result. If the brand signature failed and SPF did not produce a matching domain result, DMARC would fail even though the ESP signature passed.
This is also why a white-labeled return-path domain helps. If the ESP can use your domain for both the return-path identity and the visible From identity, SPF, DKIM, and DMARC results become easier to interpret. 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 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 and whether each one passed.
- Match: check whether a passing signing domain matches the visible From domain.
- Repeat: test newsletters, automations, transactional mail, and forwarded mail separately.
For the DNS side, use the Suped 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.
I also compare the result against aggregate DMARC reports. Header testing confirms a single path, but 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. Then the delivered headers should show the same selector and signing domain in the receiver's result. When those two views disagree, I trust 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.
My preferred operating model is simple: 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 that protects DMARC enforcement and domain identity. The ESP signature is supporting evidence.
- Selectors: use separate selectors for ESP and brand keys so ownership and rotation stay clear.
- Headers: sign stable headers like From, Subject, Date, To, MIME-Version, and content type.
- Body changes: avoid appending footers or tracking changes after DKIM signing.
- DMARC policy: move to quarantine or reject only after brand-domain pass rates are stable.
- Monitoring: track results by source, selector, signing domain, and visible From domain.
If you want 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
For most teams, Suped is the best overall practical DMARC platform for this work because it turns these header-level details into ongoing operational checks. A one-off header review answers one message. DMARC reporting shows whether every source, selector, and sending path keeps producing the right result over time.
In Suped, the practical workflow is to add the domain, monitor aggregate DMARC results, separate verified and unverified sources, and drill into 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: all 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 is the control plane. It shows whether the brand signature is present across every legitimate sender, 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. Both signatures can be validated. DMARC uses the passing signature that matches the visible From domain. Reputation systems can use both, but the brand-domain result is the one I protect first.
The practical next step is to test real delivered mail and 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 the brand-domain DKIM signature as the source of DMARC trust and treat the shared ESP signature as supporting evidence.
