Why are there three DKIM CNAMEs but only one selector in a message?

Acquia’s SES-backed workflow issues three aliases to support managed DKIM operation and rotation. A message can use one selector without making the other issued records disposable. Keep all required aliases.

Why is an MX record needed for outgoing mail?

It configures the provider’s custom MAIL FROM feedback domain. It does not move your staff’s inbound mail to Acquia. Publish it only at the issued child owner after confirming that destination and ownership are authorized.

Is setting Default PHP mailer as Formatter enough?

No. For the native route, the relevant transport field is Sender. A Formatter choice controls formatting. Inspect module-specific overrides and test the actual hosted notification path.

Can I use a subdomain with strict SPF alignment?

A visible From on the registered domain and an envelope under acq-mail are different domain names. They can relax-align, but not strictly align with each other. Preserve the intended policy and verify an appropriately aligned passing DKIM signature instead of assuming strict SPF works.

Is a separate AWS SES setup required?

Not for the Cloud Platform workflow documented here. Acquia supplies the domain records and application association process. Directly managed SES and third-party SMTP modules have separate configuration and acceptance requirements.

Acquia Cloud SPF, DKIM & DMARC Setup: Step-by-Step Guide

To authenticate Drupal mail through Acquia Cloud Platform, register the sending domain in Email → Domain Verification, publish all seven DNS records issued for that domain, wait for verification, and associate the domain with the application. Then configure Drupal’s From address and confirm that the application uses the native PHP mailer. Finish by checking a freshly received notification for the intended aligned DKIM signature and a trusted DMARC pass. A verified DNS entry alone does not complete this setup. Acquia configuration instructions.

This guide covers Platform Email for transactional messages from Drupal hosted on Cloud Platform. It does not configure Campaign Studio, Site Factory marketing workflows, employee mailboxes or a Drupal SMTP module connected to another supplier. Acquia documents limited transactional use, such as registration confirmations and subscription notifications, rather than marketing campaigns, newsletters or attachments. It provides Platform Email as a courtesy service without an uptime or service-level agreement. Platform Email scope.

No customer account, DNS zone or delivered message was tested for this guide.

Before you start: entitlement, roles and the actual mail route

Confirm these prerequisites before changing records:

Platform Email entitlement: the application must have the service available. If Email is absent from navigation, Acquia directs you to your Account Manager to provision the entitlement. Do not infer availability from a hosting-plan name alone.
Cloud Platform permissions: Acquia lists the organization’s Owner or Administrator for domain configuration, association, dissociation and deletion. Arrange access to the correct organization, subscription and application.
Drupal access: someone must be able to change the site email address. Basic site settings are available to administrators and to users granted the relevant access.
DNS authority: identify the service actually hosting authoritative DNS, including any delegated sending subdomain or _domainkey namespace. The registrar is not necessarily the DNS host.
Sending-route ownership: record the hosted application and environments, the intended From address, and the mail transport used by each important notification. A form module can override the site-wide transport or From address.

Save the existing relevant DNS records, application associations, Drupal email settings and applicable DMARC policy. Identify other applications and subscriptions using the domain. If the intended acq-mail name already serves another purpose, resolve that collision with the DNS owner and Acquia before proceeding. A less commonly used name is not necessarily an unused one. Acquia prerequisites, missing entitlement and hosted-environment checks.

1. Register the email domain, not just the website

Open the Cloud Platform application that will send the notifications.
Select Email, then the Domain Verification tab.
Select ADD DOMAIN.
Enter the intended sending domain in Domain to add, then select ADD DOMAIN again.
Find the new domain with Verification pending status and expand its record list.

Use the domain of the intended email address. Acquia allows sending subdomains but does not support configuring a subdomain with the www prefix. Adding a website hostname in Domain Management does not register an email-sending domain. Keep website routing and email authentication as separate changes. Registering a Platform Email domain.

2. Collect the complete seven-record DNS set

