registeraddress for TYPO3

Newsletter signup without external services cuts costs and keeps data under your own control

Mailchimp, Brevo, Rapidmail: for every newsletter signup, organizations pay per subscriber and per email sent. With 10,000 subscribers, that adds up to €100 to €300 a month just for managing the addresses. registeraddress offers an alternative: newsletter registration directly in TYPO3 via the proven tt_address table. Subscriber management, double opt-in, unsubscribe link and GDPR-compliant consent records all run inside the CMS, and no external service ever gets access to subscriber data.

For associations, small publishers and public institutions on tight budgets, this is a valid architecture, especially when the newsletter itself goes out through a low-cost SMTP relay such as Amazon SES ($0.10 per 1,000 emails) or through your own mail server.

Typical use cases include association newsletters, intranet mailing lists and event registrations

The most common scenario is the classic association newsletter. A sports club with 2,000 members offers a signup form on its TYPO3 website. Visitors enter their email address, receive a double opt-in email, confirm and are added to the tt_address table. The club sends a monthly newsletter via the direct_mail extension or an external sending service that imports the addresses from tt_address. registeraddress handles only signup and unsubscribe, not the sending itself.

A second scenario is intranet mailing lists in companies. Employees subscribe to internal information newsletters such as “Amsterdam office: canteen menu” or “IT maintenance windows”. Since the data must not leave the corporate network, an external newsletter service is out of the question. registeraddress manages the subscriptions locally in the TYPO3 database.

The third scenario is event registrations with email confirmation. A library runs events and uses registeraddress as a lightweight registration form. The confirmation email sent after the double opt-in contains the date, time and location of the event. This is not a full event management solution, but it is enough for institutions with five to ten events a month.

The technical architecture builds on tt_address and the double opt-in workflow

registeraddress is implemented as an Extbase plugin and uses the tt_address table as its database. Every registration goes through a three-step process: form entry, a double opt-in email with a confirmation link, and activation of the record once the link has been clicked. The confirmation link contains a cryptographically signed token that expires after a configurable period (default: 48 hours).

The extension registers a frontend plugin that is configured via TypoScript: required fields, optional fields (name, company, salutation), confirmation text, and email templates for the double opt-in and the welcome message. The Fluid templates can be overridden via a site set, so the form matches the design of the website.

For GDPR compliance, registeraddress stores the time of consent, the IP address, the user agent and the version of the privacy policy linked in the form. If a data protection authority makes an inquiry, you can prove when and under what conditions the subscriber gave consent. (US: The federal CAN-SPAM Act follows an opt-out model and does not require prior consent, so these records matter above all for subscribers in the EU.)

Unsubscribes run through a link in the newsletter footer that deactivates the tt_address record rather than deleting it, so the consent history is preserved. Permanent deletion under Article 17 GDPR (right to erasure) can be handled through a separate deletion form or manually in the backend.

Common problems involve double opt-in emails landing in spam and outdated tt_address versions

The dominant problem is the deliverability of the double opt-in email. If the confirmation email lands in the spam folder, the subscriber never completes the registration. The causes are almost always on the server side: a missing SPF record, no DKIM signature, no DMARC policy. registeraddress itself cannot improve deliverability, because this is a mail server issue. We recommend checking email authentication with mail-tester.com before launching a newsletter form.

The second problem is incompatibility with older tt_address versions. registeraddress relies on specific fields in the tt_address table. If tt_address publishes a major update that renames or removes fields, registeraddress can no longer write the records correctly. The fix: always update tt_address and registeraddress together and run a test pass through the entire registration process after the update.

The third topic is bot registrations. Without a protection mechanism, bots fill the form with fake addresses and trigger thousands of double opt-in emails that strain the mail server and damage the sender’s reputation. registeraddress supports honeypot fields and can be combined with sr_freecap or hcaptcha to keep bots out.

TYPO3 v12 is supported, and v13 compatibility requires tt_address alignment

registeraddress runs stably on TYPO3 v11 and v12, provided tt_address is installed in a compatible version. For TYPO3 v13, compatibility depends on both registeraddress and tt_address, since the two extensions are maintained independently. During TYPO3 upgrades, Gosign checks the entire newsletter chain (registration, address management, sending) for compatibility and, if the TYPO3-native solution is no longer maintained, recommends switching to an external newsletter service with an API connection.