The best practice is to use DNS wildcards only in narrow places, usually customer-subdomain mail routing, while keeping DKIM and DMARC records explicit, controlled, and monitored. For most domains, I avoid wildcard TXT records. I publish DKIM selectors deliberately, rotate keys on a schedule, and move DMARC policy through p=none, p=quarantine, then p=reject after real traffic has been checked.
There is one practical caveat: if you run an ESP, SaaS app, or multi-tenant mail system, a wildcard MX pattern can help create branded customer subdomains without asking every customer to edit DNS. That is different from using a wildcard DKIM or wildcard DMARC shortcut. Suped's DMARC monitoring workflow is useful here because the hard part is not writing one record. The hard part is seeing which senders pass, which fail, and which customer subdomains need fixes.
- Wildcards: Use wildcard MX records for controlled catch-all subdomain routing. Do not use wildcard TXT records as a broad authentication shortcut.
- DKIM: Use explicit selectors, private keys per signing system or tenant group, 2048-bit RSA keys unless your provider documents another choice, and planned rotation.
- DMARC: Publish at the organizational domain, send aggregate reports to a mailbox or processor, check every real sender, then raise enforcement in stages.
- Ownership: Manage DNS records through version control, review changes, and keep a named owner for every sender that appears in reports.
Where DNS wildcards fit
A DNS wildcard answers for names that do not otherwise exist under a zone. In email authentication, that sounds tempting because DKIM, DMARC, bounce domains, reply domains, and customer subdomains all create DNS work. The safe use is much narrower: route mail for predictable subdomains, while keeping authentication identity and reporting records under tight control.
Safer wildcard use
- MX routing: A wildcard MX can receive replies for customer subdomains that do not need inbound mailboxes.
- Tenant naming: A generated subdomain like customer.cust.example keeps the visible From address branded.
- Fallback handling: A default reply handler can accept messages while explicit bounce domains handle returns.
Risky wildcard use
- TXT shortcuts: Wildcard TXT records can answer lookups you did not intend, including DKIM and DMARC names.
- Shared keys: One DKIM key across unrelated tenants turns a small mistake into a wider signing risk.
- Hidden drift: Wildcard responses can hide missing records until a receiver handles the lookup differently.
A controlled customer-subdomain pattern usually has one wildcard MX, one explicit bounce domain, explicit SPF for that bounce domain, DKIM on a known authentication subdomain, and one DMARC record at the parent zone. This keeps the visible From address customer-specific without turning every TXT lookup into a wildcard answer.
Safer customer-subdomain patterndns
*.x.example. 300 IN MX 10 replies.example.net. bounce.x.example. 300 IN MX 10 bounces.example.net. bounce.x.example. 300 IN TXT "v=spf1 include:_spf.example.net -all" k1._domainkey.auth.x.example. 300 IN CNAME k1.dk.example.net. _dmarc.x.example. 300 IN TXT "v=DMARC1; p=none; rua=mailto:d@x.example"
Do not let wildcard TXT records become policy
Wildcard TXT looks clever during setup, then becomes painful during incident response. DKIM and DMARC both rely on exact DNS names. When a wildcard record answers too broadly, the record that fixes one tenant can create ambiguous behavior for another.
- Use explicit TXT: Publish DKIM and DMARC records at the exact names receivers query.
- Test negative names: Query random selectors and subdomains to confirm they do not return valid authentication records.
DKIM best practices
DKIM best practice is to sign every outbound message with a domain you control, use selectors that identify the signing system, and protect the private key as production credential material. The d= domain in the DKIM signature should share the organizational domain with the visible From domain unless you intentionally use strict DMARC settings.
DKIM key lifecycle from key creation through selector publishing, signing, monitoring, and rotation.
- Selectors: Use names that identify the mail stream and rotation period, such as s2026a or marketing01.
- Keys: Use 2048-bit RSA keys unless the signing provider has a documented constraint.
- Rotation: Run two selectors during rotation so old mail verifies while new mail uses the new key.
- Separation: Use different selectors for marketing platforms, product mail, support mail, and internal systems.
DKIM selector rotation exampledns
s2026a._domainkey.example.com. 300 IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..." ) s2026b._domainkey.example.com. 300 IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..." )
CNAME-based DKIM is fine when a sending provider manages key rotation for you. I still keep a local inventory of who owns each selector, what product sends through it, when it was created, and how to disable it. For a broader primer on the standards, the authentication standards explanation covers how SPF, DKIM, and DMARC fit together.
DMARC best practices
DMARC best practice is to start with visibility, fix legitimate senders, then enforce. A domain with p=reject and broken DKIM is not mature. A domain with p=none forever is also unfinished. The useful middle path is a measured rollout backed by aggregate reports and test messages.
DMARC rollout thresholds
A practical staging model for moving policy after legitimate mail is passing.
Observe
p=none
Start here while discovering senders and fixing known sources.
Limit risk
quarantine 25-75%
Use a percentage when the remaining failures have named owners.
Enforce
p=reject
Move here when business mail passes and exception owners are known.
Investigate
unknown sources
Stop policy movement when unknown senders carry real volume.
The minimum useful DMARC record has a policy and aggregate reporting. Add strict mode only after you understand every sender. Add subdomain policy when parked or unused subdomains need stronger protection than the parent.
DMARC policy staging examplesdns
_dmarc.ex.com. 300 IN TXT ( "v=DMARC1; p=none; rua=mailto:d@ex.com" ) _dmarc.ex.com. 300 IN TXT ( "v=DMARC1; p=quarantine; pct=25; rua=mailto:d@ex.com" ) _dmarc.ex.com. 300 IN TXT ( "v=DMARC1; p=reject; rua=mailto:d@ex.com" )
If you need to create a record, start with a DMARC record generator and then verify the published TXT record with a DMARC checker. I prefer checking both DNS syntax and real email results because a valid record does not prove that the sending systems are passing.
How the pieces work together
The useful pattern is simple: wildcard MX records handle routing, DKIM proves the message was signed by an authorized system, and DMARC decides whether the authenticated domain is close enough to the visible From domain. The wildcards article is a useful technical example of why wildcard MX can be practical while wildcard TXT deserves caution.
Flowchart showing From domain, wildcard MX routing, SPF, DKIM, DMARC, and policy action.
|
|
|
|
|---|---|---|---|
MX | Sometimes | Route replies | It handles unknown tenant names. |
TXT | Avoid | Publish exact | It prevents surprise answers. |
DKIM | Avoid | Use selectors | It supports rotation. |
DMARC | Avoid | Use parent | It gives predictable policy. |
A compact decision table for DNS wildcard use in email authentication.
For customer subdomains, I prefer a generated DNS system or delegated zone when scale allows it. Wildcard routing is acceptable as a bridge, but every bridge needs monitoring. The moment one sender starts failing, you need to know whether the problem is DNS, signing, bounce domain setup, or a policy change.
A practical rollout plan
I start with discovery, not enforcement. Pull a week or two of aggregate reports, list every source, map each source to an owner, and then fix the records that affect real traffic. Parked and unused domains can move faster because there should be no legitimate mail to preserve.
- Inventory: List every system that sends mail for the domain, including product alerts, billing, support, and marketing.
- Authenticate: Add DKIM for each sender and make sure the bounce domain has the right SPF record.
- Monitor: Review DMARC reports until the major volume is passing and every failure has an owner.
- Enforce: Move gradually through quarantine percentages, then reject once business-critical mail is clean.
- Maintain: Keep alerts, selector rotation, and new-sender review in the normal change process.
This is where Suped fits best overall for teams that want guided DMARC operations instead of raw XML. Suped brings DMARC, SPF, DKIM, Hosted SPF, Hosted DMARC, Hosted MTA-STS, blocklist (blacklist) monitoring, Real-Time Alerts, and automated issue detection into one workflow. That matters when DNS, sender ownership, and policy movement sit across different teams.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A broad domain check is useful before policy changes because SPF, DKIM, DMARC, and DNS mistakes often appear together. I still send real test messages after DNS checks because mail handlers, forwarding paths, and platform-specific signing behavior only show up in message headers.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The concrete workflow I want is simple: detect the issue, show the source, explain the fix, verify the record, and alert the right owner when a problem returns. That is much easier to run at scale than asking someone to manually inspect XML reports every week.
What I would avoid
Most bad authentication setups come from shortcuts that outlive the emergency that created them. Wildcards are one example. Shared DKIM keys are another. A DMARC record copied between domains without checking senders is another. These choices work until volume grows, a tenant leaves, or a mailbox provider changes enforcement.
Shortcuts that create long-term risk
- Wildcard DKIM: Do not publish one wildcard DKIM key and treat every selector as valid.
- Permanent none: Do not leave a sending domain at p=none after the real sources are known.
- Unknown tenants: Do not let customer-generated subdomains send without ownership, logs, and abuse controls.
- Silent changes: Do not allow vendors to add sending sources without DMARC report review.
For non-sending domains, I use a stricter pattern: SPF hard fail, no DKIM selector unless a system truly sends, and DMARC reject. That gives attackers fewer places to borrow your domain name.
The clean target state
A mature setup has explicit DNS records, visible sender ownership, working DKIM on every platform, a DMARC policy at reject, and alerts that catch drift before customers notice missing messages.
- Records: DNS is generated or reviewed through a controlled change process.
- Reports: Aggregate data is parsed into source owners, pass rates, and clear repair tasks.
- Alerts: New failures and new senders trigger review before policy has to be relaxed.
Views from the trenches
Best practices
Keep wildcard MX records separate from TXT records so authentication answers stay predictable.
Manage DNS through reviewed templates or version control when tenant records change often.
Pair every DMARC policy change with report review and real message tests before rollout.
Common pitfalls
Using one shared DKIM key across tenants makes key exposure and sender abuse harder to contain.
Copying DMARC records without sender discovery creates failures that look like inbox problems.
Letting wildcard TXT responses mask missing records makes later DNS troubleshooting slower.
Expert tips
Use explicit DKIM selectors for tenant groups, then rotate keys with overlap and clear dates.
Treat generated DNS as application code, with tests for positive and negative query names.
Move parked domains to reject quickly, then spend more time on active high-volume domains.
Expert from Email Geeks says wildcard DNS examples help teams see how customer subdomains can meet mailbox requirements without every customer editing DNS.
2023-10-18 - Email Geeks
Marketer from Email Geeks says Terraform-managed zones or generated BIND files make the pattern safer because DNS changes are reviewed and repeatable.
2023-10-18 - Email Geeks
The practical answer
The best wildcard, DKIM, and DMARC practice is restraint. Use wildcards for routing when they solve a real multi-tenant problem. Keep TXT authentication records explicit. Use DKIM selectors that match real signing systems. Treat DMARC as an operating process, not a one-time DNS paste.
For a normal business domain, the answer is even simpler: no wildcard authentication records, DKIM on every legitimate sender, DMARC reporting from day one, and staged movement to reject. For an ESP or SaaS platform, wildcard MX can help with customer subdomains, but long-term scale still needs generated records, monitoring, and clear ownership.
