Provider documentation checked on 8 November 2026. Account-generated values and current product support must still be verified for a real deployment.
1-grid sells more than one email and hosting configuration. A Professional Email Basic or Pro account is not automatically the same configuration as a cPanel-hosted mailbox. Establish the product, authoritative DNS provider and actual outbound route before applying a generic 1-grid SPF or DKIM recipe.
Confirm the service and DNS owner
Record the subscribed product, domain, control panel, mailbox submission host and any website or application that also sends mail. Identify the authoritative nameservers. A registrar account, hosting panel and DNS authority may belong to different services. Export the existing zone or capture the relevant records before editing anything.
The current 1-grid Professional Email guide covers Email Basic and Pro and includes service-specific DNS instructions. Its displayed SPF example contains placeholders and formatting that should not be published literally. Obtain the valid values for your account from the active service configuration or 1-grid support and have the complete policy checked. This is a documented evidence limitation, not a reason to guess a server address or copy a third-party recipe.
Follow the correct configuration branch
References: RFC 7208 §4.5, RFC 7208 §4.6.4, RFC 6376 §3.6.2.
For Professional Email, the cited guide directs the domain administrator to SmarterMail Settings, then the Email Signing card and Enable. The resulting Text Record Name and Text Record Value are the name and content of a DNS TXT record, not two separate TXT records. Use the values generated for your domain rather than the sample public key. Confirm whether DKIM has been generated and enabled for your domain, what selector is in use and who must publish its public value. Do not assume that a recommendation to add a record proves the service is currently signing.
For a cPanel-hosted route, if the host exposes Email Deliverability, open that interface and manage the exact domain. cPanel documents suggested DKIM and SPF records and a Repair function, but Repair is unavailable when the system does not control the domain's DNS. In that case, copy the correct public values to the authoritative DNS operator. Review suggestions before applying them, especially when other legitimate services share the domain.
Keep SPF as one valid policy at the evaluated domain. Merge required authorised mechanisms rather than adding a second v=spf1 record. Check lookup dependencies and avoid blanket permission for addresses unrelated to the actual route. DKIM public values belong at the specified selector; private signing keys must stay with the signer. Do not change inbound MX routing just to troubleshoot an outbound signature unless the product migration explicitly requires it.
Verify the message, not only the panel
References: RFC 9989 §5.3.5.
Send a controlled message through each intended route: the mailbox client, webmail if used and any website application. At a controlled recipient, preserve the original received source and trusted authentication results. Compare From, envelope domain, every DKIM d and s, and the resulting alignment. A panel status indicates a configuration observation, not proof that every application uses that route.
Illustrative result: From accounts@example.org and DKIM pass for d=example.org provides an exact aligned DKIM path. If SPF instead passes for an unrelated relay domain, that does not remove the successful aligned DKIM path. Conversely, a pass for only unrelated provider identities does not establish alignment. This is a synthetic comparison; no live 1-grid account or delivered message was tested for this article.
Resolve failures and maintain trust
If no signature appears, confirm signing is enabled for the specific product and outbound path. If the selector cannot be resolved, verify the authoritative zone and exact record name. If the signature fails after leaving the service, investigate downstream changes. Ask for a supported aligned configuration if the product cannot supply the required identity; do not assert a feature exists without confirmation.
Keep the prior DNS configuration and a narrow rollback plan. Do not replace a shared SPF policy wholesale or disable unrelated senders. The provider's support scope distinguishes routine guidance from advanced work, so confirm assistance and any charges before commissioning a complex change. After product migrations or account retirement, review unused selectors and authorisations only after confirming no active flow depends on them.