DKIM Selector Mismatch: The 2-Minute Fix

What a DKIM selector mismatch actually is

DKIM uses public key cryptography to let a receiver verify that a message was signed by someone who controls a domain.
The receiver extracts a DKIM-Signature header, finds a d= (domain) and an s= (selector), then looks up a DNS TXT record at:

<selector>._domainkey.<domain>

When we say “DKIM selector mismatch,” we usually mean one of these:

• The message is signed with selector s=foo, but DNS only has bar._domainkey.
• The signer is configured to use selector foo, but the key published in foo._domainkey doesn’t match the private key used to sign.
• The domain in the signature d= doesn’t match the domain where you published the record (common with subdomains and “bounce” domains).
• DNS is correct, signer is correct, but your DNS visibility is wrong (split-horizon DNS, stale resolvers, caching, or broken delegation).

DKIM mismatches are not “email is down” problems. They’re worse: email still flows, just with reduced trust. That means your incident doesn’t show up as a clean outage. It shows up as “pipeline looks fine” while revenue emails land in spam.
Classic reliability problem: failure is silent until it’s expensive.

One operational detail that matters: receivers often treat DKIM as one signal among many. A mismatch might not instantly bounce mail, but it can tip borderline traffic over the edge—especially when IP reputation is mediocre or you’re sending bursts.

Joke #1: DKIM selectors are like luggage tags—lose the tag and your email still travels, just not to the destination you wanted.

Fast diagnosis playbook (first/second/third checks)

When the page comes in (“DKIM failing”), your job is to find the bottleneck fast: is this a DNS problem, a signing problem, or a domain alignment problem?
Don’t start by rotating keys. Don’t start by editing DNS in a panic. Start by reading what the mail actually says about itself.

First: confirm what selector and domain are being used right now

• Grab a fresh message from the affected stream (not last week’s sample).
• Extract d= and s= from DKIM-Signature.
• Look at Authentication-Results to see how the receiver evaluated it.

If the selector in the header is not the selector you think you configured, you’re already done: you’re debugging the wrong sender or the wrong signing path.
In large orgs, multiple signers exist (cloud gateway, MTA, ticketing system, CRM). The email you’re holding tells you which one is actually signing.

Second: query DNS for that exact selector

• Query TXT for <selector>._domainkey.<domain>.
• Query from at least two different resolvers (your corporate resolver and a public one).
• Check for NXDOMAIN vs empty answer vs truncated/broken record.

If DNS doesn’t return a DKIM key for the selector in the header, fix DNS or fix the selector used by the signer. Usually one line.

Third: validate that the public key matches the signer’s private key

• On the signing host, locate the private key file in your OpenDKIM/OpenSMTPD/Haraka/whatever setup.
• Derive the public key from the private key and compare it to what’s in DNS (or re-publish the correct one).

If DNS has a key but the signature fails verification, you likely have a key mismatch (wrong key published, wrong file deployed, wrong selector pointing to old key, or multiple signers out of sync).

Paraphrased idea (attributed): “You can’t improve what you can’t measure,” often associated with Peter Drucker. In email auth land, “measure” means “read the header and query DNS.”

The 2-minute fix (the boring truth)

Most selector mismatch incidents end the same way: someone changed a selector in one place and forgot the other place exists.
You fix it by making the selector consistent across:

1. What the signer emits (the s= in DKIM-Signature)
2. What DNS publishes (the TXT record for that selector)
3. What key file the signer uses (private key mapped to that selector)

The fastest “2-minute fix” depends on which side is wrong:

• DNS missing the selector that’s in production mail: publish the TXT record for that selector (copy from the signer’s expected public key).
• Signer using the wrong selector: update signer config to use the selector that’s already in DNS, reload the service.
• Key mismatch: publish the right public key for the selector being used, or deploy the right private key for the selector already published.

The advice I give teams: prefer changing the signer to match DNS only if you’re absolutely sure DNS is correct and current.
Otherwise, match DNS to what the signer is already using, because that’s what your receivers are currently evaluating. Changing the signer can take time to propagate through gateways, containers, or vendor systems.

