Authenticate Get a Newsletter with its current three-CNAME setup, not the old root-domain SPF include. Publish the two DKIM aliases and the gan subdomain alias for your sending domain, then check the sender's status in Get a Newsletter. The provider changed this workflow on January 26, 2023. A delivered newsletter must still demonstrate that your intended domain signs successfully and aligns with the visible From address. Current Get a Newsletter instructions.
What this setup covers
This guide covers newsletters sent through Get a Newsletter using a domain your organization controls. It does not configure employee mailboxes, migrate incoming email or authorize a different application's mail servers. Repeat the checks for every sending domain, including a newsletter subdomain if you use one.
Before making changes, record:
- The exact From address selected for the newsletter, such as
news@example.com. - The Get a Newsletter account and sender entry that will use it.
- The DNS zone containing that domain and the administrator authorized to edit it.
- Existing SPF, DKIM and DMARC records, including other services' selectors.
- Any existing use of the
ganhostname, because a conflicting CNAME cannot safely replace it without investigation.
An address at a public mailbox service does not give you control of that service's DNS. Use an owned domain for branded authentication. The examples below use example.com; substitute your actual sending domain, not the provider's domain.
The DNS records Get a Newsletter currently documents
For a sender at example.com, the current public instructions specify:
| Purpose | Relative name in the example.com zone | Full DNS owner | Type | Target |
|---|---|---|---|---|
| First DKIM selector | gan1._domainkey |
gan1._domainkey.example.com |
CNAME | gan1._domainkey.gansend.com |
| Second DKIM selector | gan2._domainkey |
gan2._domainkey.example.com |
CNAME | gan2._domainkey.gansend.com |
| Branded return-path subdomain | gan |
gan.example.com |
CNAME | mta.gansend.com |
These are the provider's documented shared targets, not invented customer keys. Compare them with the instructions associated with your sender before publishing. If your account supplies a different configuration, resolve that difference with Support rather than mixing old and new records. Official DNS values and verification steps.
The two _domainkey names make Get a Newsletter's public signing keys discoverable. Do not generate your own DKIM key pair for this hosted workflow or paste a private key into DNS. The gan record serves a different purpose: it allows a branded envelope identity while the provider manages the associated infrastructure.
Sending from a subdomain
If your From address is updates@news.example.com, make sure Get a Newsletter has configured that exact sending domain. The full owners would be under news.example.com, for example gan1._domainkey.news.example.com, when that is the domain being authenticated.
In the parent example.com zone the relative name would be gan1._domainkey.news; in a separately delegated news.example.com zone it would be gan1._domainkey. Both describe the same full owner. Do not add records under the parent merely because the organization owns it, or assume parent-domain signing satisfies a strict subdomain policy.
If _domainkey.news.example.com is already separately delegated, publish gan1 and gan2 as relative owner labels at that authority for the corresponding full selector names. Preserve its NS delegation and unrelated selectors, using the documented current CNAME targets. Relative DNS names.
Why you should not add include:spf.gansend.com
Get a Newsletter explicitly says its old include:spf.gansend.com instruction is no longer needed for the setup introduced in January 2023. Its branded subdomain arrangement lets the provider manage SPF. Older articles showing the include predate that change. Provider explanation of the changed SPF workflow.
SPF evaluates the SMTP envelope MAIL FROM domain, normally reflected in Return-Path and reported as smtp.mailfrom by the receiver. It does not evaluate the visible From address just because that is what the recipient sees. Adding an include to example.com does not change the SPF policy evaluated for a different envelope domain. SPF identity and evaluation rules.
Keep the organization's existing SPF policy for its other senders. Do not replace it with a Get a Newsletter-only policy, create a second v=spf1 record, or publish a TXT record at gan.example.com alongside its CNAME. A CNAME owner cannot also contain ordinary TXT, A or MX data.
If the obsolete include is already present, make its removal a separate, reviewed cleanup. First confirm that all relevant Get a Newsletter senders have migrated and that no active legacy path depends on it. Retain all unrelated authorizations and the existing terminal qualifier. A DNS entry being old is not evidence that every account has stopped using it.
Publish safely in the authoritative DNS zone
Find which nameservers actually serve the domain before editing. The registrar, website host and DNS host may be different companies. An edit in an inactive DNS panel will not be visible to receiving mail systems.
- Export or record the current zone values and TTLs so the exact change can be reversed.
- Compare each proposed full owner against existing records. Stop on a collision instead of deleting the existing record.
- Add the three CNAMEs using the field format your DNS host expects.
- Check whether the host appends the zone name automatically. Avoid names such as
gan1._domainkey.example.com.example.com. - Enter targets as hostnames, without
https://, paths or smart quotation marks. Some DNS systems require a final dot to prevent a target from being treated as relative. - Where the host has a web-proxy option, keep these authentication aliases DNS-only. Do not substitute a web redirect or flatten the requested CNAME into website address records. Cloudflare guidance on DNS-only, unflattened verification CNAMEs.
- Leave incoming-mail MX records, other DKIM selectors, domain-verification TXT records and existing DMARC policy intact.
Do not move nameservers or transfer your domain simply to add these records. If gan is already used by another application, ask Get a Newsletter to confirm a supported alternative before changing either service.
Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.
Check public DNS, then check the sender in the account
The commands below are read-only examples for the example.com setup. Replace that example everywhere before running them. They show the queries to make, not successful results from a tested customer domain.
dig +short NS example.com
dig +short CNAME gan1._domainkey.example.com
dig +short CNAME gan2._domainkey.example.com
dig +short CNAME gan.example.com
dig +short TXT gan1._domainkey.example.com
dig +short TXT gan2._domainkey.example.com
dig +short TXT gan.example.com
dig +short TXT _dmarc.example.com
The CNAME answers should match the table. Recursive TXT lookups should follow the aliases to provider-managed records: usable public-key data for DKIM and an SPF policy for the envelope alias. A displayed CNAME alone does not prove that the target serves valid authentication data.
To separate a publication mistake from caching, query an authoritative nameserver returned by the NS lookup. Replace ns1.dns-host.example with a real authoritative server:
dig @ns1.dns-host.example gan1._domainkey.example.com CNAME +noall +answer
dig @ns1.dns-host.example gan2._domainkey.example.com CNAME +noall +answer
dig @ns1.dns-host.example gan.example.com CNAME +noall +answer
For a delegated subdomain, use its authoritative zone, not an assumed parent nameserver. Compare authoritative answers with an independent recursive resolver. If both return the wrong owner or target, waiting will not repair the configuration. If the authoritative answer is correct but a recursive cache is older, allow the relevant TTL and negative-cache lifetime to expire.
Get a Newsletter's documented check is available from the profile icon, Sender, View Details, then Check status. Its guide suggests checking after one hour. Treat that as a checking interval, not a guaranteed propagation deadline. Resolve any reported problem for the exact sender you will use. Account verification workflow.
Keep DMARC policy and reporting separate from record publication
DMARC compares the visible From domain with a successfully authenticated SPF or DKIM domain. Either aligned mechanism can produce a DMARC pass. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. For example, gan.example.com and example.com can align under relaxed SPF alignment but do not match under aspf=s. A passing customer-domain DKIM signature can still provide alignment. DMARC alignment requirements.
Preserve any existing DMARC policy, including p=quarantine or p=reject, reporting destinations and alignment settings. Do not weaken it to hide a failing newsletter configuration. Check the applicable parent policy when sending from a subdomain; absence of a record directly at that subdomain does not necessarily mean no DMARC policy applies.
For a domain with no established applicable policy, a monitored rollout may begin with a record such as the following. This is an example, not an instruction to replace an existing policy:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Use a real reporting destination your organization controls or an authorized reporting service. An external report receiver may need to publish authorization before reports can be sent there. Review aggregate results by source, From domain and alignment before increasing enforcement. p=none requests no DMARC-specific enforcement; it does not guarantee inbox delivery. DMARC aggregate reporting.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.
Prove the setup with a delivered newsletter
After the account and DNS checks succeed, have an authorized operator send a representative newsletter to controlled external test inboxes. Use the actual sending domain and production route. A message sent from an employee mailbox does not test Get a Newsletter.
Inspect the original message and the receiving mailbox system's trusted Authentication-Results, rather than a result supplied by the sender or copied from a forwarded message. Authentication-Results trust model.
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
Record these observations:
| Evidence | Acceptance criterion |
|---|---|
Visible From: |
The intended customer address and domain are present |
DKIM-Signature and receiver DKIM result |
The intended branded signature passes, and its d= aligns with From under the applicable adkim mode |
| DKIM selector | The passing signature's s= resolves through the correct published selector; do not assume both selectors sign every message |
SPF result and smtp.mailfrom |
SPF passes for the actual envelope domain; record whether it aligns under aspf |
| Branded envelope behavior | The expected customer-domain return path is active, rather than an unnoticed provider fallback |
| DMARC result | The receiver reports a pass for the intended From domain |
A passing provider-owned DKIM signature alone does not establish branded DKIM. Likewise, DMARC passing through SPF alone does not demonstrate that your new DKIM configuration works. Do not call this setup complete until the intended branded DKIM signature both passes and aligns.
If SPF passes but is unaligned, investigate the envelope identity and strict-versus-relaxed setting. If SPF reports fail, softfail, none, permerror or temperror, investigate the actual cause even if DKIM allows DMARC to pass. In particular, a provider-controlled envelope failure belongs with Get a Newsletter Support, with the sending time, message identifier and sanitized receiver diagnostics. Adding an old include to the root cannot fix a policy evaluated elsewhere.
Distinguish authorization fail or softfail from transient evaluation temperror and invalid-policy/duplicate/lookup-limit permerror at the actual envelope identity. Do not repair provider-owned policy by editing a different apex. SPF results.
Troubleshooting Get a Newsletter authentication
Only the old DKIM selector exists
The official guide identifies getanewsletter._domainkey pointing to key1._domainkey.gansend.com as the earlier setup. Compare your sender with the current three-record workflow. Do not delete a still-used legacy selector until the migration and any queued mail have been accounted for. Legacy and current record comparison.
Check status fails even though the DNS panel looks correct
Query the full owners publicly. Common causes include editing the wrong nameservers, a duplicated domain suffix, a missing second selector, a proxied alias or an existing record occupying gan. If authoritative answers are correct, distinguish a cached result from an account association problem.
DKIM passes, but DMARC fails
Read the passing signature's d=. It may belong to the provider or a different customer subdomain. Compare it with the visible From domain under the published alignment mode. Do not confuse DKIM's signature-canonicalization settings with DMARC alignment. See strict and relaxed DMARC alignment.
SPF reports a permanent error
Inspect the envelope domain's policy, including duplicate SPF records, syntax and recursive lookup-causing terms. SPF permits at most ten such terms during evaluation, including nested includes. Do not count only the visible includes or flatten provider addresses into an unmanaged list. See diagnosing SPF permerror.
Everything passes, but newsletters still go to spam
Authentication is one input to mailbox decisions. Investigate recipient consent, complaints, engagement, bounce handling and message content separately. Keep an example message and receiver diagnostics; do not weaken DMARC or add random SPF mechanisms to chase inbox placement.
Verification note
This guide is based on public provider documentation and email-authentication standards. No customer account was configured, no DNS records were changed and no newsletter was sent or delivery result measured during preparation. Validate your account's current values and actual delivered messages before relying on the configuration.