Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Identify the transport before touching DNS
Mautic is an application in the sending chain, not a universal SPF authorization domain. Its current knowledgebase directs administrators to the email service configured in Settings > Configuration > Email Settings. The relevant DNS records come from that service or the organization's own mail server. Record the installed Mautic version and transport before following version-specific instructions. Mautic SPF setup.
The version 7.2 configuration documentation describes email settings and provider transport configuration. Use documentation matching the deployed version rather than importing a legacy signing screen from an older tutorial. Record the transport or DSN scheme without copying credentials into the change ticket. Note whether mail is queued, which workers process it and which account the transport authenticates to. Generic Symfony Mailer transports do not supply Mautic batch sending or transport callback handling; confirm a suitable Mautic-specific transport when those operational features are required. Mautic configuration settings.
Inventory defaults and overrides. A configured default From address does not guarantee that every campaign uses it. Create a small matrix of the campaign email, intended From domain, transport account and queue worker. Include contact-specific or campaign-specific sender choices where they are enabled. In the cited 7.2 settings, Mailer is owner overrides system defaults and plain email From addresses, but a valid tokenized From on the email Advanced tab takes precedence over the owner. Record token fallbacks as well as owner domains. Assign an application owner for Mautic configuration, an email service owner for authentication and a DNS owner for public records.
Configure signing at the responsible service
The current Mautic DKIM guide says the configured email service usually signs the message. Add the actual From domain to that service's domain-authentication workflow, publish its issued TXT or CNAME records and complete verification there. A self-hosted mail server instead needs its own signing implementation and key management. A sample selector such as mautic2026 is an illustration, not a universal Mautic record. Mautic DKIM setup.
Do not transfer a private signing key into Mautic solely because an old guide mentions DKIM configuration. Determine which component signs on the present version and route. If a downstream service adds disclaimers or transforms message content, locate signing after changes where supported or test whether the existing signature survives. Copying DNS records without enabling the responsible signer cannot create a signature.
Keep selector names, public values, domain ownership and account activation in a worksheet. If the provider rotates delegated keys, follow its current procedure; if the organization operates the signer, plan overlapping selectors and safe retirement. DNS visibility and key age alone do not show which key a queue worker is using. A received message supplies the actual d= and s= values. DKIM verification requirements.
Authorize the observed envelope identity
Obtain the sending service's current SPF instructions for the route. Publish them at the required envelope-domain owner, retaining one SPF policy there. Include existing legitimate senders when editing a shared name and apply RFC 7208 §4.6.4’s ten evaluated DNS-causing-term limit, including nested evaluations. Do not copy every sample provider include listed in a Mautic tutorial: only services actually used by the account belong in its authorization plan. SPF policy evaluation.
A custom MAIL FROM or bounce domain, when supported by the chosen transport provider, can give SPF an identity related to the visible From domain. The public Mautic guidance does not establish that every integration exposes this feature. Confirm the exact provider setup and activation separately, and do not treat an application-level Reply-To as a change to the envelope. Reply-To directs replies; it does not select the SPF identity.
Inspect the domain's actual DMARC alignment modes. A passing DKIM d= at a related subdomain may align under relaxed mode and fail under strict mode. Likewise a provider-owned Return-Path can pass SPF while remaining unrelated to the From domain. Record which passing path is intended to carry DMARC rather than merely checking three green status labels. DMARC alignment rules.
Compare the quick test with the queued campaign
Use this blank worksheet for a harmless quick test and a controlled campaign sent through the real worker. It is a proposed comparison, not observed evidence. Replace every blank with a value or “not applicable”; do not count the quick test as a substitute for the campaign run.
- Observation: Mautic version and environment; Quick test: ___; Queued campaign: ___
- Observation: Email or campaign ID and timestamp; Quick test: ___; Queued campaign: ___
- Observation: Transport scheme and account reference without secrets; Quick test: ___; Queued campaign: ___
- Observation: Worker process and deployment/configuration revision; Quick test: ___; Queued campaign: ___
- Observation: Default From and email-specific From override; Quick test: ___; Queued campaign: ___
- Observation: Actual received From domain; Quick test: ___; Queued campaign: ___
- Observation: Return-Path and receiver-reported SPF domain/result; Quick test: ___; Queued campaign: ___
- Observation: Every DKIM d=, s= and receiver result; Quick test: ___; Queued campaign: ___
- Observation: DMARC mode, result and aligned passing path; Quick test: ___; Queued campaign: ___
- Observation: Restricted original-message location; Quick test: ___; Queued campaign: ___
Read across the rows before editing DNS. Different From overrides direct the investigation to the email asset and the sending service's authenticated domains. Different transport accounts or worker revisions direct it to deployment configuration. Matching settings but a missing signature call for checking the actual signer; a body-hash failure calls for examining changes after signing. If SPF fails, compare the receiver-facing sender and envelope domain rather than adding the web server IP automatically.
Illustrative reasoning only: if the quick test uses an authenticated brand domain but the queued campaign overrides From with an unauthenticated second domain, the passing quick test does not validate that campaign. The next action is to authorize the intended second domain at the actual sending service or correct the unintended override, then rerun the controlled campaign. No actual addresses, results or tenant behavior are asserted in this example.
Accept a route only when its intended From selection, expected signer and receiver authentication results agree. Keep an unresolved row open instead of replacing it with a dashboard success badge.
Separate recovery from delivery optimization
Pause the affected campaign or worker using the agreed operational procedure when authentication breaks. Preserve queued-message state and avoid replaying jobs blindly, which can create duplicate communications. Restore the last known-working sender and transport configuration where approved, then retest with controlled recipients. Keep existing keys available while messages signed with them remain in transit.
Authentication is one prerequisite, not proof of consent, reputation or inbox placement. Handle bounce processing, unsubscribe behavior and recipient complaints through their own checks. Do not relax DMARC or add broad SPF authorization as a shortcut around an unidentified integration fault.
No deployed Mautic instance, provider account, DNS zone or live message was inspected for this manuscript. Version and transport selection, account-issued records, live campaign identity evidence and human SME review remain required. The general sending-service workflow is documented, while each actual provider's supported envelope behavior and signing activation remain implementation-specific gates.