What are wildcard, DKIM, and DMARC best practices?
Published 2 Aug 2025
Updated 20 Oct 2026
14 min read
Summarize with
Updated on 20 Oct 2026: We clarified wildcard DNS behavior, DMARC test mode, and the checks needed before changing email authentication records.
The best practice is to use DNS wildcards only in controlled places, usually customer-subdomain mail routing, while keeping DKIM and DMARC records explicit and monitored. For most domains, avoid wildcard TXT records for SPF, DKIM, or DMARC policy. Publish DKIM selectors deliberately, rotate keys on a documented schedule, and move DMARC policy through p=none, p=quarantine, then p=reject only after legitimate traffic and indirect mail flows have been checked.
If you run an ESP, SaaS app, or multi-tenant mail system, a wildcard MX can route replies for customer subdomains in a DNS zone you control. It does not configure authentication for a customer's separately owned domain. Suped's DMARC monitoring groups aggregate report results by sending source so teams can identify authentication failures and investigate the affected customer subdomains.
- Wildcards: Use wildcard MX records for controlled catch-all subdomain routing. Do not use wildcard TXT records as a broad authentication shortcut.
- SPF: Publish one SPF record per MAIL FROM domain, keep evaluation within 10 DNS-querying terms, and remove stale sender authorizations.
- DKIM: Use explicit selectors, separate private keys by signing system or tenant group, use 2048-bit RSA with rsa-sha256 where supported, and plan rotation.
- DMARC: Publish for each Author Domain and its Organizational Domain when they differ, collect aggregate reports, check every real sender, then choose enforcement.
- 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 synthesizes an answer for a name that does not exist, using the wildcard immediately below its closest existing ancestor. An existing name blocks that fallback even when it has no record of the requested type. A name can also exist because it has child records, an empty non-terminal. Zone delegation puts names under the delegated zone's authority. For email, use wildcards for controlled routing while keeping authentication records explicit.
Safer wildcard use
- MX routing: A wildcard MX directs replies for otherwise nonexistent customer subdomains to a shared mail handler; that handler still needs recipient validation and abuse controls.
- Tenant naming: A generated name such as customer.cust.example identifies a tenant under the platform's domain; it does not authenticate a customer-owned From domain.
- Fallback handling: A default reply handler can accept messages while explicit bounce domains handle returns.
Risky wildcard use
- TXT shortcuts: A wildcard TXT in an authentication subtree can synthesize answers for selectors or policy names you did not intend to authorize.
- 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 concrete DNS name or delegation changes the answer.
A controlled customer-subdomain pattern can use a wildcard MX for replies, an explicit bounce domain with SPF, and DKIM on a known authentication subdomain. The parent DMARC policy can be inherited by customer subdomains; publish explicit records for each sending Author Domain and the Organizational Domain for full DMARC participation. The example assumes relaxed identifier alignment between customer.x.example, bounce.x.example, and auth.x.example. The explicit customer DMARC record makes customer.x.example exist, so the example also gives that tenant an explicit MX. All names and provider targets are illustrative.
Safer customer-subdomain patterndns
*.x.example. 300 IN MX 10 replies.example.net. customer.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" _dmarc.customer.x.example. 300 IN TXT "v=DMARC1; p=none; rua=mailto:d@x.example"
Do not let wildcard TXT records become policy
Wildcard TXT records can return a DKIM public key or DMARC policy at unintended names. A public key alone does not let someone sign messages without the private key, but broad selector responses make authorization and key retirement harder to control. Publish authentication records at the exact names receivers query.
- 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.
There is a separate, valid wildcard TXT use for external DMARC report authorization. A report destination accepting reports for any domain can publish *._report._dmarc.reports.example.net with v=DMARC1. This authorizes report delivery, not a domain's sending policy. When a rua destination is in another Organizational Domain, verify that the receiving service publishes the required authorization, as specified in RFC 9990.
SPF best practices
SPF authorizes sending IP addresses for the RFC5321.MailFrom domain, commonly shown as the Return-Path. DMARC gets an SPF-based pass only when SPF passes and that domain has identifier alignment with the visible From domain. A passing SPF result for an unrelated provider domain does not satisfy DMARC.
- One record: Publish one SPF TXT record at each MAIL FROM domain. Multiple SPF records produce a permanent error.
- Lookup limit: Keep evaluation within 10 DNS-querying mechanisms and modifiers across nested include and redirect processing. This is a term limit, not a count of every DNS packet.
- Authorization: List only active senders, remove stale include mechanisms, and never publish +all.
- Alignment: Use a custom bounce domain with the same Organizational Domain as the visible From under relaxed alignment. With aspf=s, the domains must match exactly.
- Forwarding: Expect SPF to break on some forwarded mail, so use aligned DKIM as the durable DMARC path.
SPF is not inherited: the parent domain's record does not authorize a MAIL FROM subdomain. The initial SPF TXT query and ip4, ip6, and all terms do not consume the 10-term budget. Avoid ptr and keep void lookups, queries returning no data or NXDOMAIN, to two or fewer. These limits are defined in RFC 7208.
Aligned SPF record for a bounce domaindns
bounce.example.com. 300 IN TXT "v=spf1 include:_spf.sender.example -all"
Move to -all only after every legitimate MAIL FROM source has been inventoried. Some receivers can reject an SPF hard fail before evaluating DKIM or DMARC, so those messages will not appear in aggregate DMARC reports. Check real message headers after each SPF change.
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. Under relaxed DMARC alignment, the d= signing domain and visible From domain must share the same Organizational Domain. With adkim=s, they must match exactly.
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 with rsa-sha256 where supported. Never use RSA keys below 1024 bits or rsa-sha1 signatures, as specified in RFC 8301.
- Rotation: Publish the new public key and allow DNS caches to refresh before switching the signer. Keep the old public key available for queued mail and retries, then retire it after that delivery window.
- Separation: Use different selectors and private keys for separate sending systems. Different selector names pointing to the same key do not isolate a compromise.
DKIM selector rotation example, public keys abbreviateddns
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..." )
Each selector needs its own complete public key; the abbreviated values above are placeholders. CNAME-based DKIM is fine when a sending provider manages key rotation. Publish exactly the TXT record or CNAME requested for each selector, never both at the same DNS name. Keep an inventory of each selector's owner, sending system, creation date, and revocation steps. RFC 8301 defines the RSA key and algorithm requirements. The authentication standards explanation covers how SPF, DKIM, and DMARC work together.
DMARC best practices
DMARC best practice is to start with visibility, fix legitimate senders, then choose enforcement. A domain with p=reject and broken DKIM is not mature. A domain left at p=none without a documented reason is also unfinished. Before using reject, confirm aligned DKIM and assess indirect flows such as mailing lists and forwarding.
DMARC policy rollout stages
Change policy after legitimate senders pass and indirect mail flows have been assessed.
Observe
p=none
Discover senders and fix known sources.
Optional test
p=quarantine; t=y
Supporting receivers treat quarantine as none with t=y; older receivers can still quarantine.
Enforce
p=quarantine or reject
Use after business mail passes and indirect flows have been assessed.
Investigate
unclassified sources
Investigate unclassified sources before changing policy; do not authorize confirmed spoofing.
For a monitored deployment, include v=DMARC1, a p policy, and a working rua destination. Publish one DMARC TXT record at each policy name; the alternatives below must not coexist. Publish for every Author Domain and for the Organizational Domain when it differs. Use strict identifier alignment only after every sender supports exact-domain matching. At the Organizational Domain, sp sets policy for existing subdomains and np sets policy for nonexistent subdomains in supporting receivers. Without either override, p is inherited. A wildcard MX can make otherwise nonexistent subdomains exist, so np=reject alone does not protect them.
DMARC policy alternatives, publish only one at a timedns
; Monitoring _dmarc.ex.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:d@ex.com" ; Optional test, only after senders are ready for older receivers to quarantine _dmarc.ex.com. 300 IN TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:d@ex.com" ; Quarantine _dmarc.ex.com. 300 IN TXT "v=DMARC1; p=quarantine; rua=mailto:d@ex.com" ; Reject _dmarc.ex.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:d@ex.com"
Understand DMARC test mode
RFC 9989 replaced RFC 7489, made pct historic, and introduced DNS Tree Walk policy discovery. With t=y, supporting receivers apply none instead of quarantine, or quarantine instead of reject. Older receivers ignore the flag and apply the published policy, so use p=none while any quarantine or rejection of failing mail is unacceptable.
To create a record, start with a DMARC record generator and then verify the published TXT record with a DMARC checker. Check 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
These controls have separate jobs. A wildcard MX handles inbound routing; it does not authorize outbound mail by itself. An SPF policy using the mx mechanism does consult MX targets, so changing routing can affect that policy. SPF authenticates the MAIL FROM domain, DKIM verifies a signature made with the signing domain's private key, and DMARC checks whether either passing domain has identifier alignment with the visible From domain. Passing authentication does not guarantee inbox placement or prevent display-name impersonation and lookalike-domain abuse.
Flowchart showing From domain, wildcard MX routing, SPF, DKIM, DMARC, and policy action.
|
|
|
|
|---|---|---|---|
MX | Sometimes | Route replies | It routes mail to a receiving system; outbound authorization still needs SPF or DKIM. |
TXT | Avoid for authentication | Publish exact | Explicit SPF and DKIM records prevent unintended answers; report authorization is a separate exception. |
DKIM | Avoid | Use selectors | It supports key separation and rotation. |
DMARC | Avoid | Publish explicit | It keeps policy discovery predictable. |
A compact decision table for DNS wildcard use in email authentication.
For customer subdomains, prefer generated DNS records or a delegated zone when scale allows it. Test wildcard routing after every new record or delegation. When a sender starts failing, inspect the authentication result and the DNS name it queried before changing policy.
How to test wildcard DNS and email authentication
Inspect the DNS response status and any CNAME target, not just returned text. In the earlier example, fresh.x.example should receive the wildcard MX answer. However, auth.x.example exists because it contains the DKIM selector; it needs an explicit MX if it receives mail. This empty non-terminal behavior follows RFC 4592.
Example DNS checks, replace the reserved domains before runningbash
dig MX fresh.x.example dig MX customer.x.example dig MX auth.x.example dig TXT bounce.x.example dig TXT k1._domainkey.auth.x.example dig TXT unused._domainkey.auth.x.example dig TXT _dmarc.customer.x.example dig TXT _dmarc.x.example
The unused selector should not return a valid DKIM key. Allow cached answers, including negative answers, to expire after DNS changes. Then send test messages through every sending system and inspect the Authentication-Results header added by the receiving mailbox.
- Compare smtp.mailfrom with the visible From domain under the selected SPF identifier alignment mode.
- Read s= and d= in DKIM-Signature to find the actual selector and signing domain, then query that selector's full DNS name.
- Confirm that at least one passing SPF or DKIM domain meets DMARC identifier alignment, and check the receiver's dmarc result. A pass for an unrelated provider domain is insufficient.
- Test forwarding and mailing-list routes before enforcement, because changes in transit affect authentication.
A practical rollout plan
Start with discovery. Collect aggregate reports for at least one complete sending cycle, list every source, map each source to an owner, and fix the records that affect real traffic. RFC 9989 advises domains whose users post to Internet mailing lists against p=reject because of interoperability risks. If such a domain still considers reject, observe at least a month at p=none and another month at p=quarantine, then compare the dispositions. 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 every legitimate sending source passes, including low-volume billing and recovery messages. Investigate failures before enforcing policy.
- Enforce: Move to quarantine, observe a full mail cycle, then consider reject after indirect flows are understood.
- Maintain: Back up DNS before changes, document rollback values, and review new senders. Remove obsolete SPF authorizations and DKIM delegations after the final delivery window.
Suped is our DMARC reporting and email authentication platform. Its reporting workflow helps teams investigate failing sending sources before a policy change. Use Hosted DMARC to manage policy changes, and review report results with the team responsible for each sender.
?
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. 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
Use Suped's issue-resolution workflow to identify the affected sender, apply the DNS or signing fix, and verify subsequent mail results. Assign a sender owner to investigate recurring failures before relaxing policy.
Authentication shortcuts to avoid
Many authentication failures come from shortcuts that outlive the emergency that created them. Common examples include wildcard authentication records and shared DKIM keys. These choices become harder to control when volume grows or a tenant leaves.
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 domain at p=none by default after senders and indirect flows have been evaluated. Document the reason if monitoring is the chosen steady state.
- Unknown tenants: Do not let customer-generated subdomains send without named ownership and abuse controls backed by logs.
- Silent changes: Do not allow vendors to add sending sources without DMARC report review.
For non-sending domains, publish SPF v=spf1 -all and DMARC p=reject. Remove obsolete DKIM selectors and provider delegations after queued mail has cleared. SPF is not inherited by subdomains, so explicitly protect any subdomain identities that need their own SPF policy.
The maintained configuration
A mature setup has explicit DNS records, visible sender ownership, working aligned DKIM on every platform, an intentional DMARC enforcement policy, 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 and pass rates tied to repair tasks.
- Alerts: New failures and new senders trigger review before policy has to be relaxed.
Recommended wildcard and authentication setup
Use wildcards for routing when they solve a real multi-tenant problem. Keep SPF, DKIM, and DMARC policy records explicit. Use DKIM selectors tied to separate signing systems, and review DMARC reports whenever those systems change.
For a normal business domain, use no wildcard authentication records, add SPF and aligned DKIM for every legitimate sender, and collect DMARC reports before enforcement. Consider reject only after checking mailing-list and forwarding impact. For an ESP or SaaS platform, wildcard MX can help with customer subdomains, but long-term scale still needs generated records and monitoring with clear ownership.
Frequently asked questions
Use explicit DKIM selectors with separate keys for each signing system. A wildcard public key does not expose the private key, but it lets unintended selectors resolve and makes key retirement harder to control.
Yes, when the zone is controlled and the receiving system validates recipients and handles abuse. Test existing customer names as well as new names: a TXT record or a child record can stop wildcard MX fallback, requiring an explicit MX.
Publish one DMARC TXT record at _dmarc followed by the Author Domain, such as _dmarc.customer.example.com. Publish at the Organizational Domain too when it differs. Parent policy inheritance covers subdomains without their own policy; a wildcard DMARC record is unnecessary.
Start active sending domains at p=none, fix legitimate sources, then use quarantine. Consider reject only after aligned DKIM passes and indirect flows have been assessed. Non-sending domains can usually start at reject.
No. DMARC passes when either SPF or DKIM passes with identifier alignment to the visible From domain. Configure both because forwarding often breaks SPF and message changes can break DKIM.
Use a documented risk-based schedule based on the signing provider's rotation controls and your key-exposure risk. DKIM has no universal annual rotation requirement. Publish the new selector before switching signing, retain the old public key through the queue and retry window, and revoke a compromised key immediately.
