Review SPF and DKIM in Legacy Bread Basket or Webuzo

Webuzo can expose SPF/DKIM and mail-deliverability controls for domains on a configured mail service. Historical Bread Basket menus and addon-domain checkboxes are not a reason to delete or reassign an existing primary domain.

Do not use domain removal as an authentication repair

The earlier guide changed the primary domain and removed/re-added a domain to trigger record creation. That can affect websites, mail and account associations. Preserve the existing domain and use the installed version’s supported deliverability/DNS controls, or request a narrowly scoped support procedure.

Plan the actual sending identities

List the services that send for the domain and obtain their required SPF authorization and DKIM selector/public record. Do not assume the old “unsigned” error proves one particular cause or that SPF and DKIM are interchangeable ownership checks. SPF authorizes an SMTP identity; DKIM verifies a signature associated with a signing domain.

Configure existing-domain records safely

1. Enter the verified HTTPS panel, select the exact domain and inspect its existing mail-deliverability configuration and records.
2. Use the supported SPF/DKIM generation or management feature where available. Menu labels differ from legacy Bread Basket.
3. Review the proposed SPF policy against all legitimate senders. Publish one SPF policy at its owner, preserving unrelated TXT records.
4. Publish the exact DKIM public key or provider-required delegation at the correct selector name. Keep private keys private and retain old keys as required for a planned rotation.
5. If DNS is external, publish there. A local DNS Zone Settings row alone does not establish that public receivers see the record.

For a newly added domain, a mail-validation checkbox may initialize records on supported versions. Review its output and actual sending configuration rather than assuming it authenticates every third-party route or enforces a safe DMARC policy automatically.

Verify without changing unrelated services

Check authoritative DNS and send an authorized test through each intended service. Inspect the actual DKIM d= and s= fields and trusted receiver results. A failure may involve the wrong selector, stale key, unsigned route, forwarding or changed signed content; a successful signature does not prove the sender is harmless. Avoid blanket service restarts, whole-zone resets and domain deletion.

References: Webuzo email-management controls, DNS zone settings and DKIM verification model.

Reviewed October 15, 2026. Documentation review only; no primary domain, DNS record, signing key or Webuzo service was changed.