Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Start with the transport decision
MODX Cloud hosts the application; that does not prove that MODX Cloud is the outbound mail service. First identify whether the website uses local mail, authenticated SMTP to a mailbox provider, an ESP integration or another application extension. Follow a real password-reset or contact-form transaction through its configuration and logs. Record the application context and extension, because a working administrative test can use different settings from a public form.
The provider's overview says outgoing port 25 is blocked and outbound email is disabled on new accounts pending a support request. It recommends a specialist email service and does not guarantee local-server delivery. This is a reason to settle the architecture before publishing DNS. An SPF edit will not enable a disabled sending path or open a blocked port. Email in MODX Cloud overview.
The Cloud overview prohibits bulk email and newsletters from MODX Cloud servers. Keep this local-server route limited to permitted transactional messages; use an appropriate external service for bulk sending rather than treating authentication as permission to send it.
For an ESP route, obtain the ESP's current authentication instructions and generated DNS values. Do not add a MODX-specific permission merely because the code runs on MODX Cloud. For direct local delivery, confirm with the platform owner that this route is enabled and suitable for the business flow. No account change or support request has been made as part of this article.
Interpret the MODX SPF examples narrowly
MODX's SPF guidance demonstrates adding the a mechanism to an existing policy. That is an example tied to DNS address resolution, not a universal service include. Compare the actual outbound IP with the addresses selected by that mechanism before deciding it authorizes the intended server. A website address behind a reverse proxy or a separately routed mail host may not represent the outbound mail IP. Do not guess a replacement include domain. MODX Cloud SPF records.
Preserve permissions for existing senders, and identify which envelope domain the application uses. A message displaying the organization's address in From can still use an unrelated envelope domain. Publishing a correct policy at the wrong domain does not fix that message. Likewise, an inbound MX record is not evidence that the named hosts originate the website's mail. Avoid expanding authorization through broad mechanisms just to make a diagnostic tool display green.
Keep CMS signing separate from Cloud guarantees
The application-signing documentation could not be read in this review: its selector-settings endpoint returned HTTP 403. This package therefore does not establish a current CMS-managed DKIM procedure. Keep that route on hold until the administrator obtains documentation for the installed version, extension and actual mail path. Do not infer application signing capability from Cloud hosting alone.
If application-managed signing is chosen, assign responsibility for key generation, private-key storage, file access, rotation and recovery. Never publish a private key in DNS or include it in a troubleshooting bundle. Obtain the selector and public value from the approved configuration, publish the exact owner, then test the workflow that invokes the mailer. If an ESP signs after submission, document that service as the signing owner instead of assuming a CMS signature survives every subsequent transformation.
Test the website behavior that matters
Use a controlled test registration, password reset and contact form as separate cases if all are in scope. Confirm that the configured From address belongs to the organization. Put visitor-supplied addresses in an appropriate reply field rather than making an arbitrary visitor domain the authenticated sender. Inspect reply handling as well as delivery. A contact form that sends unwanted copies to arbitrary addresses can be abused even when its authentication is technically correct.
Separate authentication failure from application failure: a missing message may never have left the application, may have been rejected on submission, or may have been accepted and later filtered. Preserve the message ID and relevant timestamps without copying user passwords or reset tokens into shared logs. Coordinate any transport switch with the website owner so that queued notifications are neither silently lost nor duplicated.
Use the MODX route decision worksheet
Copy this worksheet for each application context. Blank observations are intentionally unverified. The rows are decisions to resolve, not claims about a customer's installation.
- Route found in application settings: ESP API or SMTP submission; Authentication owner to identify: ESP account, issued DNS records and final signer; Stop condition: No matching account instructions
- Route found in application settings: Authenticated mailbox SMTP; Authentication owner to identify: Mailbox service and permitted From identity; Stop condition: Submission identity or sender permission unknown
- Route found in application settings: Local application mail; Authentication owner to identify: Enabled Cloud route, actual outbound IP and installed signing path; Stop condition: Route disabled or outbound source unconfirmed
- Application context and extension: ______; installed version: ______.
- Trigger and controlled recipient: ______; transport configuration owner: ______.
- From domain: ______; observed envelope domain: ______; final sending IP: ______.
- DKIM d= and s= for every signature: ______; trusted receiver results: ______.
- Authoritative DNS answer, server and UTC time: ______; evidence location: ______.
- Pause owner and last known-good transport: ______; acceptance decision: ______.
Worked password-reset diagnosis
This is a fictional analysis using reserved example domains, not a delivered-message result. Suppose a reset is submitted to an ESP, From is notices@example.com, the envelope is bounce@provider.example, and the trusted recipient reports SPF pass for provider.example plus DKIM pass with d=example.com. SPF does not align with example.com; the same-domain DKIM result supplies an aligned passing path. Adding the Cloud website's A address to example.com's SPF is not the correction indicated by those observations. DMARC specification.
If the reset never receives an application message ID or successful submission response, investigate application execution before authentication. If submission succeeds but the recipient finds a different signer, compare the specific reset context with the admin-test context. A successful contact form must not substitute for the reset test.
Decide whether the website route can be released
- Configuration check: the selected transport is enabled, its owner confirms support, and generated records belong to this account.
- Identity check: organizational From and safe Reply-To behavior are confirmed for each form; visitor domains are not impersonated.
- DNS check: the exact envelope policy and DKIM selector resolve authoritatively. Check one SPF policy and the full lookup dependency path. SPF processing.
- Message check: the real application trigger reaches the controlled recipient with a trusted aligned result. Record all signatures, not just the first. DKIM verification.
- Recovery check: the website owner can pause the affected trigger, reconcile queued jobs and restore the previous transport without duplicating notifications.
Before switching transport, retain the changed settings and DNS RRsets. If the controlled test fails, stop that workflow and restore only those changes; then trigger a fresh harmless transaction. Do not collect reset tokens or private signing keys in the evidence worksheet. Product/version changes, new extensions and separate application contexts require a fresh route assessment.
No live tenant, authoritative before-and-after DNS or delivered-message test is represented here. Technical evidence, visual inspection and human SME approval remain pending; the completed fictional example does not close any of them.