Acquia’s current procedure issues seven records for the initial domain setup. Copy every owner, record type and complete value from your actual account. Preserve MX priority separately if your DNS host has a dedicated priority field.

Three DKIM CNAME records: each has its own issued selector under _domainkey and an issued provider destination. Publish all three, even though a particular message may use only one selector.
Two ownership TXT records: Acquia’s documented example uses _amazonses and _acquiaplatform beneath the registered domain. Their complete tokens prove ownership; they are not SPF policies or DKIM public keys.
One SPF TXT record: this belongs at the issued custom MAIL FROM owner, documented as acq-mail beneath the registered domain.
One MX record at that same MAIL FROM owner: its regional feedback destination supports the provider’s custom envelope domain. It is not a replacement for the normal mailbox-domain MX records.

The DNS record list, not a copied screenshot, supplies your values. Do not reuse another domain’s ownership tokens, DKIM selectors or regional MX destination. Do not create your own DKIM private key or paste a TXT public key where Acquia issued a CNAME. Record issuance and MX field handling, Acquia’s custom MAIL FROM explanation.

For orientation, the official sample uses the SPF value v=spf1 include:amazonses.com ~all at its child MAIL FROM name, and an MX destination in a particular AWS Region. These are clues for understanding the record roles, not permission to reconstruct your account’s seven-record set. Copy the current issued SPF value, MX priority and complete regional hostname exactly after checking their authorized use.

Keep ownership tokens for every active subscription

Domains can be used by applications within the same subscription. For a domain used across subscriptions, Acquia says to verify it in one subscription first, then add and verify an additional ownership TXT record for each further subscription. Preserve all still-required token values. Do not overwrite the first subscription’s token when onboarding the next one. This is different from SPF’s one-policy rule: multiple independent ownership TXT values can be legitimate. Multi-subscription verification.

3. Publish at the correct DNS owners without disrupting other services

Suppose the registered sending domain is example.com. These are owner-name illustrations only, not records to deploy:

Issued DKIM owner: ISSUED-SELECTOR._domainkey.example.com
Ownership TXT owners: _amazonses.example.com
 _acquiaplatform.example.com
MAIL FROM TXT/MX owner: acq-mail.example.com

In a DNS editor for the example.com zone that appends the zone name, the relative owners are ISSUED-SELECTOR._domainkey, _amazonses, _acquiaplatform and acq-mail. An editor accepting full names may instead require the full owners. Preview the resulting name so it does not become acq-mail.example.com.example.com.

For a registered sending domain of alerts.example.com, the MAIL FROM owner becomes acq-mail.alerts.example.com. In the parent example.com zone its relative name is acq-mail.alerts; in a separately delegated alerts.example.com zone it is acq-mail. Apply the same suffix logic to ownership and DKIM records. If _domainkey.alerts.example.com is separately delegated, the DKIM records belong at that delegation’s authoritative DNS service, often with only the issued selector as the relative name. Preserve existing NS delegation and other active selectors rather than deleting them to make room.

Handle DKIM CNAMEs as DNS aliases

Keep each issued CNAME owner free of conflicting TXT, A, AAAA, MX or another CNAME record. Resolve an occupied owner with its owner and Acquia; do not silently overwrite a working sender. Configure these authentication CNAMEs as DNS-only, not HTTP-proxied.

Check whether flattening would conceal the required CNAME. The relevant behavior may be per-record, zone-wide, apex-only or applicable to same-zone targets. An apex-only rule might not affect a DKIM child name; do not disable unrelated settings unnecessarily. Use the narrow setting appropriate to these records and retain other services’ behavior. A public CNAME lookup should expose the exact issued alias, rather than an HTTP proxy address or a flattened address answer.

Approve the MAIL FROM MX routing, not just its spelling

Compare the exact acq-mail owner and feedback destination with the authorized mail-routing plan before saving. Publishing the MX assigns incoming mail for that child name to the provider’s feedback service. It must not take over employee mail, a working bounce domain or another application’s inbound route. Keep the organization’s ordinary apex MX unchanged. Do not append several guessed regional MX targets or turn the child name into a mailbox service. If the issued record conflicts with an existing use, stop and reconcile the design.

