Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Select the domain the campaign will actually use
Before opening DNS, record the GreenRope campaign or group, its selected sending address and the domain owner. A company may use one domain for staff mail and another for campaigns. Authenticate the domain that appears in the intended message rather than assuming that configuring the corporate apex covers every choice in the CRM.
GreenRope publishes an SPF include of include:_spf.stgi.net and a DKIM CNAME owner of kesq._domainkey pointing to dkim.stgi.net. Confirm these against the current provider instructions and the account's domain check before publication. These are documented provider values, not invented customer records. GreenRope setup
Publish without removing existing authorization
References: RFC 7208 §3.2, RFC 7208 §4.6.4, RFC 1034 §3.6.2.
If SPF already exists at the relevant owner, insert the approved include before the terminal all mechanism while preserving other legitimate senders. Publish only one SPF policy there. Apply the ten-term SPF limit to evaluated include, a, mx, ptr, exists and redirect terms, including nested processing. This limit is not a raw DNS-packet count. A change that makes the policy exceed the protocol limit is not a successful installation.
For DKIM, compare the full selector owner with existing data. A CNAME cannot simply be added beside a TXT key at the same name. Establish who uses any existing selector before replacing it. Use the DNS host's owner-name convention so the domain is not appended twice, and retain the exact published target rather than an IP address copied from a lookup.
GreenRope's setup article provides a domain check through its DKIM/SPF control. Use that check after saving records and retain the result. Its sample DMARC record should not be copied wholesale into an existing domain policy. Review DMARC separately with the domain owner, choose an authorized reporting destination and preserve existing enforcement unless a deliberate policy change is approved. Provider verification instructions
Configure the custom MTA separately
References: RFC 9989 §4.4.
The current provider article also documents a custom MTA setting. In Communicate > Email, open MTA beside the From field, enter an approved subdomain in New MTA and add it. After refresh, use setup beneath that entry to obtain its account-specific CNAME target. Publish that record and inspect the MTA verification indicator. Do not reuse the DKIM CNAME target for this different purpose.
A custom bounce identity can support SPF alignment, but a subdomain is not an exact match to the parent From domain under strict alignment. Inspect actual identities and valid aligned DKIM as an independent path. Do not repeat the source’s blanket suggestion that DMARC is optional as a recipient-policy exemption, or copy its sample reporting destinations.
Establish evidence for the selected sender
References: RFC 9989 §5.3.5.
Original acceptance procedure: send a harmless campaign example to controlled recipients using the exact account sender intended for release. Capture the visible From domain, SMTP envelope identity, DKIM signing domain and selector, and trusted receiver-added SPF, DKIM and DMARC results. The key question is whether a passing authentication identity aligns with From under the applicable policy. An unrelated passing signature does not answer that question.
Save the account check and the message check as separate rows. If the DNS check is green but the message uses a different sender domain, correct the campaign selection or authenticate that intended domain. Do not add more includes to the first domain as a substitute for tracing the message.
Illustrative case: a team completes DNS for its main domain but launches a campaign using a newly introduced events subdomain. The investigation starts with the actual From and signing identities. Whether they align depends on the observed domains and policy mode; the administrator must not infer strict alignment from shared branding.
Keep the campaign recoverable
Before launch, retain the prior sender choice and DNS values and name the person who can pause the affected campaign. If the test fails, identify whether the cause is owner-name publication, selector conflict, SPF evaluation or sender selection. Correct one layer at a time and repeat the controlled message test. Do not downgrade a domain-wide policy to get a campaign out on schedule.
Recheck after a sender-domain change, DNS migration or CRM account reconfiguration. Documentation was reviewed on 8 November 2026. No GreenRope account, public DNS zone or delivered campaign was tested; the acceptance procedure and scenario are illustrative.