Scope: Sonic DNS TXT publication and verification of mail sent through Sonic for your own domain. This is not SonicWall Email Security, a new web-hosting signup guide, or a universal DKIM-key issuance procedure. No customer account, DNS change or test email was used for this article.
Quick answer
If Sonic actually sends your custom-domain mail, its current help documents the SPF authorization include:mail.sonic.net. Add it only as part of the one approved SPF policy at the domain Sonic evaluates, preserving other legitimate senders. Sonic documents managed outbound DKIM signing, but some domains require provider-specific instructions. Verify the intended signature; do not invent a selector or public key. Sonic SPF guidance, DKIM rollout and exceptions.
Sonic DNS supports TXT records for authentication. The documented Member Tools screen provides a practical TXT-publication route below. CNAME-based DKIM, provider-issued signing changes and an existing-record save flow not matching that screen need the appropriate confirmed procedure before you proceed. A published record is not proof that the sender is correctly signing.
Choose the correct Sonic situation
For an address ending in @sonic.net, Sonic controls the domain's authentication policies. You cannot customize its SPF, DKIM or DMARC for your own campaign platform. For a domain you own, your DNS administrator can configure authentication for the actual services sending mail. A third-party client submitting through Sonic is different from a third-party platform sending directly. Sonic DMARC policy explanation.
Sonic's current hosting notice calls web hosting a legacy service and says new hosting cannot be added; removed hosting cannot be re-enabled. It explicitly distinguishes domain registration and DNS as continuing supported services. Do not cancel a legacy hosting package as an authentication troubleshooting step. Confirm any mail-service consequences with Sonic first. Hosting service notice.
This guide does not treat a Sonic internet connection as evidence that Sonic sends your domain's mail. Identify the actual mailbox service and every website, billing or marketing application that sends as the domain. If another provider sends the mail, use its account-issued authentication instructions. For example, the Microsoft 365 setup guide applies to Microsoft-hosted mail even when Sonic hosts the DNS.
Prepare a safe change
Get the domain owner's approval for the intended changes. Record the visible From domain, actual MAIL FROM or bounce domain, DKIM signing domain and selector where known, and the current DNS host. Export the zone and preserve the complete existing records, TTLs and authentication policies for rollback.
Check the public NS delegation, including any delegated sending subdomain or _domainkey child zone. Make changes only in the zone that is authoritative for the exact owner. Registration at Sonic or a DNS editor visible in an account does not prove that the public internet uses it. Do not change nameservers merely to add authentication records.
Preserve MX, A/AAAA, NS, SOA and unrelated TXT entries. Review existing DMARC policy at the From domain and any applicable inherited parent policy before adding a direct record. A new subdomain policy can override an inherited one; it is not necessarily an empty-policy situation.
Publish a TXT record using Sonic Member Tools
Sonic's SPF help and embedded Member Tools screenshot show the Host Records route and these controls:
- Sign in to Member Tools, open the documented Host Records page and choose the intended domain.
- Use Export Zone to save the current records before changing them.
- Inspect the existing records. Use Add a new record only when that owner does not already contain the policy you need to update.
- For a new TXT record, choose TXT, enter the correct Name, retain an appropriate approved TTL and put the exact text in Record. The screenshot shows the selected domain appended to Name; its root SPF example leaves Name blank.
- Check the full resulting owner and value, then use Add Record. Recheck the public answer afterward.
The screenshot displays quote-delimited TXT text, while the Host records reference describes TXT content as a quoted string. Preserve the actual payload, not extra nested quote characters. If your live UI differs, obtain Sonic's current field and save instructions rather than assuming its old screenshot is an authenticated test of your account.
For a record below the selected zone, first remove only that zone's suffix from the full required owner. For example, _dmarc.example.com in the example.com zone corresponds to _dmarc; the same calculation differs for delegated child zones. Confirm the editor's resulting full name before saving. Do not append the domain twice or apply a parent-zone shortcut to a delegated _domainkey zone.
Existing rows show Edit and Delete controls, but the source does not establish every subsequent edit/save screen. For an existing SPF or DMARC policy, edit the existing policy through a confirmed workflow; do not create a duplicate as a workaround. Stop if the offered operation would delete unrelated data.
Configure SPF for the actual Sonic sending path
SPF checks the envelope MAIL FROM domain, with HELO used in applicable cases, not just the visible From address. Confirm that the owner being edited is the one relevant to your Sonic submission path.
Sonic's current published single-sender example is:
v=spf1 include:mail.sonic.net -all
That is not permission to replace an existing multi-sender policy. Sonic explicitly warns to account for other mail sources before applying its recommendation. Preserve every authorized sender and existing intentional policy semantics; authorize Sonic only if it actually sends for that owner. Current provider recommendation.
Keep one SPF policy beginning v=spf1 at each evaluated owner. Other TXT records may coexist there, but a second SPF policy is an error. Evaluate the entire policy, including nested includes, against the ten DNS-dependent-term limit. If all is present, a redirect modifier is not used. Do not arbitrarily replace ~all with -all while troubleshooting; neither guarantees the receiver's final handling. SPF standard.
After any approved merge, recheck the resulting public policy and test every legitimate sender, not only Sonic. Avoid unnecessary manual flattening that replaces provider-managed authorization with a snapshot of IP addresses that may change.
Verify managed Sonic DKIM, do not invent records
Sonic's January 2024 announcement describes signing customer-owned domains and says some customers may need special instructions. It also states that customer-domain DMARC was not automatically added in that rollout. This is historical deployment evidence, not confirmation of your account's present state. The current DMARC help confirms outbound signing as the provider's intended behavior. Rollout notice, current policy help.
Send through the intended Sonic mailbox path to a controlled recipient and inspect the actual DKIM signature. Use its d= signing domain and s= selector to identify the public-key lookup owner. Do not assume the selector is default, copy another customer's key or generate an unrelated key pair. If signing is absent, unaligned or unverifiable, request the domain-specific procedure from Sonic.
When Sonic supplies a TXT public-key instruction, preserve the exact owner and full value. Publish only public DNS material, never a private key. If it supplies CNAME instead, use a confirmed CNAME workflow: the TXT screenshot is not a CNAME tutorial. A CNAME cannot conflict with other data at that same owner. At an external DNS host, disable proxying and per-record flattening where supported, and verify that zone-wide, apex or same-zone behavior preserves the issued alias. Stop if mandatory behavior cannot do so. DKIM protocol.
DNS publication and signing activation are separate. Publishing a public key does not make an application sign; a passing signature from a different service does not prove the Sonic path works.
Introduce DMARC without weakening existing policy
Preserve any current direct or inherited DMARC policy, including reporting destinations and alignment settings. Do not replace a working policy with a minimal template merely because it is shorter.
Only for a first policy with no applicable existing direct or inherited policy, and with explicit domain-owner approval, a monitoring start can use a TXT record at _dmarc.<from-domain> with v=DMARC1; p=none. Replace the placeholder with the actual From domain and map the owner to its authoritative zone. This monitoring policy requests no DMARC enforcement and contains no report destination; it does not itself provide monitoring reports or stop spoofing.
Choose any report recipient deliberately and obtain permission for sharing aggregate sending data. External aggregate reporting also requires the destination-authorization checks defined by Organizational Domain; a same-Organizational-Domain destination has the specified exception. Technical authorization and permission to share data are separate. Aggregate reporting, section 4.
Review legitimate mail flows and reports before an owner-approved enforcement change. Do not promise that reject forces every recipient to reject, or that authentication guarantees inbox placement. DMARC protocol.
Prove the result at DNS and receiver boundaries
Identify the authoritative nameserver for the exact zone, including any delegation. Replace the angle-bracket placeholders in these read-only checks with real values:
dig @<authoritative-nameserver> TXT <actual-spf-owner>
dig @<authoritative-nameserver> TXT <selector>._domainkey.<signing-domain>
dig @<authoritative-nameserver> TXT _dmarc.<from-domain>
For CNAME-issued DKIM inspect the alias and resolved key instead. Compare authoritative answers with a recursive resolver after relevant TTLs; waiting cannot repair the wrong authoritative owner or payload.
Send a fresh message through each intended application. Trust authentication results only from the recipient system's documented trusted boundary, which strips or identifies untrusted incoming results, or its authenticated diagnostic view. Header position and a familiar authentication-service name alone are not proof.
Record SPF's evaluated domain and result, the intended Sonic DKIM signature's selector, signing domain and result, the visible From, and DMARC. Require the intended DKIM signature to pass and align with From, plus a trusted dmarc=pass. SPF-only DMARC success is insufficient to verify the DKIM setup. Relaxed alignment uses the same Organizational Domain; strict adkim=s requires an exact DKIM-domain match, and aspf=s applies separately to SPF. These are not tests performed while writing this guide.
Troubleshooting and rollback
- Sonic address used by an external campaign service: do not attempt to edit
sonic.netpolicy. Use an authorized domain you control and configure the actual campaign sender. - TXT exists in Member Tools but not publicly: check authority, delegation and expanded owner before blaming propagation.
- SPF passes but DMARC fails: compare the evaluated envelope domain with visible From and verify intended aligned DKIM.
- DKIM cannot be found: use the actual signature selector, then ask Sonic for any required account-specific instructions. Do not guess records.
- Existing-record workflow differs: stop and obtain a supported edit/save procedure. Do not delete and recreate a multi-purpose zone.
- A change breaks other senders: compare the approved change with the export. Restore only the affected approved record values with the administrator, then retest. Do not cancel hosting or switch nameservers.
Give support the exact service, domain, sending path, authoritative DNS host, public answers and redacted recipient diagnostics. Keep passwords, private keys and message contents out of the ticket unless specifically necessary and authorized.