The SPF TXT and feedback MX can coexist at the MAIL FROM owner. They must not coexist with a CNAME at that same owner. These distinctions follow the record types Acquia issues and the DNS alias rules. Acquia DNS requirements, CNAME constraints, RFC 1034.

4. Verify every record, then associate the application

Check the published values against the account’s expanded record list. Acquia says verification can take up to 72 hours; elapsed time is not proof that a wrong owner or target will fix itself. Confirm that the required records verify and the domain reaches OK.

Next, open Domain Association for the intended application, select Associate beside the domain, and confirm ASSOCIATE DOMAIN. Check that its state becomes Associated. Repeat only for applications that are intended and authorized to use the domain. An OK domain that remains unassociated is not ready for that application’s mail. Verification and association.

Keep the records in DNS after verification. Acquia continues checking them; removing “temporary” ownership or DKIM records can break the service later.

Optional CLI route for multiple applications

Acquia also documents acli email:configure for an already authenticated Cloud Platform user. It prompts for the sending domain and subscription, exports DNS instructions as JSON or YAML, checks verification, and prompts for the applications and environments to enable. Choose those deliberately; configuring one environment does not prove another uses the same route.

The utility regenerates its DNS export file on each run. Preserve the earlier approved export before rerunning, and compare changes rather than assuming the new file matches DNS. The CLI is an alternative orchestration path for the same Platform Email configuration, not permission to skip DNS review, Drupal settings or message acceptance. This guide does not require installing CLI software or changing credentials. Official CLI workflow.

5. Set Drupal’s From address and actual Sender

In the hosted Drupal site, open Configuration → Basic site settings → Site Details. Set Email address to the intended From address on the verified domain, then select Save configuration. Acquia says a From address on a different domain prevents Platform Email from sending. Check form and notification-specific overrides as well as the basic setting. Drupal From configuration.

If a custom Mail System module is installed, open Configuration → Mail System and verify that Sender is Default PHP mailer for the native Platform Email route. Changing only Formatter does not select the sending transport. Acquia’s screenshot specifically highlights the Sender field. Without a custom mail module, this dropdown may not exist; do not install a module merely to reproduce the screenshot.

Do not silently replace an intentionally configured external SMTP transport. Decide whether the workflow belongs on native Platform Email or that separate supplier, then authenticate the chosen route. For a directly managed SES application, use the separate EmailAuth Amazon SES guide. Acquia’s SES backend does not mean its customers should substitute AWS-console identity settings for Cloud Platform association.

6. Understand Acquia SPF and retire the legacy include safely

SPF evaluates the SMTP envelope identity, normally MAIL FROM, rather than the address displayed in From. Acquia documents acq-mail.<registered-domain> as its custom MAIL FROM domain while the visible From address remains on the registered domain. SPF is therefore checked at that child name. Adding an SES include to the parent’s SPF does not fix a missing policy at the actual envelope owner. Acquia envelope identity.

Publish one v=spf1 policy at each evaluated owner. If the issued MAIL FROM owner already has SPF, inventory its users before replacing or merging anything. Preserve legitimate authorizations and the intended qualifier. An existing a or mx mechanism authorizes the addresses reached through those names; it is not harmless boilerplate. Changing an MX can consequently change SPF authorization when an mx mechanism depends on it.

Keep SPF evaluation within the ten DNS-dependent-term limit, including nested processing of include, a, mx, ptr, exists and redirect. This is not simply “ten includes.” Adding an all mechanism makes redirect ineffective; do not automatically append a qualifier to a redirect-based policy. SPF -all and ~all express authentication outcomes, not guaranteed rejection or delivery. SPF rules, RFC 7208.

Do not add include:_spf.acquia.com to a new setup

Acquia’s notice published February 6, 2025 states that Legacy Email has been removed and _spf.acquia.com is no longer required. Older instructions recommending that include are not the current Platform Email procedure. Acquia’s legacy SPF notice.