Don’t forget caching. If you publish a new TXT record, receivers won’t necessarily see it immediately. Your authoritative TTL matters, and so does the receiver’s caching behavior.
But: if your record didn’t exist (NXDOMAIN) and you add it, many systems will pick it up quickly; negative caching can still bite you for a few minutes.

Facts and historical context (why this keeps happening)

1. DKIM standardized in 2007: It came from DomainKeys (Yahoo) and Identified Internet Mail (Cisco) merging into one standard. That merge is why you see both “domainkey” naming and DKIM terminology.
2. Selectors were designed for key rotation: The selector lets you publish multiple keys at once and switch signers without removing old keys immediately.
3. DNS TXT length limits shaped DKIM: TXT strings have practical size constraints, and long keys often get split into multiple quoted strings. Some tooling handles this poorly and creates “invisible” breakage.
4. Receivers commonly do relaxed canonicalization by default: DKIM supports “simple” and “relaxed” canonicalization to tolerate whitespace changes in transit. That’s why many emails still validate even after some header formatting changes.
5. DMARC (2012) made DKIM failures visible to executives: DKIM existed before DMARC, but DMARC reports and enforcement made “auth” a boardroom topic.
6. 2048-bit keys became the expected baseline: 1024-bit keys are increasingly treated as weak; some receivers penalize them. Rotations often coincide with changing key sizes, which increases the chance of selector mistakes.
7. Some providers rotate selectors automatically: Cloud email platforms may generate selectors like selector1/selector2 or vendor-specific strings. Humans then “standardize” them and break things.
8. Split-horizon DNS is a recurring villain: Internal resolvers returning different answers from external ones can make DKIM appear correct inside the company while failing on the public internet.

Three corporate mini-stories (how grown-ups break email)

Mini-story #1: The incident caused by a wrong assumption

A mid-size SaaS company migrated from an on-prem Postfix + OpenDKIM stack to a cloud email relay for outbound notifications.
The migration plan had a neat spreadsheet: “Update SPF, set up DKIM, verify DMARC.” Everyone nodded. The calendar invite said “30 minutes.”

The engineer doing DNS work assumed the selector name was arbitrary, so they chose something memorable: prod2025.
They published prod2025._domainkey.example.com with the key the relay UI displayed. Clean.

But the relay was already signing messages with s=selector1. The UI’s “DKIM settings” page showed two selectors and a toggle for rotation.
The engineer saw “prod2025” in the docs and thought they were supposed to name it themselves, so they did. They never changed the relay’s actual selector.

Result: authentication failed for all outbound mail, DMARC policy was “quarantine,” and the most important password reset emails started landing in spam. Support tickets spiked. Nobody could reproduce it internally because their test mailbox had whitelisting rules.

The fix was almost insulting: publish the TXT record for selector1 and stop inventing selector names unless you’re also changing the signer.
The postmortem had one good takeaway: when email auth fails, read the header first. Don’t trust what you meant to configure.

Mini-story #2: The “optimization” that backfired

A global company had a tidy mail gateway fleet in two regions. Someone decided to “optimize” DNS updates by lowering TTL on all DKIM records to 60 seconds.
The idea: faster key rotation, faster rollback, less risk. Sounds reasonable in a meeting.

What actually happened: their authoritative DNS provider began rate-limiting some resolver traffic and occasionally returned SERVFAIL during peak times.
It wasn’t a full outage; it was intermittent and load-dependent. The mail gateways kept signing with the same selector, but receivers sometimes couldn’t fetch the key due to transient DNS failures.

DKIM started failing sporadically at major consumer providers. Deliverability teams saw “some campaigns fine, some not,” which is the kind of uncertainty that makes everyone fight.
The SRE on-call saw no errors on the mail gateways. The DKIM signing service was healthy. The problem was downstream: key retrieval.

