Start with the current domain setup
Get a Newsletter's help article describes a newer setup that replaced its older selector and root-SPF instructions. Use the current sending-domain configuration rather than combining every record found in past onboarding messages. The provider changed the arrangement in January 2023 so customers no longer need to add its old include to their own SPF record for this setup.
Before making changes, identify the From domain used by the newsletter, the account owner and the authoritative DNS host. Inventory existing records at the requested names. Confirm that you control the domain and that the sending address is appropriate for the campaign. A free mailbox domain you do not administer cannot be configured by adding records somewhere else.
The goal is to verify the actual newsletter route. The organization may also send employee mail, invoices or application notifications using the same parent domain. Those routes keep their own authentication requirements; onboarding this newsletter service is not a reason to erase their SPF permissions.
Publish the documented CNAME set
The current help page lists three CNAMEs: gan1._domainkey to gan1._domainkey.gansend.com, gan2._domainkey to gan2._domainkey.gansend.com, and gan to mta.gansend.com. Confirm these against the current account and provider instructions before publication. Use the DNS editor's relative-name rules and preserve the exact target domain names.
The two _domainkey entries are selector lookups; the third is a separate namespace used by the newer setup. Do not place all three at one owner, create TXT keys in place of the documented aliases or place a CNAME beside conflicting records. If gan already serves another application, pause and resolve the collision with the provider rather than silently displacing it.
For a synthetic example.com domain, gan1._domainkey is intended to publish at gan1._domainkey.example.com. An editor that appends the zone automatically must not receive a name that becomes gan1._domainkey.example.com.example.com. Write down the intended complete names before saving, then query those names afterward.
Do not reintroduce the retired SPF recipe
The help page identifies the older getanewsletter._domainkey configuration and the former include:spf.gansend.com instruction. These are historical context, not instructions to add them alongside the new setup. Do not use an old blog or copied checklist to override the provider's current configuration.
Equally, do not delete an existing record without understanding its remaining use. Retiring an old selector requires confirming that no active messages still depend on it. Removing an SPF include requires reviewing the complete policy and the service's current route. Preserve every unrelated legitimate sender and the policy's intended final behavior.
The protocol reason is straightforward: SPF evaluates the SMTP envelope domain. Adding an include to a different visible-From domain does not automatically change that evaluation. DKIM and SPF alignment must be assessed from actual message identities, not inferred from the presence of the provider name in a root TXT record.
Validate in the account and in DNS
The documented account route is the profile icon, Sender, View Details and Check status. The help article suggests checking after an hour. Treat that as operational guidance rather than a guarantee that every resolver has discarded older data. First confirm the authoritative records are correct; waiting cannot fix an incorrectly entered label.
Query each CNAME owner at the authoritative DNS service and check its target. Follow the relevant resolution path when diagnosing a key lookup. Preserve the answers and timestamps without claiming a successful newsletter delivery from DNS alone. If a CNAME target resolves but the account still fails validation, compare the exact domain entered in the account and the actual published owner.
A successful status check establishes the setup check performed by the service. It is not proof that every campaign From address uses the same authenticated domain. Record each sending identity that the campaign owner intends to use and verify representative messages from the real route.
Prove alignment with a received newsletter
Send a controlled newsletter to an authorized test recipient and retain the raw message. Record From, envelope domain, DKIM signing domains and selectors, and the trusted receiver's SPF, DKIM and DMARC results. Do not treat the sender's own inserted Authentication-Results as receiver evidence.
Synthetic interpretation: From is news@example.com, the envelope uses a subdomain of example.com, and a valid DKIM signature uses d=example.com. The exact DKIM domain aligns. The envelope subdomain can satisfy relaxed SPF alignment but not strict exact matching against example.com. This example is not a measurement of Get a Newsletter's default envelope or selector use; inspect the real message rather than filling in an expected answer.
If only a provider-owned DKIM domain passes, investigate whether the custom-domain setup is active for that sender. If the expected selector is missing, compare the account's sender-domain configuration and the message route. If aligned authentication passes but spam placement persists, assess reputation, consent, content and recipient filtering separately.
Preserve recovery and evidence
Keep the previous records, new approved values and the point at which the campaign owner may resume sending. Pause a failing campaign rather than weakening the entire organization's DMARC policy. If reverting, restore only the affected configuration after checking whether signing has already changed. Record the result of the first message after recovery.
This guide retains first-party instructions and provides synthetic DNS and identity reasoning. No account validation, DNS change, delivered campaign or tenant measurement was performed. Production acceptance requires the administrator's authoritative answers and received-message evidence, followed by the responsible human owner's decision.
Resolve an occupied gan name without breaking another service
Written case GAN-01 assumes the planned From is news@example.com, the two gan1/gan2 selector names are unused, but gan.example.com already has an A record owned by an unrelated application. The current three-CNAME setup cannot be completed at that occupied name without a conflict. Leave the application intact and ask the newsletter account owner and DNS administrator to resolve a supported namespace plan with the provider. No custom-domain verdict is available: envelope and DKIM results remain unknown. Do not infer an alternative label or restore the retired root-SPF recipe. This is a fictional collision, not an executed lookup, support request or campaign.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.