If an existing policy still contains it, confirm which applications have migrated and inventory the complete policy first. Remove only the obsolete authorization as an approved cleanup, retaining unrelated mail services, qualifiers and dependencies. Do not delete the entire SPF record or try to restore the retired service as a rollback route.

7. Preserve DMARC and check alignment explicitly

Inspect the DMARC policy applicable to the visible From domain, including an inherited policy when no direct record exists. Preserve existing protection, alignment settings and authorized report destinations. Acquia onboarding does not justify replacing p=reject with p=none, duplicating the record or discarding a parent policy.

For example, From notifications@example.com and MAIL FROM under acq-mail.example.com can align under relaxed SPF alignment because they share the Organizational Domain. They do not exactly match, so that SPF path does not satisfy aspf=s. Keep a deliberate strict policy intact and verify whether the intended DKIM signature supplies the aligned pass. Strict DKIM alignment requires the signature’s d= domain to exactly match the visible From domain; do not infer it from a DNS badge. DMARC identifier alignment, RFC 9989.

DMARC requires a passing aligned SPF identity or a passing aligned DKIM signature. For this DKIM setup, a DMARC pass through SPF alone is insufficient acceptance: the intended Acquia signature must also pass and align. A rewritten provider-owned From address is not successful authentication of the brand you intended to use.

A first monitoring policy, only when no policy already applies

If there is no direct or applicable inherited policy, and the domain owner approves a monitored first deployment, the baseline is one TXT record at _dmarc.<visible-From-domain>. For example.com, the full owner is _dmarc.example.com, normally entered as _dmarc in that zone. For alerts.example.com, use _dmarc.alerts in the parent zone or _dmarc in a separately delegated alerts.example.com zone.

This is a template, not a ready-to-publish value:

v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-ADDRESS

Replace the placeholder with an authorized, monitored destination before publication. p=none requests monitoring rather than quarantine or rejection. Enforcement changes require an inventory and evidence for all legitimate senders, not one Drupal test.

If the report destination belongs to a different Organizational Domain from the policy domain, the report-generating receiver must check the destination’s DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone does not establish external reporting. This protocol check is separate from the owner’s permission to share sending information. Approve the recipient, access and retention, and do not add failure reports or copied vendor addresses by default. External reporting authorization, RFC 9990 section 4.

8. Verify DNS and a real hosted Drupal notification

First compare authoritative DNS with the issued packet and at least one independent resolver. These commands are templates; replace example.com and ISSUED-SELECTOR with the actual domain and each of the three selectors. They are not claimed test results.

dig CNAME ISSUED-SELECTOR._domainkey.example.com
dig TXT _amazonses.example.com
dig TXT _acquiaplatform.example.com
dig TXT acq-mail.example.com
dig MX acq-mail.example.com
dig TXT _dmarc.example.com

Check all seven records, including every required subscription ownership token, exact DKIM target and regional MX priority/destination. If answers disagree, inspect the authoritative zone and cached TTLs before editing again. A direct DMARC query without a record does not prove no inherited policy applies.

Then trigger a harmless, representative notification through the actual hosted Drupal application and environment, to a valid external mailbox you control. Do not test with nonexistent recipients, a local machine without mail services, or a bulk mailing. Capture the application/environment and time alongside these observations:

The visible From address remains the intended branded address.
The actual SMTP MAIL FROM or receiver-reported smtp.mailfrom identifies the expected envelope domain; retain Return-Path as supporting evidence.
The intended Acquia DKIM signature has the expected d= signing domain and an issued s= selector, and the receiver reports it as passing.
That passing signature aligns with the intended From under the applicable adkim setting, and the trusted receiver reports dmarc=pass for that From domain.
SPF is checked separately at its actual owner. Investigate fail, temperror or permerror even when aligned DKIM makes DMARC pass.

