Provider documentation checked on 8 November 2026. Account-generated values and current product support remain deployment prerequisites.
AcyMailing can be the application composing the newsletter without being the server delivering it. That distinction decides which authentication instructions apply. This guide covers AcyMailing, with separate paths for its sending service and a server or SMTP supplier selected in the installation.
Start with the transport, not the plugin name
Record the installed version, configured sending method and visible From address. For the AcyMailing sending service, the current documentation describes entering the applicable license in configuration, selecting the service, adding the owned From domain and retrieving its generated DNS entries. It describes three CNAME entries and an Update domains statuses action. Publish the records shown for your domain, not the placeholder targets in an example. Sending-service activation
Use only a domain your organization controls. A consumer mailbox address does not authorize changing that mailbox provider's domain. If an address is changed after verification, re-evaluate the actual sending domain rather than assuming the old configuration applies.
Keep the server-signing path separate
References: RFC 6376 §3.3, RFC 6376 §3.6.2.
AcyMailing's separate DKIM configuration guide recommends using the mail server or SMTP supplier's DKIM when that route already supports it, rather than also enabling the application's DKIM option. For an installation using AcyMailing's own DKIM option, the guide describes generated keys, the public TXT value in DNS and a private key used by the application. The cited application-signing guide lists AcyMailing Enterprise as a prerequisite. Confirm current edition and version support in the installation before taking this path. AcyMailing DKIM configuration
Never publish a private key in DNS. A DKIM signature authenticates selected message content with a public-key verification process; it does not encrypt the newsletter or guarantee delivery. The application's own TXT-key workflow and the hosted sending service's generated CNAME workflow are different setups, not extra records to stack blindly.
Diagnose DNS expansion mistakes
The sending-service documentation specifically describes a DNS editor appending the domain to a CNAME target. Check the resulting public name and target, not just what was typed. An intended vendor target that becomes vendor-target.example.com points somewhere else. Use your DNS host's required absolute-name syntax, including a trailing dot when required, and avoid duplicating the zone suffix in the owner name.
For the hosted sending service, the troubleshooting section separately directs customers needing aligned MAIL FROM to support for two domain-specific DNS entries. The three initial CNAMEs should not be presented as a universal guarantee of aligned SPF.
Original operator checklist: save the issued records, query each authoritative name, refresh the provider status and only then send a test through the selected transport. Do not authorize every possible SMTP service in SPF just because the plugin offers several options.
Verify the selected route and recover
References: RFC 9989 §4.4.
Illustrative comparison: the website initially sends through the AcyMailing service and later switches to an external SMTP relay. The original CNAMEs may remain visible, but they no longer prove which system signs new messages. Capture a new received message with From, SPF identity/result and DKIM d=/s=/result; evaluate alignment and DMARC on that evidence.
If the new route fails, pause the affected mailing and restore the known working transport under change control. Preserve old records while dependent queued mail or other applications still need them. Remove obsolete records only after dependency review. No real installation or outgoing message was tested here; the route-change example is synthetic and the exact account-generated values remain a deployment prerequisite.