Combell SPF, DKIM and DMARC setup, step by step

For Combell email, choose SPF by mailbox product before changing DNS. Basic, hosted Exchange and Microsoft 365 have different authorizations. Combell’s current documentation says standard mailboxes do not support DKIM; its managed mailserver option can have DKIM installed by support. A domain registered at Combell does not automatically send through Combell. Combell SPF guidance and DKIM product limits.

This guide covers mailbox and website sending, the supported DKIM paths, and evidence to collect before accepting DMARC. No customer account, DNS changes or real delivery tests were performed.

Start with the sending route, not the domain registrar

Write down each route separately: employee mailbox, contact form, order confirmation, CRM notification and newsletter. For each, record the sending service, visible From domain, SMTP submission host, envelope sender domain and person responsible. A website hosted at Combell might submit to a different email provider; a Combell mailbox might coexist with a marketing service. Those are separate authentication tasks.

Before editing, obtain access to the authoritative DNS zone and the appropriate mail administrator account. Export the existing zone, including SPF, every DKIM selector and DMARC. Identify any sending subdomains and delegated zones. Keep the current TTLs and a copy of the exact old values for recovery. Do not move nameservers or replace MX records merely to add outbound authentication.

Your decision is practical:

• Standard mailbox: verify the correct SPF route and measure SPF alignment; do not invent a DKIM key.
• Managed mailserver: ask support to confirm signing availability for that server and domain, then obtain its public DNS record and activation procedure.
• Microsoft 365: use the tenant’s Microsoft DKIM configuration, not a generic Combell selector.
• External sender: use that sender’s account-generated authentication instructions, even if Combell hosts DNS.

Select the documented Combell SPF authorization

Combell lists these single-provider examples. They are alternatives, not three records to install together:

Basic mailbox: v=spf1 include:_spf.relay.mailprotect.be -all
Exchange mailbox: v=spf1 include:_spf.powermail.be -all
Microsoft 365 mailbox: v=spf1 include:spf.protection.outlook.com -all

Use the one matching your actual service. For Combell-hosted authoritative DNS, the documented path is My products → DNS & forwarding management → Manage beside the domain → TXT records. Its root-domain example uses an empty hostname. If another company operates the authoritative nameservers, make the change there instead. Combell’s product-specific SPF instructions.

SPF evaluates the envelope MAIL FROM domain, normally visible in the delivered Return-Path, not simply the From address readers see. Publish one SPF TXT policy at each evaluated owner; a root policy does not automatically cover a bounce subdomain. Merge needed authorizations into that owner’s existing policy, retaining legitimate senders and the intended final qualifier. Do not add a second v=spf1 record or blindly replace -all with ~all.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Count evaluated DNS-querying terms across nested policies: include, a, mx, ptr, exists and redirect share a limit of ten; exceeding it returns permerror. This is not a count of ten providers or ten visible includes. ip4, ip6 and all do not consume that term budget. SPF rules, RFC 7208.

What to do about Combell DKIM

For standard mailboxes, Combell explicitly documents that DKIM is unavailable. Publishing a public key generated by an unrelated tool cannot make that mailbox sign. For the separately documented mailserver product, support can install DKIM. Ask for the signing domain, selector, DNS type, full owner, public value or target, and how support will confirm activation. Do not request or publish a private key. Flexmail is another product, not a setting that enables signing on a standard mailbox. Combell’s DKIM and mailserver distinction.

A useful support request identifies the product and domain, then asks: “Does this exact sending route sign with my domain? Which public record should I publish, and what action activates signing?” Save the answer with your configuration record. If the service cannot sign, document the limitation rather than treating a DNS checker’s empty result as an installation failure.

For Microsoft 365, obtain Selector1CNAME and Selector2CNAME from the domain’s Defender DKIM page or Exchange Online PowerShell. Publish both returned CNAME targets, then enable signing after detection. Microsoft’s newer target format includes an assigned dynamic partition, so do not calculate targets from the tenant name or copy another domain’s values. Microsoft DKIM configuration.

For any supported DKIM record, check whether the editor expects a relative owner such as selector._domainkey or a fully qualified name. Avoid appending the domain twice. A CNAME owner must not also contain TXT or other conflicting data. Preserve unrelated selectors used by other senders.

For Microsoft 365 or another supported route that actually issues a CNAME, apply the following at the authoritative DNS host; these controls do not create DKIM support for standard mailboxes or change a TXT key to CNAME. Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls. For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Make website mail use the intended submission path

Combell documents that shared-hosting PHP mail() uses relay.webhosting.be. Its alternative uses a Basic Mail mailbox and smtp-auth.mailprotect.be, with port 465/SSL or 587/TLS. Port 25 traffic is redirected to the shared relay. Where MX points elsewhere, Combell says to create the mailbox at that other mail service too. Authenticated website sending.

Configure your application’s SMTP transport rather than only changing its displayed From address. Keep credentials in the application’s protected secret store, not DNS or a support screenshot. Use an address on your controlled domain as From and the visitor’s address as Reply-To. Retest password resets and contact forms independently: changing one plugin need not change every application mail path. Authenticated SMTP login alone does not establish DKIM support on the Basic Mail product.

Preserve DMARC while you repair authentication