Use results produced inside the receiving service’s known processing boundary, with its documented handling of externally supplied Authentication-Results. If an inbound gateway is involved, establish which service evaluated authentication and how untrusted incoming result fields are removed or segregated. A familiar authserv-id, a header’s position or a pasted “pass” string is not proof. Ignore attacker-supplied or otherwise untrusted result fields; obtain the receiving administrator’s trace when the boundary is unclear. Authentication-Results trust, RFC 8601.

Retest every important application and environment, especially notifications with their own mail-module overrides. Keep shared header evidence free of unnecessary recipient information, message content and credentials. DNS, Acquia status and a received-message result answer different questions; none guarantees inbox placement.

Troubleshooting and safe rollback

Request the Platform Email entitlement through your Account Manager. Do not work around an entitlement issue by publishing guessed SES records or switching an application’s mail provider. Entitlement troubleshooting.

Verification stays pending or fails

Compare full owners, complete values, all three DKIM aliases, both ownership tokens and the MAIL FROM pair. Check duplicate domain suffixes, wrong authoritative DNS, CNAME proxy/flattening and MX priority entered in the wrong field. Acquia allows up to 72 hours; persistent pending status calls for correction, not repeated record replacement. For Verification failed, correct DNS and use Refresh beside the domain. Verification states.

The domain is OK but the application sends no mail

Confirm Associated on the intended application, the verified domain in Drupal Site Details, and Sender: Default PHP mailer where a custom Mail System is installed. Check notification-specific From and transport overrides. DNS for Platform Email cannot authenticate a message a different SMTP provider actually sends.

Verification is rejected, revoked or at risk

Rejected can indicate another subscription claimed the domain while the first verification was pending. Coordinate subscription ownership and follow Acquia’s verify-first, additional-token sequence instead of deleting other subscriptions’ records.

A Revocation warning can identify a missing DKIM record. Acquia checks records daily and documents Domain revoked when required DNS records have been missing for more than five days, after which the domain cannot send. Restore the exact still-required records, verify their authority and use Refresh. Revocation and ownership guidance.

DMARC passes but SPF or the intended DKIM signature fails

Identify which authenticated path supplied DMARC. An SPF-only pass does not validate DKIM setup. A DKIM-backed pass does not excuse a broken SPF policy. For DKIM, compare the message’s d= and s= against the issued aliases and check whether a relay modified signed content. For SPF, distinguish wrong envelope routing or missing authorization from DNS temporary errors and permanent policy errors. Do not weaken DMARC to mask the fault.

Authentication passes but messages are blocked or unwanted

Review application errors, valid recipients, bounce and complaint handling, form abuse and the receiver’s rejection reason. Acquia can block applications with excessive bounces or spam complaints. Do not bypass suppression, send repeated tests to invalid addresses or recommend blanket allowlisting. Authentication is separate from permitted use and recipient filtering. Sending restrictions and troubleshooting.

Roll back without breaking a shared domain

Pause the affected notification workflow or restore a previously verified, still-supported route under its owner’s change plan. Save the failed message evidence before changing configuration. Do not delete DNS as a diagnostic shortcut.

If an authorized rollback requires dissociation, use Email → Domain Association → Actions → Dissociate, then confirm DISSOCIATE. This disables that domain’s sending for the application but leaves it registered in the subscription. It can be associated again later. Before deleting a domain, Acquia requires dissociation from all applications; deletion removes its Platform Email registration and associated verification data. Inventory every application, environment and subscription first, and remove DNS only after all relevant dependencies have been retired. Dissociation and deletion.

Sources and maintenance

The custom MAIL FROM explanation was published February 4, 2025, and the Legacy Email SPF notice February 6, 2025. These vendor dates are separate from the November 12, 2026 documentary check.

Recheck the issued DNS set, associations and Drupal sender configuration after a subscription move, domain change, mail-module update or DNS migration. Preserve an owner-approved record of the actual application’s acceptance evidence and any unresolved exception. A future product change should update this workflow, not revive a retired include or substitute a different Acquia product.

Acquia Cloud SPF, DKIM and DMARC setup, step by step