Will OpenDKIM wildcard configuration work?
Published 13 Jun 2025
Updated 22 May 2026
10 min read
Summarize with
Yes, OpenDKIM wildcard configuration can work, but not the way many admins first write it. The safe answer is to use wildcard matching in the SigningTable with a refile dataset, keep KeyTable values valid and predictable, and restrict which mail OpenDKIM is allowed to sign. The exact line mail._domainkey.* with *:mail:/etc/opendkim/keys/mail.private is not a configuration I would ship, because the asterisk on the value side does not mean use the sender domain.
The OpenDKIM conf man page describes KeyTable as a map from a key name to the signing domain, selector, and private key. SigningTable selects which key name to use based on the From header. That split matters: wildcard selection and valid DKIM signing are separate steps.
- Short answer: wildcards work for matching when the table type supports patterns.
- Exact line: the sample KeyTable line is unsafe and likely wrong as written.
- Best pattern: use explicit KeyTable rows, then automate generation for large domain sets.
- Main risk: a broad wildcard can make OpenDKIM sign mail for domains you did not intend.
Why the exact wildcard line is fragile
The confusion starts because OpenDKIM uses the same character for different ideas in different places. In a pattern table, * can match text. In a KeyTable value, the signing domain still has to become a real domain in the DKIM signature's d= tag. A literal * is not a valid DKIM signing domain.
Risky KeyTable linetext
# /etc/opendkim/KeyTable mail._domainkey.* *:mail:/etc/opendkim/keys/mail.private
If the KeyTable is loaded as a plain file, the left side is a key name, not a wildcard rule. If it is loaded as a refile dataset, the left side can act like a pattern, but the value still needs a valid signing domain. For most production systems, I separate the two jobs: SigningTable decides which domains match, and KeyTable has concrete signing data.
The asterisk is not a domain substitute
OpenDKIM has a % substitution for some signing-domain cases. That is not the same as putting * in the KeyTable value. Treat * as a match operator only when the dataset type says it is a match operator.
- Pattern side: wildcards match input only in pattern-capable datasets.
- Value side: the signing domain and selector must resolve to real DKIM values.
- Operational side: a broad match expands your signing scope fast.
|
|
|
|---|---|---|
SigningTable refile | Yes | Use carefully |
SigningTable file | Limited | Prefer refile |
KeyTable value | No | Use real domain |
Domain setting | No | Use table |
How I treat wildcards in OpenDKIM table files.
A safer OpenDKIM layout
For a small set of domains, the clean version is boring and explicit. OpenDKIM runs in signing mode, reads a KeyTable, reads a SigningTable, and signs only mail that matches your trusted-host or authenticated-submission rules. This is the layout I use as the baseline before adding automation.
Core OpenDKIM configurationtext
# /etc/opendkim.conf Mode sv KeyTable file:/etc/opendkim/KeyTable SigningTable refile:/etc/opendkim/SigningTable InternalHosts refile:/etc/opendkim/TrustedHosts Socket local:/run/opendkim/opendkim.sock Syslog yes SyslogSuccess yes
Explicit KeyTabletext
# /etc/opendkim/KeyTable mail._domainkey.example.com example.com:mail:/etc/dkim/example.com/mail.private mail._domainkey.example.net example.net:mail:/etc/dkim/example.net/mail.private
Explicit SigningTabletext
# /etc/opendkim/SigningTable *@example.com mail._domainkey.example.com *@example.net mail._domainkey.example.net
This keeps the DKIM selector and signing domain visible. It also makes key rotation easier to reason about because every row points to one private key. If you are deciding whether a selector can be reused, read the DKIM selector uniqueness notes before standardising on one selector name.
Broad wildcard
- Scope: matches more domains than most people expect.
- DNS: requires every signed domain to publish the matching public key.
- Rotation: one shared key turns one change into a domain-wide event.
Explicit map
- Scope: each From domain maps to an intended key name.
- DNS: each selector record has one clear owner.
- Rotation: one domain can move to a new selector without touching others.
Flowchart showing how OpenDKIM moves from From header to SigningTable, KeyTable, and DKIM signature.
When a wildcard can work
A wildcard can work when the wildcard is used to select a key and the key data still produces a real DKIM signature. The simplest broad pattern is a SigningTable rule that sends every From domain to one shared key record. I only use this in tightly controlled relay setups where every domain is intentionally onboarded and every domain publishes the same public key under the same selector.
Shared-key wildcard patterntext
# /etc/opendkim.conf KeyTable file:/etc/opendkim/KeyTable SigningTable refile:/etc/opendkim/SigningTable # /etc/opendkim/SigningTable *@* shared-mail # /etc/opendkim/KeyTable shared-mail %:mail:/etc/dkim/shared/mail.private
That pattern signs with the apparent sender domain in the d= tag and the selector mail. It only works when each domain has a matching DNS record at mail._domainkey. For more than a handful of unrelated domains, I prefer generated exact rows because one compromised shared private key creates a wider rotation problem.
Acceptable wildcard use cases
- Single owner: all domains belong to the same organisation and DNS process.
- Same selector: every domain publishes the same selector and public key.
- Controlled relay: Postfix only accepts mail from authenticated or trusted senders.
- Fast rollback: you can disable the wildcard rule without blocking legitimate mail.
GNOME Terminal screenshot showing OpenDKIM configuration validation and a SigningTable file.
A useful external walkthrough of multiple domains with OpenDKIM and Postfix is this multi-domain example. The important part is the pattern, not the exact file paths: one row chooses a key name, and another row says what domain, selector, and private key that key name uses.
DNS still has to match the signature
OpenDKIM only creates the DKIM-Signature header. Receivers still verify that signature by looking up the public key at selector, _domainkey, and the signing domain. After every config change, check the published key with a DKIM checker and then send a real message to inspect the signature that was actually added.
DNS records for two domainsdns
mail._domainkey.example.com TXT v=DKIM1; k=rsa; p=BASE64KEY1 mail._domainkey.example.net TXT v=DKIM1; k=rsa; p=BASE64KEY2
If you do not want to publish raw public keys on every customer or brand domain, CNAME delegation is the cleaner operational pattern. The visible selector stays on the sending domain, but the target record can live under a domain you manage.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Do not stop at DNS validation. A published key can be correct while OpenDKIM signs with the wrong selector, skips signing because the host is not trusted, or signs with a shared key that the domain has not published. The message header is the final source of truth.
How I test before production
I test OpenDKIM wildcard changes in layers. First I make sure the daemon parses the config. Then I confirm DNS can return the public key. Finally I send real mail through the same Postfix path production mail uses, because that is where trusted-host rules, milter settings, and queue routing show up.
- Config parse: run OpenDKIM in config-check mode before restarting the service.
- Key lookup: confirm the selector and domain return the expected public key.
- Header check: inspect the generated DKIM-Signature for the expected d= and s= values.
- DMARC result: verify that the DKIM domain match passes for the visible From domain.
- Rollout data: watch aggregate reports for every domain before moving policy forward.
Useful test commandsbash
opendkim -n -x /etc/opendkim.conf opendkim-testkey -d example.com -s mail \ -k /etc/dkim/example.com/mail.private tail -f /var/log/mail.log | grep opendkim
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
Suped fits after that as the monitoring layer. Suped's DMARC monitoring shows which sources pass DKIM, which domains are sending unsigned mail, and which OpenDKIM changes created new failures. That is where wildcard mistakes become visible across real receiver reports instead of one local test message.
Rollout guardrails
Use these thresholds before keeping a broad OpenDKIM wildcard in production.
Safe
98%+ pass
Keep monitoring and rotate keys on schedule.
Investigate
95-98%
Review affected domains before expanding scope.
Stop rollout
Below 95%
Disable the wildcard or return to exact maps.
Operating at 100+ domains
At 100+ domains, config style matters more than saving lines. A wildcard looks neat, but the hard parts are onboarding, DNS ownership, key rotation, and proving that each domain still passes DKIM after a change. I would choose the operating model based on who owns DNS and how often domains change.
|
|
|
|---|---|---|
Exact files | Stable domains | Manual updates |
Generated files | Frequent changes | Needs deploy step |
Database maps | Very large sets | More moving parts |
Shared wildcard | One owner | Wide key risk |
OpenDKIM patterns for large domain sets.
For teams that manage many domains, Suped is the stronger practical choice for the monitoring and operations layer around OpenDKIM. OpenDKIM signs the mail. Suped shows whether that signing holds up across DMARC reports, SPF and DKIM checks, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, SPF flattening, and blocklist (blacklist) monitoring. Suped's domain health checks are a quick way to see whether a domain's authentication records are ready before adding it to a wildcard or generated map.
What I would automate
- Onboarding: create the domain, selector, private key path, and DNS instruction together.
- Validation: block deployment until the public key exists and parses correctly.
- Restart path: reload OpenDKIM only after files are written atomically.
- Alerting: send real-time alerts when a domain's DKIM pass rate drops.
Common failure modes
Most wildcard failures are not cryptography failures. They are selection failures. OpenDKIM signs with a different domain than the sender expected, uses a selector with no DNS record, skips signing because the client is not trusted, or signs mail that should have been left alone. The fix is to make the selection path visible.
Mistakes to avoid
- Overmatch: a broad SigningTable wildcard catches domains outside the intended set.
- Missing DNS: OpenDKIM signs, but receivers cannot find the public key.
- Shared key: one private key covers too many unrelated domains.
- Permissions: the daemon user cannot read the private key after dropping privileges.
- Wrong table: a file table is used where pattern matching was expected.
If you are using wildcards because you send for many subdomains, read the broader wildcard DKIM practices before making the same pattern apply across every branch of a domain tree. Wildcard convenience is useful only when the owner, DNS process, and security model are the same.
Views from the trenches
Best practices
Keep SigningTable broad rules below exact rules and review the first match after changes.
Generate explicit KeyTable rows for large sender sets instead of hand editing long files.
Validate every selector in DNS before routing production mail through the new rule.
Common pitfalls
Treating a KeyTable asterisk as a signing-domain substitute creates invalid signatures.
Using one shared private key across unrelated domains makes rotation unnecessarily wide.
Forgetting trusted host rules causes tests to pass locally while relay mail skips signing.
Expert tips
Use logs that show why OpenDKIM signed or verified during a controlled test window.
Keep one emergency exact-map config ready so a broad wildcard can be rolled back fast.
Watch DMARC aggregate reports per domain after changing selector or wildcard behavior.
Marketer from Email Geeks says a broad wildcard can make OpenDKIM try to sign every matching From domain that passes through the MTA.
2021-11-04 - Email Geeks
Marketer from Email Geeks says using one shared key across many domains is possible, but it is a poor fit when the domain count is high.
2021-11-04 - Email Geeks
The configuration I would ship
OpenDKIM wildcard configuration can work, but I would not ship the sample KeyTable wildcard as written. For production, I would use refile wildcard matching only in SigningTable when the scope is tightly controlled. For 100+ domains, I would generate explicit KeyTable and SigningTable rows or use a database-backed map, then monitor the result through DMARC reports.
- Use refile: put wildcard matching in SigningTable, not in the KeyTable value.
- Use real domains: make sure every DKIM signature has a real d= domain and selector.
- Use automation: let code generate maps when the domain list is large.
- Use reports: confirm the change with real DKIM and DMARC results after deployment.
