How is DKIM precedence determined when double signing emails?
Updated on 19 Oct 2026: We clarified DKIM verification order, aggregate-report priorities, and how to troubleshoot double-signed emails.
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.
DKIM verification has no fixed precedence
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 email service provider (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. Each passing signature associates the message with a signing domain whose published public key verifies it. The brand signature supports DMARC when its signing domain has alignment with the visible From domain.
DKIM outcomes and DMARC
These outcomes describe how DKIM results affect DMARC. Inbox placement also depends on the receiver's filtering.
Aligned brand signature passes
Brand match
The brand-domain DKIM signature passes and aligns with the visible From domain.
ESP signature passes
ESP pass
A passing shared ESP signature authenticates the ESP signing domain; DMARC still requires From-domain alignment.
Brand signature fails
Brand fail
An unaligned ESP pass alone cannot satisfy DMARC; a passing SPF result with alignment can still do so.
Both DKIM signatures fail
No pass
DMARC can still pass through SPF with alignment. Other filtering signals do not turn a DMARC failure into a pass.
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. The receiver retrieves each public key through a DNS TXT lookup at <selector>._domainkey.<signing-domain>, using that signature's s= and d= values.
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.
Receiver workflow for double DKIM signing, DMARC checks, 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 the signing domain. A shared signature uses the sending platform's domain. A brand signature uses the brand's domain or a subdomain. The ESP can hold the private keys for both, with the brand authorizing its key through DNS.
Shared ESP signature
- Owner: the ESP or sending network controls the signing domain and selector.
- Purpose: it associates the message with the ESP's signing domain and verifies the signed content under that signature's rules.
- 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 domain owner authorizes the key through a DNS TXT record or delegated DNS setup; the ESP often holds the private key.
- Purpose: it authenticates the brand's signing domain; DMARC checks that domain's relationship with the visible From domain.
- 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 when brand DKIM has alignment | Both signing domains authenticated | Keep both |
ESP pass, brand fail | Depends on alignment and SPF | Only the ESP domain authenticated | Fix brand |
ESP fail, brand pass | Pass when brand aligns | Only the brand domain authenticated | Review ESP |
Both fail | Depends on aligned SPF | No DKIM identity | Check SPF and restore brand DKIM |
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, because esp.example and brand.example are unrelated domains.
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 failed additional DKIM signature does not cancel a passing aligned signature. A DMARC pass does not guarantee inbox placement.
A branded return-path domain supports SPF-based DMARC authentication when SPF passes and the MAIL FROM domain has alignment with the visible From domain. It does not change DKIM signature order or DKIM alignment. Suped's domain health check checks authentication DNS configuration. Validate the specific DKIM selectors found in a delivered message separately.
DMARC alignment between the visible From domain and a passing brand DKIM signature.
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.
DMARC compares the DKIM signing domain in d= with the visible From domain. The selector in s= and the optional signing identity in i= do not replace that domain comparison.
DKIM priority in aggregate DMARC reports
Aggregate reporting has a defined priority for including DKIM results. RFC 9990, section 3.1.3, gives this order:
- Passing DKIM signatures with strict alignment to the visible From domain.
- Passing DKIM signatures with relaxed alignment to the visible From domain.
- Other passing DKIM signatures.
- DKIM signatures that do not pass.
RFC 9990 recommends no more than 100 signature results per report row, in decreasing priority. This priority governs report inclusion. It does not set DKIM verification order or make strict alignment mandatory for DMARC. Reports describe the signatures the receiver checked, so a missing result is not proof that the sender omitted that signature.
Compare the raw auth_results DKIM results with policy_evaluated.dkim, which records the DMARC DKIM outcome after alignment. An unaligned ESP signature can have a raw DKIM pass while the DMARC DKIM outcome is fail.
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. Trust only Authentication-Results fields inserted by your receiving service or another system within its documented trust boundary.
- 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 and header.s value reported and whether each signature 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 from the raw headers, check the sending platform's signing settings and whether it has approved the brand's DNS configuration. 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 DNS test should show the selector, the public key, and the validation checks clearly. When the receiver reports that signature, its signing domain and selector should match the signature in the raw headers. A missing Authentication-Results entry does not prove a signature failed. Use delivered-message verification 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 different keys under the same signing domain. Identical selector labels under different signing domains are separate DNS lookups.
- 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.
Double signing can also use the same d= domain with different s= selectors during a key transition. Publish the new public key before signing with it, allow for DNS cache expiry, and keep the old public key available until messages signed with it have cleared delivery queues. Double signing is optional during rotation. Publish one DKIM key record per selector name; multiple key records at the same name are not double signing.
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.
Monitor double signing with Suped
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 authentication failures. For double signing, identify legitimate sources losing DKIM alignment, then inspect delivered headers to investigate the signing domain and selector.
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: reported DKIM and DMARC drops identify sources to investigate; visibility depends on when receivers deliver aggregate reports.
For teams moving from a shared ESP signature to a brand-domain signature, DMARC monitoring helps track aligned authentication across reporting receivers. Use those trends alongside delivered-message tests to assess readiness for DMARC enforcement; aggregate reports cannot prove that every message contains the brand signature.
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.
Relying on an unaligned ESP pass when brand DKIM fails can leave mail without a DMARC pass.
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 retain old public keys until queued mail clears.
Keep relaxed alignment unless exact domain matching is required and legitimate senders pass.
Use alerts for sudden DKIM drops, allowing for the delay before aggregate reports arrive.
Expert view
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
Expert view
Expert from Email Geeks says a brand-domain signature is the priority because it can satisfy DMARC and build a domain-specific signal.
2020-04-29 - Email Geeks
Before enforcing DMARC
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
For DKIM-based DMARC authentication, protect at least one passing signature with From-domain alignment. Keep shared ESP signing as an additional identity.
Frequently asked questions
No. Header order is not a DKIM precedence rule. Receivers choose their processing order and can stop after a successful signature or limit checks for resource protection.
Yes. A message can have a passing shared ESP signature and a passing brand-domain signature. Authentication-Results can show both pass results when the receiver checks both.
DMARC can use any passing DKIM signature whose signing domain aligns with the visible From domain under the domain's strict or relaxed alignment setting.
Not by default. Keep it if it passes cleanly, but do not depend on it for DMARC unless its signing domain aligns with the visible From domain.
The signatures can use different keys or be applied at different stages. Check each selector's DNS key and whether signed headers or the body changed after brand signing, for example through a footer added before the ESP applied its own signature.
