Select the Combell mail product before selecting a record
Combell is not a single authentication configuration. Its SPF instructions distinguish Basic e-mail, Exchange e-mail and Microsoft 365. Its separate DMARC article states that DKIM is not available on standard mailboxes and describes a support-installed alternative on Combell Mailserver. Those differences determine what a responsible configuration plan can promise. This guide covers the documented product choices and DNS preparation, not a verified tenant implementation or a universal DKIM recipe. The SPF article was updated on 1 April 2025; the DMARC article was updated on 2 September 2026. Confirm their applicability to the actual subscription before making changes. Combell SPF guidance Combell DMARC guidance
Begin with an inventory that names the product rather than merely the vendor on an invoice. Record which system sends staff correspondence, which sends website notifications, which sends campaigns and which receives replies. A website hosted at Combell does not establish that every message uses its Basic e-mail infrastructure. Likewise, an Exchange subscription and a Microsoft 365 route should not receive a Basic e-mail authorization simply because their DNS is managed through the same portal. This inventory is proposed work: no account, domain or message has been inspected for this manuscript.
Reconcile SPF with the actual sending route
The provider publishes separate SPF examples for its three named products. Treat them as product-specific instructions requiring an applicability check, not as interchangeable additions. Obtain the current approved route information, retrieve the existing complete SPF policy through an authorized process, and identify other legitimate senders before proposing the resulting record. Do not replace a multi-sender policy with a short example or publish a second SPF policy alongside it. Combell SPF guidance
SPF is evaluated for the SMTP MAIL FROM identity, or the HELO identity in the relevant cases; it does not directly authenticate the visible author address. A policy authorizing an outbound service can therefore be correct while the message still lacks DMARC alignment. Keep the envelope domain, visible From domain and observed outbound route as separate fields. Avoid describing a correct SPF record as proof that all mail carrying the organization's display name is genuine. RFC 7208, sections 2.3–2.4
Review the expanded SPF dependency path, including services already present. The protocol limits evaluated DNS-querying terms; this is not simply a count of textual include entries, packets or cached answers. Additional authorization must remain within the evaluation rules without silently deleting a legitimate sender. The final all mechanism expresses a policy result, while receiver handling remains a separate decision. Neither a hard fail nor a provider's delivery-oriented wording guarantees a particular inbox or rejection outcome. RFC 7208, sections 4.6.4 and 8
Publish in the authoritative DNS context
For domains managed in its documented DNS interface, Combell directs the operator through My products, DNS and forwarding management, management beside the domain, and TXT records. Its SPF instructions use a blank hostname for the domain itself. Apply that behavior only to the documented editor and intended zone. A DNS zone managed elsewhere requires that provider's own name-entry semantics; the Combell instructions do not prove another editor handles blank names or suffixes identically. Combell SPF guidance
Before publication, record the intended fully qualified owner name, record type, complete content, TTL and rollback value. Compare that intended owner with the editor's preview. After an authorized change, distinguish the stored control-panel view from authoritative answers and resolver observations. TXT presentation can include quotation marks or multiple character strings; those display details should not be mistaken for several independent SPF policies. The operator should preserve the intended logical value and record boundaries. RFC 1035, sections 3.3.14 and 5.1 RFC 7208, sections 3.1–3.3
Combell's stated one-to-four-hour interval is operational guidance, not proof that every cache has refreshed at a particular moment. A worksheet should retain observation times and distinguish previous cached answers from the current authoritative state. Do not repeatedly rewrite a correct record merely because one resolver still returns an earlier answer. Conversely, elapsed time cannot repair a wrong owner name or an accidentally duplicated policy.
Respect the standard-mailbox DKIM limitation
The Combell DMARC page explicitly says DKIM is unavailable on standard mailboxes. It identifies Combell Mailserver as a different option on which support can install DKIM, and Flexmail as a separate marketing product. These alternatives do not establish that standard mailboxes have acquired a DKIM switch, nor do they supply a universal selector or public key. A project requiring aligned DKIM should retain this as a product-fit decision, with current account applicability unresolved. Combell DMARC guidance
Do not publish an invented DKIM record to make a checklist look complete. DNS publication alone cannot cause an unsigned route to sign messages. The signer must possess the corresponding private key and apply an appropriate signature, while the receiver obtains the public verification material through the signature's selector and signing domain. A support-assisted installation needs its own approved scope, current instructions and subsequent message evidence. No support contact or installation has been performed here. RFC 6376, sections 3.5 and 3.6.2.2
Decide DMARC policy separately from the sample
Combell describes adding DMARC as a TXT record at _dmarc and gives a monitoring-policy example for users who do not want a specific enforcement policy. That example is not permission to replace an existing quarantine or reject policy. Review the organization's complete sender inventory and approved reporting arrangements before changing policy. A generator can format a decision; it cannot decide the organization's tolerance for unauthenticated mail. Combell DMARC guidance
DMARC can pass through a qualifying aligned SPF result or a qualifying aligned DKIM result. Standard-mailbox DKIM limitations therefore do not by themselves prove every message fails DMARC, but neither does a published SPF policy establish that the actual envelope identity aligns. Record the receiver's results for the approved route when evidence is available. Authentication remains distinct from reputation, content assessment, recipient preference and final delivery. RFC 9989, sections 2.4 and 4.4
Fictional diagnosis: the wrong product assumption
Consider a fictional organization, Cedar Workshop, whose administrator sees Combell on the DNS invoice and selects a Basic e-mail example. Its finance correspondence actually uses a different subscribed mail product, while the website uses another sending service. A colleague then proposes a guessed DKIM selector to satisfy an internal checklist. Nothing in this scenario is a measured incident or an executed test.
The proposed diagnosis begins by correcting the product inventory. The team reconciles each legitimate sender against the existing SPF policy and records which routes can supply aligned identities. It leaves DKIM unresolved for standard mailboxes rather than inventing a record. If the business requires DKIM for that route, the owner evaluates the supported product alternative and obtains applicable instructions. The successful outcome is a clear decision and evidence plan, not a claim that DNS changes have already fixed delivery.
Blank acceptance worksheet
- Subscription and product: ____; responsible account owner: ____.
- Sending application, envelope domain and visible From domain: ____.
- Authoritative DNS operator and intended complete owner name: ____.
- Existing SPF policy and legitimate senders retained: ____.
- Product-specific authorization confirmed on date: ____.
- Expanded SPF evaluation review and unresolved dependencies: ____.
- DKIM availability for this exact product and installation responsibility: ____.
- Current DMARC policy, approved reporting destination and change rationale: ____.
- Authorized DNS observations and actual received-message evidence: ____.
- Remaining product-fit decisions, rollback owner and release approver: ____.
All fields are intentionally blank. The catalogue implementation requirement, human review, current source applicability, production routes, visual/accessibility review and owner release remain open. This draft is not operational acceptance and makes no delivery guarantee.