Soft Edge SPF, DKIM and DMARC setup, step by step

Congress Plus domain authentication requires DNS publication followed by Soft Edge's account-side completion. Its official instructions publish three CNAME records and require a support follow-up; creating DNS records alone does not finish setup. Use the intended From domain, preserve existing mail services and DMARC protection, then verify an actual received message. [1]

This guide is based on provider documentation and current email standards. It is not a customer-account, DNS-deployment or live-delivery test.

Scope and prerequisites

This is for The Soft Edge's Congress Plus sending route, including grassroots-contact and advocacy thank-you mail described in its instructions. Do not apply it to an unrelated product merely because that product also sends advocacy email. [1][2]

Before starting, have an authorized Congress Plus administrator and the administrator of the relevant authoritative DNS zone agree the sending domains and rollout. Establish which campaign or automated message will provide a safe test. Do not send test advocacy messages to legislators, supporters or real customer lists; use a controlled recipient and approved isolated workflow.

Record existing DNS values, the intended visible From domain and applicable DMARC policy, including inherited protection. Check whether the three proposed owner names already exist. If any name is already used by another service, stop and agree a resolution rather than overwriting it. Keep a record of the approved changes and rollback conditions.

The registrar selling the domain is not necessarily the service hosting authoritative DNS. Make changes in the zone actually delegated for the relevant owner. No MX, parent-nameserver, DNSSEC or credential change is implied by outgoing authentication setup.

Publish the documented CNAME records

The provider lists these records for domains used in Congress Plus From addresses. The relative names and targets below come from its published instructions, not a generated tenant key. Confirm that this route applies to your account before publication. [1]

Do not replace these CNAMEs with a guessed SPF TXT policy or independently generated DKIM key. The tse label is part of this provider's published configuration; it does not establish which signature or envelope identity a particular message actually used. Inspect that message after account completion.

Map the owners into the correct zone

Suppose the approved From domain is example.com. The full owners would be:

tsemail.example.com
tse._domainkey.example.com
tse._domainkey.tsemail.example.com

These are illustrative names using a reserved example domain, not values to deploy. Replace the domain with the approved one. If your DNS editor appends the example.com zone suffix, enter the relative owners shown in the table. Do not accidentally create tsemail.example.com.example.com.

For a From domain of mail.example.com, the first full owner is tsemail.mail.example.com. In the parent example.com zone, that is normally entered as tsemail.mail; in a separately delegated mail.example.com zone, it is normally tsemail. The DKIM owner tse._domainkey.mail.example.com similarly becomes tse._domainkey.mail in the parent zone or tse._domainkey in that child zone. If _domainkey.mail.example.com is separately delegated, its administrator would handle the relative owner tse. Verify your editor's actual suffix behavior and preserve existing delegations.

A trailing dot denotes an absolute DNS name. Some DNS editors add or normalize it automatically. Confirm that the published target is the intended provider name, not the provider name with your zone appended.

Avoid CNAME conflicts, proxying and flattening

A CNAME owner cannot also hold conflicting TXT, A, AAAA, MX or another CNAME data set. Do not delete existing records simply to make a form accept a new value. [3]

Authentication CNAMEs should remain DNS-only, not HTTP-proxied. If the DNS host offers per-record CNAME flattening, disable it for these records when needed to preserve the literal CNAME response. Also assess zone-wide, apex and same-zone flattening behavior: one per-record switch may not override those rules. If mandatory behavior prevents the required CNAME answer, stop and obtain a provider-approved alternative rather than changing unrelated zone settings.

These are mail-authentication aliases, not a request to proxy a website through a CDN. Check the actual answers after saving, with the authoritative zone and appropriate recursive resolution; a dashboard entry alone is not sufficient.

Preserve SPF and DMARC rather than replacing them

SPF evaluates the SMTP MAIL FROM identity, or HELO in the relevant null-reverse-path case. It does not automatically evaluate the visible From domain. The provider's CNAME recipe does not justify adding an invented include:congressplus.com to your apex SPF or assuming a fixed Return-Path for every message. Obtain account-specific clarification if the observed envelope route differs from the expected configuration. [4]