They reverted TTL to a sane value (hours, not seconds), fixed DNS provider settings, and stopped treating DKIM like a feature flag system.
The “optimization” increased the volume of lookups, amplified a weak link, and gave them a failure mode that was difficult to detect from inside their network.

Mini-story #3: The boring but correct practice that saved the day

A financial services org had a dull practice: every outbound mail system had a weekly canary email sent to a dedicated external mailbox at two providers.
The mailbox was watched by a script that parsed headers, recorded DKIM/SPF/DMARC results, and alarmed on changes.

A vendor rotated a DKIM selector on a Friday night as part of “routine security maintenance.”
By Saturday morning, the canary alarm fired: DKIM fail (selector not found). Nobody was on a major incident bridge because production systems were fine—only email trust was broken.

The on-call followed the playbook: read the header, see s=vendor2026, query DNS, NXDOMAIN.
Their DNS team published the new record within minutes, because they already had a change procedure and a pre-approved list of DKIM subdomains.

No customer impact worth writing a blog post about. Which is exactly the point.
They didn’t “move fast.” They moved predictably.

Practical tasks: commands, expected output, and decisions

Below are real tasks you can run during an incident. Each includes: the command, what typical output means, and what decision you make next.
Adjust hostnames, domains, and paths to your environment, but keep the logic.

Task 1: Extract selector and domain from a DKIM-Signature header

cr0x@server:~$ grep -i '^DKIM-Signature:' -m1 -n /tmp/message.eml
42:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

What it means: The live email claims d=example.com and s=selector1.

Decision: Stop debating. Your DNS lookup must target selector1._domainkey.example.com.

Task 2: Check receiver-side evaluation in Authentication-Results

cr0x@server:~$ grep -i '^Authentication-Results:' -n /tmp/message.eml | head
12:Authentication-Results: mx.google.com;
13:       dkim=fail header.i=@example.com header.s=selector1 header.b=AbCdEf;
14:       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com;
15:       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

What it means: DKIM failed for selector1; SPF passed but DMARC failed (likely alignment problem or DKIM is required by policy).

Decision: Focus on DKIM record availability and correctness first; then check DMARC alignment once DKIM passes.

Task 3: Query the DKIM TXT record with your default resolver

cr0x@server:~$ dig +short TXT selector1._domainkey.example.com

What it means: No output typically indicates NXDOMAIN or no TXT record returned (depending on dig options).

Decision: Re-run with more detail to distinguish “no record” from “DNS failure.”

Task 4: Distinguish NXDOMAIN vs SERVFAIL vs empty answer

cr0x@server:~$ dig TXT selector1._domainkey.example.com +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51234
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

What it means: NXDOMAIN: the name doesn’t exist publicly (or not from this resolver).

Decision: Publish the missing record, or fix the selector used by the signer if DNS already has a different one.

Task 5: Query authoritative DNS directly (remove “my resolver lies”)

cr0x@server:~$ dig +short NS example.com
ns1.dns-provider.net.
ns2.dns-provider.net.

cr0x@server:~$ dig +noall +answer TXT selector1._domainkey.example.com @ns1.dns-provider.net
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

What it means: Authoritative server has the record.

Decision: If receivers still fail, suspect resolver caching, propagation delays, or that the receiver is seeing a different DNS view (split-horizon, delegation issues).

Task 6: Compare answers from a public resolver (external reality check)

cr0x@server:~$ dig +noall +answer TXT selector1._domainkey.example.com @8.8.8.8
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

What it means: Public resolver sees the key. Good.

Decision: If DKIM still fails, move to key mismatch / signing path / canonicalization and header changes.

Task 7: Check if the record is broken by quoting, whitespace, or missing tags

cr0x@server:~$ dig TXT selector1._domainkey.example.com +noall +answer
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." "morekeymaterial..."

What it means: Split TXT strings are normal. Receivers concatenate them. Missing k=rsa is usually fine (defaults exist), but malformed tags or smart quotes are not.

Decision: If the record contains non-ASCII quotes, stray semicolons, or line breaks inserted by your DNS UI, fix the record formatting.

