Cerb SPF, DKIM and DMARC setup, step by step

For Cerb Cloud's managed SMTP service, add the documented include:cerb.email authorization to the appropriate existing SPF policy and ask Cerb to permit your customer sender domains and generate their DKIM keys. Publish only the public records Cerb supplies, complete its provider-assisted signing setup, and assign the approved addresses to the intended Cerb Cloud SMTP transport. Then test a real message from each relevant group and bucket. Creating DNS records alone does not authorize a domain or activate the Cloud signer.

This guide covers Cerb Cloud managed outbound mail using your own domain. It does not cover self-hosted Cerb, remote SMTP, website or community-portal domains, incoming mailboxes or the Null transport. The Admin Quick Start explicitly documents the SPF include and provider-assisted domain-permission/key request.

Which Cerb setup needs these steps?

Cerb Cloud provides a managed SMTP service and temporary addresses under an instance domain such as INSTANCE.cerb.email. Cerb configures SPF, DKIM and DMARC for those provider-domain addresses. That does not authenticate support@example.com or another customer-owned domain automatically.

The Cloud page describes assistance with customer-domain authentication when moving to a subscription. Confirm eligibility and the intended domains with Cerb; do not infer a particular plan entitlement from a screenshot. A Cloud installation can also use remote mail services, so merely being hosted in Cerb Cloud does not establish the outgoing route.

An administrator is required to enter Setup and perform global configuration. Worker permissions alone are insufficient. You also need the DNS owner's authorization and access to the actual authoritative zone. Inventory existing SPF, DKIM selectors, direct and inherited DMARC policy, sender addresses, group/bucket selections, default sender and any backup transport before changing them.

1. Identify the managed transport and sender identities

Go to Setup → Mail → Outgoing → Email Transports. The Quick Start says Cerb Cloud supplies a transport named Cerb Cloud SMTP. Confirm that this is the existing approved route for the customer domains in scope. Do not replace a corporate transport or a deliberately disabled test route.

Under Setup → Mail → Outgoing → Sender Addresses, review each address that should appear in From. Each can be linked to a specific transport. An existing address can also be edited through Search → Email Addresses, using We send email from this address, as documented in the Quick Start. Apply and save only the approved sender/transport associations using the actual editor; the public sources do not prescribe a universal DKIM activation button.

Review the fallback sender under Setup → Mail → Outgoing → Settings. It is used where no more-specific sender is configured. Group and bucket selections can determine which identity is actually used in a message, so do not test only the default and assume every brand is covered. See Sender Addresses and Mail Transports.

Keep any backup transport in the test inventory. It may have different sending infrastructure, SPF requirements and signing keys. The Null transport discards messages; a simulated send through it is not a delivery test. Changing a transport is a routing decision requiring its owner's approval, not an automatic authentication repair.

2. Request customer-domain permission and DKIM from Cerb

The native Cloud workflow is provider-assisted. Ask Cerb to permit the exact sender domains and generate DKIM keys for the managed Cloud transport. Include your instance identity, intended From domains and the existing transport you want to use. Do not send passwords or private keys.

Request a complete implementation packet containing:

• The approved domains and sender scope, including any relevant subdomains.
• Each exact DNS type, full owner and complete public value or target.
• The intended signing domain and selector, and how they relate to each sender domain.
• The required publication and provider-completion sequence, including confirmation that domain permission and signing are ready.
• Any account-specific constraints or controlled transition instructions if a signer already exists.

The public guide establishes this request path but does not publish a universal selector, DNS type or fixed post-publication activation sequence. Do not create a key with an unrelated generator or invent a self-service Verify/Enable DKIM control. Have Cerb confirm completion of its domain permission and signing configuration before relying on the new branded signer. If it cannot provide an applicable packet, pause that domain's rollout rather than guessing.

Cerb's optional custom website URL also uses a CNAME, but it is a separate web/SSL feature. A portal CNAME is not a DKIM record and should not be copied into the signing setup.

3. Merge the documented SPF include

The official authorization component for the managed Cloud route is:

include:cerb.email