If another approved change genuinely requires editing an SPF TXT policy, keep only one policy at that evaluated owner and retain existing legitimate authorizations and qualifiers. Check the limit of ten evaluated DNS-dependent terms, including nested evaluation. Do not confuse this with ten total DNS records or ten includes. An all mechanism makes a redirect modifier ineffective. [4]

The source also gives a first-time monitoring DMARC example. Do not use it to downgrade an existing direct or inherited enforcement policy. [1][5] Only if no applicable policy exists, the domain owner approves and a monitoring plan is in place, the minimal example is:

Type: TXT
Owner: _dmarc.example.com
Value: v=DMARC1; p=none;

For an editor appending the example.com zone, the relative owner is _dmarc. For a sending subdomain mail.example.com, the full owner is _dmarc.mail.example.com: enter _dmarc.mail in the parent example.com zone or _dmarc in a separately delegated mail.example.com zone when the editor appends that zone suffix. Evaluate the relevant direct and inherited policies before adding either. Do not create duplicate DMARC policies or infer that p=none protects against spoofing. The minimal record contains no reporting destination; it does not, on its own, arrange aggregate-report collection.

Any added reporting destination requires an approved privacy and monitoring plan. When the destination's Organizational Domain differs from the Organizational Domain of the discovered DMARC policy domain, the report-generating receiver must check the required DNS authorization. Destinations within the same Organizational Domain are excepted. That protocol check does not replace authorization to share the data. [6]

Ask Soft Edge to complete the account setup

After the DNS administrator confirms publication, the provider directs customers to notify Soft Edge support, identifying the domains. Its published contact is info@thesoftedge.com, with subject Email authentication setup. It states a 1–2 business-day confirmation/completion interval or follow-up on problems. That is the provider's stated process, not a guaranteed completion time from EmailAuth. [1]

Send only the information needed for the authorized request. Do not include account passwords, private keys or customer recipient lists. Track three separate stages:

1. The required DNS records are published correctly.
2. Soft Edge confirms its account-side setup is complete.
3. A controlled message demonstrates the intended identity and authentication results.

Do not declare success at stage one. If provider confirmation is pending or reports a problem, keep the rollout pending rather than weakening DMARC to permit unverified traffic.

Verify SPF, intended DKIM and DMARC in received mail

Use the approved message workflow and a controlled valid recipient. Preserve a minimal test record: message type, From address, timestamp, message identifier and results. Do not expose raw headers or recipient data publicly.

Use only authentication results generated within a known receiving processing boundary. Your receiving administrator should establish its documented handling of external Authentication-Results headers, such as stripping or segregating untrusted input. A familiar authserv-id or a header's position alone cannot prove a result is trustworthy. [7]

Check the actual envelope domain and SPF result. For each relevant DKIM signature, keep the d= signing domain, s= selector and verification result together. Compare the authenticated identity with the intended visible From domain: relaxed alignment requires the same Organizational Domain, while strict alignment requires the exact same domain under the applicable aspf or adkim mode. [4][5]

For the branded DKIM route, require the intended provider DKIM signature to pass and align with the intended From, plus a trusted receiver dmarc=pass. A passing unrelated signature is insufficient; a DMARC pass supplied only by SPF does not prove intended DKIM signing works. A provider-domain From rewrite is not successful organization-domain authentication.

See raw DKIM results versus aligned DKIM policy results for the distinction. DNS resolution is not proof of live signing, and authentication success guarantees neither inbox placement nor safe content.

Troubleshooting without weakening protection

Diagnose SPF errors even when aligned DKIM supplies a DMARC pass. If a new configuration causes trouble, coordinate rollback with the service owner and provider; remove only newly introduced records confirmed to have no shared dependency. Do not disable an existing signing route or remove old selectors while queued messages may still need them.

Sources

1. Congress Plus: Updated Email Authentication Requirements. Full operative body reviewed; published records and support completion procedure.
2. The Soft Edge. Provider/product identity and Congress Plus context; not a configuration source.
3. RFC 1034, section 3.6.2. CNAME constraints.
4. RFC 7208. SPF identities, policy evaluation and limits.
5. RFC 9989. Current DMARC alignment and policy behavior.
6. RFC 9990, section 4. Aggregate-report destination authorization.
7. RFC 8601. Authentication-result trust boundaries.