Provider documentation checked on 8 November 2026. Account-generated values and current product support remain deployment prerequisites.
Acquia Cloud hosting and Acquia Platform Email are related but different configuration tasks. This guide covers the current Platform Email route for a Drupal application, not every SMTP module that might run on that website. An application using a separate SMTP supplier needs that supplier's authentication instructions instead.
Register the email domain in the right place
References: RFC 6376 §3.6.2.
Start with the Cloud Platform application and its Email area. On Domain Verification, use Add Domain for the intended sending domain. Website Domain Management is not the email-domain configuration screen. Acquia lists owner or administrator permissions for domain configuration and owner permission for application association. Arrange DNS access and a Drupal administrator before beginning.
Copy the records generated for this domain into its authoritative DNS service. Acquia's workflow verifies the records and then allows the verified domain to be associated with an application. Associate it with the application that will actually send the messages. Configure the Drupal site email address under Configuration, Basic site settings, Site Details. For a custom mail-system module, the documented Platform Email path requires Default PHP mailer as Sender; this is not a requirement for a separately chosen external SMTP route. These are distinct steps: a verified domain that is not used by the application does not prove the application's outgoing route is authenticated. Acquia configuration
Avoid the legacy SPF trap
References: RFC 7208 §4.5.
Acquia's February 2025 support notice says the legacy email service was removed and its _spf.acquia.com dependency is no longer required. Do not add that historical include to a new Platform Email configuration. If it is already present, review the full SPF policy and the migration evidence before removing only the obsolete term. Do not replace unrelated mail-service authorizations. Legacy SPF notice
Use the current generated records for the selected domain. Do not copy another customer's SES targets or move the corporate domain's receiving MX records to a guessed destination. Preserve the exact owner names and record types supplied by the service.
Test a Drupal transaction, not just a console status
References: RFC 9989 §4.4.
Original verification plan: trigger a harmless notification using the application's normal delivery path and a mailbox you control. Record the visible From domain, SPF identity and result, DKIM d= and s= values and verification result, and the receiving system's DMARC result. Compare the authenticated domains with the visible From domain under its alignment policy. A DNS verification badge is evidence of setup, not a received-message result.
Illustrative failure: a site verifies news.example.com in Platform Email, but its form module uses another SMTP service. The mail can leave successfully while authenticating a different domain. Correct the selected transport or authenticate that separate supplier; repeatedly adding Platform Email records cannot change the other supplier's signer.
Recover without breaking another application
Keep the previous configuration, application association and DNS values in the change record. If test mail fails, pause the affected workflow, inspect Drupal transport configuration and restore the previously verified route if it remains available. Check whether the domain is shared with other applications before dissociating or deleting it. Do not delete verification records merely because one test failed.
This is documentary setup guidance. No Acquia tenant, DNS zone or real message was tested for this article. Completion requires a saved application-specific received-message table and a named owner for any exception.