Task 8: Verify OpenDKIM is actually signing and which selector it uses

cr0x@server:~$ sudo opendkim-testkey -d example.com -s selector1 -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'selector1._domainkey.example.com'
opendkim-testkey: key OK

What it means: From this host, OpenDKIM can retrieve the public key and it parses correctly.

Decision: If remote receivers still fail, either they can’t fetch DNS or the signer isn’t actually using this key/selector for the affected mailstream.

Task 9: Identify which KeyTable/SigningTable rule applies (common mismatch source)

cr0x@server:~$ sudo grep -R --line-number -E 'SigningTable|KeyTable|Selector|Domain' /etc/opendkim.conf /etc/opendkim/*
/etc/opendkim.conf:12:KeyTable           /etc/opendkim/KeyTable
/etc/opendkim.conf:13:SigningTable       refile:/etc/opendkim/SigningTable
/etc/opendkim/KeyTable:5:selector1._domainkey.example.com example.com:selector1:/etc/opendkim/keys/example.com/selector1.private
/etc/opendkim/SigningTable:3:*@example.com selector1._domainkey.example.com

What it means: For mail from @example.com, you intend to sign with selector1 using a specific private key file.

Decision: If the header shows a different selector, your actual mail path is bypassing this signer or a different signer is adding DKIM later.

Task 10: Confirm the private key file exists and permissions are sane

cr0x@server:~$ sudo ls -l /etc/opendkim/keys/example.com/selector1.private
-r-------- 1 opendkim opendkim 1704 Jan  4 10:12 /etc/opendkim/keys/example.com/selector1.private

What it means: File exists, readable only by opendkim user/group. Good.

Decision: If permissions are wrong (world-readable or unreadable by opendkim), fix them and restart; unreadable keys can lead to unsigned mail or runtime errors.

Task 11: Derive public key from the private key (prove whether DNS matches)

cr0x@server:~$ sudo openssl rsa -in /etc/opendkim/keys/example.com/selector1.private -pubout -outform PEM | sha256sum
0d7f3b6c6c2e3a9d93d8c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5  -

What it means: You now have a stable fingerprint of the public key derived from the signing key.

Decision: Compare this to the key material you think is in DNS (next task). If it differs, you have a key mismatch, not a “selector name” problem.

Task 12: Extract the DNS public key and fingerprint it the same way

cr0x@server:~$ dig +short TXT selector1._domainkey.example.com | tr -d '"' | sed 's/.*p=//' | tr -d ' ' | base64 -d 2>/dev/null | sha256sum
0d7f3b6c6c2e3a9d93d8c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5  -

What it means: If the hash matches Task 11, DNS and private key match. If it doesn’t, you’re publishing the wrong key for that selector.

Decision: Publish the correct key or deploy the correct private key. Do not “try random restarts” until hashes match.

Task 13: Check Postfix is actually sending through the DKIM milter

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_milters|non_smtpd_milters|milter_protocol|milter_default_action'
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
milter_protocol = 6
milter_default_action = accept

What it means: Postfix is configured to use a DKIM milter on localhost port 8891.

Decision: If these are empty, or only smtpd_milters is set, some mail paths (like submissions or reinjections) might bypass signing. Fix config to cover all flows.

Task 14: Confirm the milter service is actually listening

cr0x@server:~$ sudo ss -ltnp | grep 8891
LISTEN 0      128        127.0.0.1:8891      0.0.0.0:*    users:(("opendkim",pid=2145,fd=6))

What it means: OpenDKIM is running and listening.

Decision: If nothing is listening, restart OpenDKIM and check logs. If OpenDKIM is down, you may see unsigned mail rather than selector mismatch—different symptom, different fix.

Task 15: Validate a selector exists when you’re rotating keys (list what’s published)

cr0x@server:~$ for s in selector1 selector2 prod2026; do echo "== $s =="; dig +noall +answer TXT ${s}._domainkey.example.com; done
== selector1 ==
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
== selector2 ==
== prod2026 ==

What it means: Only selector1 exists in DNS; selector2/prod2026 do not.

Decision: Don’t switch the signer to selector2/prod2026 until DNS is ready, unless you enjoy watching deliverability graphs fall off a cliff.

Joke #2: DNS propagation is the only part of the internet that still runs on “did you try waiting?” as an official troubleshooting step.

Checklists / step-by-step plan

Incident checklist (15 minutes to stable)

1. Get a fresh failing message. Not forwarded, not re-sent, not a screenshot.
2. Extract d= and s=. That’s your ground truth.
3. Query DNS for that selector and domain. Use your resolver and a public resolver.
4. If NXDOMAIN: publish the missing TXT record or revert signer to an existing selector.
5. If record exists: run opendkim-testkey (or your signer’s equivalent) from the signing host.
6. If “key OK” locally but receivers fail: suspect DNS visibility, delegation, or intermittent SERVFAIL at scale.
7. Check signing path: confirm mail is going through the expected gateway/milter.
8. Confirm DMARC alignment: once DKIM passes, verify that d= aligns with From: domain for your policy.
9. Send a canary. Verify headers on the receiving side and capture evidence for the postmortem.

Change checklist (safe selector/key rotation without drama)

1. Generate new key pair. Use a new selector name that won’t collide (e.g., s2026a).
2. Publish the new selector in DNS first. Wait for it to be visible externally.
3. Deploy the private key to all signers. Confirm permissions and config mapping (SigningTable/KeyTable).
4. Switch signing to the new selector. Reload services, verify with a canary email.
5. Keep the old selector published. For at least several days; longer if you have delayed mail flows or archiving systems.
6. Remove old selector only after verification. Don’t clean up on the same day. That’s how you create heisenbugs in compliance journaling.

Design checklist (make selector mismatch less likely)

• One owner for outbound signing. If five teams can change DKIM, nobody owns deliverability.
• Centralize DNS changes with code review. DKIM records are production config, not a helpdesk ticket.
• Canary monitoring from outside your network. Internal checks miss split-horizon DNS and external resolver behavior.
• Record the selector in your runbook. Not “DKIM is set up,” but “selector is X; rotation procedure is Y.”

Common mistakes: symptom → root cause → fix

1) Symptom: “dkim=fail (no key for signature)”

Root cause: DNS missing the TXT record for the selector in the message header, or receiver can’t resolve it.

Fix: Publish <selector>._domainkey.<domain> TXT record. Verify via authoritative and public resolvers. Check negative caching TTLs if it “still fails” briefly.

2) Symptom: “dkim=fail (bad signature)” while DNS record exists

Root cause: Public key in DNS does not match private key used to sign. Often caused by partial deployment, wrong key file path, or rotating keys on one node only.

Fix: Compare derived public key fingerprint (Tasks 11–12). Redeploy correct key everywhere or update DNS to match the deployed signing key. Then re-test with a fresh message.

3) Symptom: DKIM passes sometimes, fails sometimes

Root cause: Multiple outbound paths or multiple signers with inconsistent configs; or intermittent DNS resolution failures at receiver scale (SERVFAIL, rate limits).

Fix: Correlate failing messages to sending IPs/hosts; check which signer added DKIM. Ensure all nodes have identical selector/key config. If DNS-related, stabilize TTLs and provider reliability.

4) Symptom: SPF passes, DKIM passes, but DMARC fails

Root cause: Alignment failure: DKIM d= domain doesn’t align with visible From: domain, or SPF mailfrom domain doesn’t align.

Fix: Ensure DKIM signs with d= that matches (or is a subdomain allowed by your DMARC alignment mode) the From domain. Don’t “fix DMARC” by weakening policy unless you truly need to.

5) Symptom: Everything looks correct internally, external receivers still show selector missing

Root cause: Split-horizon DNS, broken delegation, or DNS changes only applied to internal views.

Fix: Query authoritative nameservers and a public resolver from outside the corporate network. Fix public zone records and delegation. Email authentication is judged on the public internet, not your VPN.

6) Symptom: DKIM fails after “minor” email infrastructure change

Root cause: Mail is now bypassing the DKIM signing hop (new relay route, changed submission port, new gateway, changed milter settings).

Fix: Trace message path. Confirm milters apply to all injection points (smtp and non-smtp). Validate DKIM-Signature is present and produced by the expected system.

7) Symptom: DKIM fails only for one subdomain or one business unit

Root cause: SigningTable mismatch: rules sign @example.com but not @alerts.example.com, or the signer uses d=example.com while From is subdomain and policy requires strict alignment.

Fix: Update SigningTable rules; publish keys for the correct domain; confirm alignment with DMARC mode (relaxed vs strict).

8) Symptom: Receiver says “key too short” or treats DKIM as weak

Root cause: 1024-bit key still in use or legacy configuration.

Fix: Rotate to 2048-bit keys. Publish new selector, deploy new key, switch signing, then retire old selector. Don’t try to “edit” the old key in place.

FAQ

1) What is a DKIM selector, in plain terms?

It’s the name of the key. The selector tells receivers which DNS record to fetch for the public key used to verify the signature.
One domain can have multiple selectors so you can rotate keys or have different systems sign with different keys.

2) How do I find the selector used by my system?

Don’t guess. Look at a real message and read the DKIM-Signature header: s=....
If the message doesn’t have a DKIM-Signature, you have a different problem: signing isn’t happening.

3) Why does a selector mismatch often show up as a DMARC failure?

DMARC requires either SPF or DKIM to pass and align with the From domain.
If DKIM fails due to a missing selector/key mismatch, and SPF isn’t aligned (common with third-party senders), DMARC fails.

4) Can I “just change the selector” on the signer?

Yes, but only if DNS already publishes that selector’s key and the signer has the matching private key.
Changing the signer first is the fastest way to create a global deliverability incident.

5) Why do I see two selectors like selector1 and selector2 in some platforms?

Many providers support seamless rotation by keeping two keys published and switching between them.
The platform may sign with one while the other is staged. Humans often delete “the unused one” and cause intermittent failures.

6) How long should I keep an old selector published after rotation?

Longer than you think. At least several days is common; longer if you have delayed queues, retries, forwarding systems, or compliance journaling.
DKIM verification happens at receipt time, so delayed delivery can still need the old public key.

7) What if DNS looks correct from my laptop but receivers still fail?

Check from outside your network and query authoritative nameservers directly.
Split-horizon DNS, broken delegation, and DNS provider issues show up as “it works here” until it doesn’t.

8) Does DKIM depend on the sending IP like SPF does?

Not directly. DKIM verification depends on the signature and DNS key lookup, not the sending IP.
But receivers combine signals: if your IP reputation is poor, a DKIM hiccup hurts more.

9) Is a selector mismatch the same as “bad signature”?

No. Selector mismatch often means “no key found for that selector” (record missing or wrong name).
“Bad signature” usually means the record exists but the public key doesn’t verify the signature (key mismatch or message modified).

10) Should we automate DKIM validation?

Yes. A simple external canary that captures headers and alerts on DKIM/SPF/DMARC changes will catch selector problems before customers do.
This is one of those places where boring monitoring beats heroics.

Next steps that prevent a repeat incident

DKIM selector mismatch is the kind of failure that makes smart teams look silly, because it’s rarely “hard.”
It’s usually just inconsistent configuration across DNS and signers, with enough moving parts to hide the mistake.
The fix is fast when you treat the email header as the single source of truth.

Do this next, while the pain is fresh:

1. Write down your live selectors per domain and per sending system.
2. Add an external canary that alerts on DKIM/SPF/DMARC changes.
3. Standardize rotation: publish new selector first, then deploy keys, then switch signing, then retire old keys later.
4. Stop improvising selector names unless you’re also controlling the signer configuration end-to-end.

Email authentication is not glamorous. That’s why it breaks.
Treat DKIM like production infrastructure, not a checkbox in a vendor portal, and selector mismatch becomes a two-minute fix—once, not every quarter.