It is not a standalone second SPF policy. SPF checks the actual SMTP MAIL FROM domain, or HELO in the applicable empty-envelope case, not automatically the visible From. The public Cerb pages do not guarantee a universal runtime envelope identity. Reconcile the provider's instructions with the actual customer-controlled evaluated owner; do not invent a bounce domain or edit a provider-owned policy.

Read the existing TXT policy at that owner. Add the include to its single v=spf1 policy while preserving every legitimate sender, required ordering and the approved terminal qualifier. Do not replace the root-domain policy merely because the visible address uses that domain. See the EmailAuth multiple SPF records guide before adding another TXT policy.

Validate the entire SPF dependency chain against the maximum ten evaluated DNS-dependent terms, including nested processing. This is not a ten-visible-includes allowance. Preserve redirect semantics: an all mechanism makes redirect ignored. Never insert all into a redirect-based policy without evaluating the consequences. Qualifiers do not guarantee a receiver's inbox or rejection decision. These rules come from RFC 7208.

For an evaluated apex domain example.com, the full SPF owner is example.com, usually entered as @ in that zone. For support.example.com, use relative support in the parent example.com zone, or @ in a separately delegated support.example.com zone. Do not append the suffix twice.

4. Publish the issued public DKIM records

Use the exact type and complete content in Cerb's current packet. A TXT public key must retain all tags and the complete p= value; a CNAME must retain the complete issued target. Never publish a private key or substitute screenshot/example data. DKIM signing is performed by the sending service; publishing its public key does not make an arbitrary SMTP server sign. See RFC 6376.

Map each full owner to the authoritative zone. For an illustrative SELECTOR._domainkey.support.example.com, the relative name is:

• SELECTOR._domainkey.support in example.com.
• SELECTOR._domainkey in a separately delegated support.example.com.
• SELECTOR if _domainkey.support.example.com is itself delegated and you are editing that authoritative zone.

For an apex-domain signer, SELECTOR._domainkey.example.com is relative SELECTOR._domainkey in example.com. Inspect the final full owner if the editor automatically adds its zone suffix. Preserve active selectors and NS delegation; do not delete delegation to force a parent-zone record to work.

Only if Cerb issues a CNAME, check that its owner has no conflicting TXT, A, AAAA, MX or second CNAME. Resolve existing ownership and dependencies before changing anything. Use DNS-only resolution, not an HTTP proxy. Where flattening would hide the required literal CNAME, turn off the applicable per-record flattening control when available and ensure relevant zone-wide, apex and same-zone behavior does not suppress the alias. Do not disable unrelated global features. If mandatory behavior prevents the required answer, stop and coordinate a supported arrangement. TXT-only packets do not require these CNAME settings.

Authentication alone does not require changing MX, incoming forwarding, nameservers, DNSSEC or mailbox-download settings. Preserve those services. In particular, the Quick Start's separate mailbox setup can delete messages after downloading them; it is not part of this outbound guide.

5. Verify DNS and provider completion separately

Substitute actual approved values in these read-only checks:

dig @AUTHORITATIVE_NS ACTUAL_SPF_OWNER TXT
dig @RECURSIVE_RESOLVER ACTUAL_SPF_OWNER TXT
dig @AUTHORITATIVE_NS ACTUAL_DKIM_OWNER ISSUED_RECORD_TYPE
dig @RECURSIVE_RESOLVER ACTUAL_DKIM_OWNER ISSUED_RECORD_TYPE

ISSUED_RECORD_TYPE is a placeholder for the type Cerb supplied, not a literal query type. Compare exact owners, types and complete values at authoritative and recursive resolvers. For CNAME, verify the complete target and that the chain reaches the intended DKIM public key. For TXT, compare the reconstructed full value rather than treating presentation-level quoted strings as separate policies. A nonempty answer is not proof of correctness. Follow delegated authority and account for TTL/cache effects.

Send the resulting public-DNS evidence to Cerb through the agreed implementation channel if requested. Obtain its confirmation that the domain is permitted and signing configuration is complete. Preserve existing working routes until the approved transition is ready. A successful DNS lookup and provider completion are prerequisites, not the final delivered-message result.

6. Test the real Cerb group and bucket path

