Cadmium EdgeReg SPF, DKIM and DMARC setup, step by step

For the legacy EdgeReg interface, Cadmium documents a native Domain Authentication workflow that creates a domain entry, emails its DNS instructions to an IT contact and provides a Verify button. Use that account-specific packet rather than guessing SPF includes, DKIM selectors or SendGrid targets. This guide covers that workflow and the checks needed before calling branded sending successful.

Scope: the EdgeReg route documented in Cadmium's Eventscribe support center, associated with the EventRebels legacy product. It is not a universal recipe for every current Eventscribe product. The EventRebels website redirects to Cadmium Eventscribe; this does not prove that every existing customer's account has migrated to the same interface. No account, DNS or sending test was performed.

Confirm which setup route your account uses

The relevant official article explicitly names EdgeReg and starts from the myCadmium events list. If your account does not expose the controls below, stop and obtain instructions for your actual product and route rather than improvising an equivalent menu.

There is also a newer, separate Cadmium-wide workflow: the organization supplies its sending domains and an authorized contact; Cadmium initializes them and SendGrid emails that contact the instructions. That article recommends spf.gocadmium.com as an optional SPF addition. It does not establish that all legacy EdgeReg tenants should apply the same change. Do not combine recipes merely because both products belong to Cadmium. Cadmium custom-email-domain guidance.

Before proceeding, have the account and DNS owners agree on the actual sending address, the domain used by that address, the intended recipients of setup instructions and the message stream being configured. Access to myCadmium does not automatically grant permission to edit the organization's DNS.

Request the EdgeReg DNS packet

In the documented EdgeReg interface:

1. Open your event list in myCadmium and launch EdgeReg.
2. At the bottom of the EdgeReg home page, select Domain Authentication under Admin.
3. Select Add Domain, enter the domain of the intended sender address, and choose Create. For an illustrative address registration@mail.example.com, the domain is mail.example.com, not the entire email address.
4. On the Validation Pending page, open Share With Co-Worker.
5. Enter the authorized IT contact's email address, review the message and use Send Email to deliver the setup packet.

That last action sends a real external email; verify its recipient before taking it. This article describes the workflow but has not sent anything. The provider's instructions then direct you back to the Domain Authentication page to use Verify after the DNS installation. Official EdgeReg authentication instructions.

Review the packet before editing DNS

Keep the full issued record type, owner and value for every entry. The public EdgeReg instructions do not publish universal selectors, record counts, key values, Return-Path names or an extra signing-activation switch. Do not manufacture them. If the email is incomplete, ask Cadmium for the missing information and whether any account-side completion is required after verification.

Check that the packet belongs to the requested domain and actual EdgeReg account. A familiar sender logo is not sufficient: confirm unexpected setup mail through the established account/support route. Never provide DNS login credentials, API secrets or DKIM private keys in a reply.

For each record, establish who controls the authoritative DNS zone. A domain registrar, website host and DNS host may be different organizations. Preserve the pre-change values and note any shared selectors or delegations. If the packet unexpectedly requires an MX, address, forwarding destination or nameserver change, do not treat it as harmless authentication metadata: reconcile its effect with the approved routing plan before proceeding.

Publish the exact owners and record types

The examples below explain DNS naming only. They are not EdgeReg-issued values and should not be pasted into a production zone.

If _domainkey.mail.example.com is separately delegated, the first owner is selector within that namespace. Respect the existing delegation and its administrator; do not delete its NS records to force a new entry into the parent zone. Providers differ on accepting full names or automatically appending the zone, so check the final published owner for duplicated suffixes.

If the packet supplies a TXT DKIM record, retain the complete tagged public record, including its full p= value. Do not copy a shortened screenshot or only one fragment of a split display. If it supplies a CNAME, preserve its exact alias and target instead of converting it to TXT. DNS publication and signing activation are different operations. DKIM DNS lookup and key records, RFC 6376.

At a CNAME owner, do not add another CNAME or conflicting TXT, A, AAAA or MX data. Use DNS-only behavior rather than an HTTP proxy. Where the issued workflow needs literal CNAME answers, turn off an applicable per-record flattening control if available and check whether whole-zone, apex or same-zone behavior still hides the alias. Do not disable unrelated settings globally. If mandatory DNS-host behavior cannot preserve the required answer, stop and coordinate a supported arrangement. These are conditional CNAME safeguards, not a claim that every EdgeReg packet uses CNAMEs. CNAME behavior, RFC 1034.

Handle SPF without replacing your organization's policy