DMARC passes when either SPF passes with an aligned envelope domain or DKIM passes with an aligned signing domain. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. The aspf and adkim tags control alignment, not spam-folder versus inbox handling. Current DMARC standard, RFC 9989.

Read the current _dmarc policy and any applicable inherited policy before adding anything. Retain established quarantine or reject protection. Combell’s simple p=none example is not a reason to downgrade a working policy. If no policy exists, a monitored initial policy may be appropriate after reviewing all senders. Add an approved aggregate-report destination and assign someone to investigate failures. p=none alone does not arrange reports or guarantee delivery.

Use RFC 9989 rather than older percentage-rollout advice: pct is obsolete. Readiness should depend on representative sending evidence, including application mail and forwarded traffic, rather than a percentage dial. Aggregate reporting is specified in RFC 9990; report destinations outside the policy domain’s Organizational Domain require destination authorization. Failure reports can expose message contents and personal data, so do not add ruf by default. RFC 9991 privacy guidance.

First DMARC policy when no policy already applies

Use this procedure only after confirming there is no existing or inherited DMARC protection for the From domain. Edit an existing policy rather than creating a duplicate. A monitoring policy is a starting point for a reviewed rollout, not a replacement for established enforcement.

• For From addresses at example.com, create a TXT record at _dmarc.example.com. In the example.com zone, the relative Name is _dmarc.
• For From addresses at news.example.com, the full owner is _dmarc.news.example.com. In the parent example.com zone, use _dmarc.news; in a separately delegated news.example.com zone, use _dmarc instead.
• Confirm your editor’s resulting full owner and publish this minimal value only for that genuinely new policy:

v=DMARC1; p=none

To request aggregate reports, first provision an approved reporting mailbox or service, then append a semicolon-separated rua tag with its actual destination. For example, the suffix ; rua=mailto:dmarc-reports@example.com is illustrative, not a working destination to copy. A destination outside the policy domain’s Organizational Domain needs its authorization record under the destination’s DNS, as specified in RFC 9990 section 4. Validate the single published policy and arrange a report review before any move to enforcement.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS and then verify real messages

Substitute your actual domains, selector and authoritative nameserver in these read-only commands. example.com, bounce.example.com, SELECTOR and ns1.example.net are placeholders, not Combell settings.

dig +short NS example.com
dig @ns1.example.net example.com TXT +noall +answer
dig +short TXT bounce.example.com
dig +short TXT SELECTOR._domainkey.example.com
dig +short CNAME SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

Check the authoritative answer first, then a public recursive resolver. Confirm one SPF policy at the actual envelope domain, the exact public DKIM record for supported signing routes, and one effective DMARC policy. For CNAME-based DKIM, follow the target to its TXT key. Several quoted strings inside one TXT resource record are not several SPF records. A missing answer is a reason to inspect the owner and zone, not to assume a fixed waiting period will fix it.

Next send a fresh message from each real route to a mailbox you control at an independent receiver. Open the original headers. Trust the receiver’s own Authentication-Results, not an arbitrary header supplied upstream. Record spf, smtp.mailfrom, dkim, header.d, the signature’s s= selector, dmarc and header.from. Authentication-Results trust boundaries.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Accept a route only when the identities match your intended configuration and the trusted receiver reports DMARC pass. On standard mailboxes, record that DKIM is unavailable and show the aligned SPF pass on which DMARC relies. For a DKIM-capable route, require the expected signature and successful verification. Keep direct and forwarded tests separate. A forwarded message can lose SPF; without aligned DKIM, that limitation matters. Authentication success is not an inbox-placement guarantee.

For a DKIM-capable branded route only, acceptance requires the intended provider signature to have trusted dkim=pass and its actual d= aligned with the intended From under the applicable adkim mode, plus trusted receiver dmarc=pass. SPF-only DMARC success does not complete that DKIM deployment. Do not apply this requirement as a claim that the documented standard mailbox can sign. Independently investigate SPF fail or softfail (authorization mismatch), temperror (transient evaluation failure, often DNS), and permerror (uninterpretable policy, duplicate records or lookup limits) at the observed smtp.mailfrom, even if aligned DKIM makes DMARC pass. A passing provider-domain SPF identity without alignment is a different outcome from these errors. DMARC alignment, SPF results.

Troubleshooting Combell authentication

• SPF fails after switching products: compare the actual submission route with the Basic, Exchange or Microsoft 365 authorization. Do not add all three “just in case.”
• Standard mailbox has no DKIM signature: check the documented product limitation before repeatedly creating keys. Consider a signing-capable route if your requirements demand it.
• Website still uses the shared relay: inspect the plugin transport and port, and confirm the SMTP configuration applies to the failing message type.
• SPF passes but DMARC fails: compare smtp.mailfrom with header.from; a pass for an unrelated domain cannot authenticate your visible From domain.
• Public DNS differs from the control panel: check nameservers, delegated subdomains, duplicated suffixes and cached old answers.
• Managed-server DKIM record exists but signing is absent: ask support to verify activation on the exact sending server, with a redacted header and timestamp.

Related authentication guide

For the Microsoft 365 branch, use the Microsoft 365 email-authentication guide alongside the tenant’s current settings.