Cerb's deliverability test guide documents this native send path:

1. Open Search → Tickets and use the + control above the worklist.
2. Choose the intended group and bucket in From.
3. Use a valid controlled recipient and a nonsensitive test subject and body.
4. In Properties, set the conversation status to Open.
5. Use Send Message, then inspect the received message.

The official example sends to mail-tester.com. If using that external service, obtain approval to share the message and headers, use its current generated address and send no customer/private content. The guide's example 10/10 screenshot is not your result, and a composite score is not an authentication acceptance test. A controlled mailbox with trustworthy receiver diagnostics is preferable when you need to establish exact identities.

Read Authentication-Results generated within the actual receiving service's known processing boundary, supported by its documented handling/removal/ignoring of externally supplied result fields. A familiar authserv-id, header position or a pasted pass is insufficient. Ignore attacker-supplied results. If that boundary is unclear, obtain the receiving service's authenticated trace or administrator diagnostics. RFC 8601 explains the trust boundary.

For acceptance, require the intended Cerb Cloud DKIM signature to pass, reconcile its observed d= and s= with the provider's packet, and confirm that d= aligns with the unchanged intended visible From under the actual DMARC policy. Also require trusted receiver dmarc=pass. An unrelated passing signature, a provider-domain rewrite of From or DMARC passing only through SPF does not prove the new branded DKIM setup.

Record the actual envelope/SPF result separately. Relaxed alignment compares Organizational Domains; strict alignment requires exact domains. A child envelope domain does not automatically strictly align with an apex From. Apply the existing adkim/aspf settings and test each meaningful sender, group/bucket, automated route and approved backup path. See RFC 9989.

Preserve DMARC and authorized reporting

Read direct and applicable inherited DMARC policies before changing anything. Keep existing enforcement and approved reporting destinations. Only where no applicable policy exists, the domain owner approves and an appropriate monitoring plan exists, consider a first TXT policy such as the illustrative v=DMARC1; p=none.

For apex From example.com, the full owner is _dmarc.example.com, relative _dmarc in its zone. For From support.example.com, use _dmarc.support.example.com, relative _dmarc.support in the parent zone or _dmarc in the delegated child zone. Check suffix-appending editors. Never duplicate a policy, weaken existing protection to monitoring or copy an unrelated report recipient.

Reporting requires the owner's data-sharing/privacy decision. When a destination's Organizational Domain differs from the Organizational Domain of the domain where the policy was discovered, the report-generating receiver checks DNS authorization. A destination within that same Organizational Domain is excepted, even if its hostname differs. See RFC 9990 section 4. DNS authorization does not replace the owner's permission.

Troubleshooting

Customer-domain sending is refused. Confirm Cerb has permitted that exact domain and that the sender uses the approved managed transport. DNS publication is not sending permission.

Only the provider-domain test passes. Cerb preconfigures the default instance domain. Verify the customer-domain packet and actual From/group/bucket selection separately.

DKIM is missing or fails. Reconcile the observed selector/domain with the issued key, inspect delegation/type/value and ask Cerb to confirm signing completion. A different transport or backup can use another signer. Never rotate keys blindly.

SPF fails while DKIM gives DMARC pass. At the observed envelope identity, fail/softfail indicates an unauthorized connecting sender under that policy; check route and preserved authorizations. temperror indicates a transient evaluation/DNS availability issue. permerror indicates a permanent syntax, duplicate-policy or lookup-budget problem. none means no applicable SPF policy was found. Diagnose each rather than treating DKIM success as a repair.

Nothing arrives. Check that the selected transport is not Null, that a real send occurred and that queue/provider diagnostics identify the delivery attempt. Do not change DNS until the actual failing layer is established.

Official sources

• Admin Quick Start: native Cloud transport, domain permission/key request, SPF and sender setup.
• Cerb Cloud: managed service and provider-domain versus customer-domain support.
• Mail Transports: route types and per-sender selection.
• Sender Addresses: visible From identities.
• Test mail deliverability: native ticket test path.

These current public pages do not establish publication/update dates or universal DKIM records. Obtain the current customer-specific packet before making a change.