SPF checks the actual SMTP MAIL FROM domain, or the relevant HELO identity for a null reverse path. The visible From alone does not identify the SPF owner. Ask which envelope identity the configured route will use; do not assume a fixed Return-Path or paste a new apex policy just because a setup email mentions authentication.

If the approved packet requires a customer-owned SPF change, maintain one v=spf1 TXT policy at the evaluated owner. Preserve legitimate existing senders, qualifiers and shared dependencies. The limit is ten evaluated DNS-dependent terms, including nested mechanisms, not simply ten includes. An all mechanism makes redirect ineffective. No qualifier guarantees how every receiver handles the message. SPF evaluation and DNS limits, RFC 7208.

The optional SPF recommendation in the newer Cadmium-wide article is not a substitute for confirming the legacy EdgeReg route. If instructions conflict, resolve the account-specific applicability with Cadmium before changing DNS.

Preserve DMARC protection

Keep existing direct and inherited DMARC policies and authorized report destinations. Do not replace a working policy with p=none merely to troubleshoot EdgeReg. DKIM signing should align with the intended visible From under the existing policy.

If there is no direct or applicable inherited policy and the domain owner approves a first monitoring policy, an illustrative TXT value is:

v=DMARC1; p=none

Publish it at the appropriate _dmarc owner, using the owner mapping above; do not duplicate an existing DMARC record. This no-report example requests no aggregate reports. Monitoring needs a separately approved observation/reporting plan and later policy review; it is not a completed enforcement strategy. Current DMARC standard, RFC 9989.

If aggregate reporting is added, compare the report destination's Organizational Domain with the policy domain's Organizational Domain. A different Organizational Domain requires the report-generating receiver to check DNS authorization; a destination within the same Organizational Domain is excepted. Different hostnames alone do not settle that comparison. RFC 9990 section 4. That protocol check is separate from the owner's approval to share report data. Do not copy a third party's reporting address from an example.

Verify in EdgeReg, then verify a real message

After the issued DNS records are published and resolvable, return to Domain Authentication and select Verify. Preserve the actual result and investigate missing or incorrect owners/values before repeatedly retrying. A provider validation result establishes only what its check tests; it does not demonstrate every delivered message's intended signature and alignment.

For the documented legacy e-Marketing route, the meeting's Control Center > Communications > e-Marketing leads to the e-Marketing Plan tab. Its Schedule option selects a mailing list; Create Custom Registration Mailing targets registrants. For an approved test, use a dedicated list containing only controlled recipients, not the live registration list. Review the selected message and recipients: a default Condition of None means the entire selected list, and a blank sending time can mean immediate sending. Do not disable duplicate protection simply to repeat a test. Official sending workflow.

Use harmless test content and inspect the original message at the receiving service. Record the visible From, the SPF-evaluated envelope domain, and the intended DKIM signature's d= domain and s= selector. Use Authentication-Results generated within that receiver's known processing boundary, following its documented treatment of externally supplied result fields. Header position or a familiar authserv-id string alone does not prove trust; ignore attacker-inserted results. RFC 8601 security considerations.

For branded DKIM acceptance, require the intended provider signature to pass and align with the intended From, plus a trusted dmarc=pass. A provider-domain From rewrite is not successful brand authentication. A DMARC pass through SPF alone does not prove DKIM works. See EmailAuth's raw versus aligned DKIM explanation.

Relaxed alignment permits the same Organizational Domain; strict alignment requires an exact domain match. Under RFC 9989, the Organizational Domain is found through the DMARC DNS Tree Walk rather than automatically taking the last two labels or a public-suffix-list result. Record the actual identities rather than assuming strict alignment from a related subdomain.

Troubleshooting and completion evidence

Retain the provider packet, approved DNS changes, EdgeReg verification result and trusted received-message results. Keep unresolved gaps visible, even if DKIM allows DMARC to pass while SPF remains faulty. Repeat controlled checks for other intended production paths, not just one e-Marketing message. Do not change MX, parent nameservers, DNSSEC, credentials or security filters simply to match a tutorial.

Common questions

Can I reuse the same record values for another event or domain?

Only if the actual account instructions establish that scope. Reuse must not be inferred from shared Cadmium branding.

Is Verify proof of inbox placement?

No. Authentication, recipient filtering and actual delivery are separate. Inspect the received message; no guide can guarantee inbox placement.

What if I have the newer Eventscribe interface?

Use the setup instructions for that actual product. This guide deliberately preserves the legacy EdgeReg workflow rather than pretending its menus apply everywhere.