Enhanced Email Configuration with Multiple Senders and Automated Validation (Marco Pfeiffer)

TYPO3 Association Community Budget Ideas 2025 Q4
1

Idea Title
Enhanced Email Configuration with Multiple Senders and Automated Validation

What is my idea about?
Extend TYPO3’s email configuration to support multiple sender addresses instead of just one default sender. Extensions can then choose from a predefined list of validated senders. Additionally, implement comprehensive email configuration validation on the system status page, checking SPF records, MX records, and sender existence to prevent email delivery issues.

What do I want to achieve by the end of Q4 2025?

  • Develop a standalone TYPO3 extension for enhanced email configuration
  • Feature: Multiple sender addresses management with backend UI
  • Feature: API for other extensions to select from validated senders
  • Feature: Comprehensive email validation dashboard including:
    • SPF record validation
    • MX record verification
    • Sender email existence check
    • DKIM/DMARC analysis
  • Clear documentation and troubleshooting guides
  • Community feedback integration and testing with real-world installations

What is the potential impact of your idea for the overall goal?
This directly supports the TYPO3 integrators by solving a frequent support issue. Many TYPO3 installations suffer from email delivery problems due to misconfiguration. This feature will:

  • Reduce support requests related to email delivery
  • Improve user experience by ensuring reliable email communication
  • Lower the entry barrier by providing clear guidance on email setup
  • Establish best practices for email configuration in TYPO3

How does your Idea align with the strategic goals for TYPO3 v14.
Objective 1 (UX Improvements): Automated validation eliminates guesswork in email configuration

  • Objective 3 (Lowering Entry Barrier): Clear validation and guidance help newcomers configure emails correctly
  • Objective 2 (Best Practices): Establishes and enforces email configuration best practices
  • Objective 4 (Easier Migration): Validation helps identify and fix email issues during upgrades

Which budget do we need for this idea?
1500 Euro

My Name
Marco Pfeiffer

7 Likes
2

What I would love to see is a site-based configuration of email senders AND mail configuration (servers, credentials,…). This way I could have different setups based on a site, and let it me used frontend-wide for any task (ext:form, fluidmail, regular mail, felogin password resets etc). The global config would then apply to the backend only and be a fallback. What do you think?

4 Likes
3

Oh, yeah. I would also love the feature to configure mail sending in the Site Configuration. And the validation of that configuration sounds good too.

4

I like the site-config idea; however, that would be a lot more complex.

My current implementation idea is to create a database entry for a sender_address with an extra interface that validates them (and potentially imports them from system config). Then, I can swap the input field of ext:form (and possibly more extensions) with a select field that shows all valid options. It would still write the text sender into the form at the end, so the extension would not impact actual execution logic and could be removed at any time if no longer needed or compatible.

Putting the entire e-mail configuration in the site config is something else entirely. In that case, I’d have to hook myself into the sending process. The site config is also not always changeable by backend users, so I’d miss my original goal.

I’ve thought of hybrid approaches, but that would increase the scope and make the goal of the extension less clear.

This is a small “validate and prevent misconfiguration” feature.

5

Thanks for getting back to that with more details on your implementation. Maybe it could a follow-up or future contribution idea. I think the Core needs this. :innocent:

2 Likes