Task 1 - Lock The Newsletter v1.0 Rules

Start by agreeing on what v1.0 is supposed to do. This protects the project from growing twelve extra arms before the first issue is sent.

Step 1 - Use the newsletter-first publishing model

The email is the main version. The WordPress public issue supports sharing, search, archives, and subscriber growth.

The v1.0 loop is: useful email -> public WordPress issue -> reader share -> new signup -> double opt-in -> future email.

Step 2 - Keep v1.0 deliberately small

• One newsletter subscription.
• One welcome email.
• Three public signup forms plus one confirmation form.
• Issue-level referral tracking with UTM tags.
• No reward ladder, personal referral codes, interest scoring, dynamic personalization, or complex re-engagement yet.

Step 3 - Use one naming rule everywhere

Start every newsletter item in Mautic with NL | so the team can find it fast.

Back to top

Task 2 - Secure And Patch Mautic 6

This is a launch gate. A newsletter should not be built on an unpatched internet-facing Mautic install.

Step 1 - Check the exact Mautic version

For Mautic 6, the current final community security release is 6.0.9. Confirm the version before building the newsletter pieces.

Step 2 - Deal with the Mautic 6 support deadline

Mautic 6 community security support ends September 30, 2026. If you stay on Mautic 6 after that date, make sure you have Extended Long Term Support or another supported security plan.

Do not rush an upgrade in the middle of the newsletter build. Do make sure security coverage is not allowed to quietly expire.

Step 3 - Back up before changing Mautic

• Back up the Mautic database.
• Back up Mautic files and configuration.
• Know how to restore the backup before applying an update.

Back to top

Task 3 - Verify Email Authentication And Deliverability

If the sending domain is not trusted, the prettiest newsletter in the world can still end up in Spam.

Step 1 - Verify SPF, DKIM, and DMARC

Check the domain used in the From address. SPF, DKIM, and DMARC should be valid and aligned with the sending setup.

Google requires authentication for senders and has stronger requirements for higher-volume senders. Yahoo has similar requirements.

Check SPF

Confirm the sending domain has one valid SPF record and that it authorizes the service that sends your newsletter.

Check DKIM

Send a real test message and confirm DKIM shows PASS for the domain used by your sending setup.

Check DMARC

Confirm a DMARC record exists. Start with a policy your mail administrator is comfortable monitoring, then tighten it only when the domain is ready.

Step 2 - Verify TLS and DNS

• Mail should be sent over TLS.
• The sending host should have valid forward and reverse DNS when you control the sending IP.
• If an email service provider manages the IP, confirm the provider handles these items.

Step 3 - Check spam complaint monitoring

Use Google Postmaster Tools when your sending volume provides enough data. Keep complaint rates very low. Google says to stay below 0.1% when possible and never let the rate reach 0.3% or higher.

Step 4 - Confirm bounce and complaint handling

Your mail provider must send hard bounce and complaint information back to Mautic or otherwise suppress those addresses. The exact setup depends on your mail transport.

Back to top

Task 4 - Set The Newsletter Sending Identity

Subscribers should quickly recognize who sent the newsletter and know where a reply goes.

Step 1 - Choose one From name

Use the same recognizable From name on each issue. Example: Barb Ling.

Step 2 - Use a dedicated newsletter From address

Use a newsletter or marketing address that stays consistent. Google recommends separating subscription mail from transactional mail such as receipts and password resets.

Step 3 - Use a real Reply-To inbox

Do not use a dead no-reply mailbox. Send replies to an inbox somebody on the team reads.

Step 4 - Record the physical postal address

Choose the valid postal address that will appear in the footer of every commercial newsletter issue. A registered PO box or qualifying commercial mailbox can meet the U.S. CAN-SPAM address requirement.

Back to top

Task 5 - Verify The Mautic Jobs That v1.0 Uses

Mautic relies on server jobs for segment updates and scheduled broadcasts.

Step 1 - Verify the segment update job

Confirm that mautic:segments:update runs on schedule. v1.0 uses it for the dynamic bounced-email review segment.

Step 2 - Verify scheduled broadcast sending

Confirm that mautic:broadcasts:send runs on schedule if you plan to schedule Segment Emails.

Step 3 - Verify any mail queue worker your setup requires

Some Mautic installations send immediately. Others use a queue. Confirm the actual method used on your server and make sure its worker is running.

Step 4 - Do not add campaign cron jobs just for this newsletter

Newsletter v1.0 does not require a Mautic Campaign. The signup, confirmation, and welcome flow can be handled with Form actions. If your Mautic installation already uses Campaigns for other work, keep those existing cron jobs.

Back to top

Task 6 - Create The Two Newsletter Contact Fields

Only store data that has a clear v1.0 job. Mautic already records form submission times and UTM activity.

Step 1 - Create Newsletter Signup Source

Create a text or select Contact field named Newsletter Signup Source with alias newsletter_signup_source. Make it available for Segment filters and reporting if useful.

Step 2 - Create Newsletter Consent Version

Create a text Contact field named Newsletter Consent Version with alias newsletter_consent_version. The hidden value for the first release should be a simple label such as NL-V1.

If the signup promise changes later, change the value. This gives you a simple record of which wording applied when someone subscribed.

Step 3 - Do not add referral fields yet

Personal referrer codes and referral counts belong to v2.0. v1.0 tracks which issue or traffic source caused a signup through UTM data.

Back to top

Task 7 - Create The Three Mautic Segments

Segments do the real grouping work in v1.0. Tags are not required for this first release.

Step 1 - Create NL | Subscribers - Confirmed

Create a static Segment. A Contact enters this Segment only after completing the confirmation form.

Use this Segment as the recipient Segment for every daily newsletter broadcast.

Step 2 - Create NL | Internal Testers

Create a static Segment containing you and the colleagues who check real newsletter sends. These must be normal Mautic Contacts, not only Mautic Users.

Step 3 - Create NL | Bounced Emails

Create a dynamic review Segment with the filter Bounced Email = Yes. Use it to inspect list health. Do not use it as your only bounce suppression system.

Step 4 - Create no newsletter tags for v1.0

The three Segments, Mautic Do Not Contact status, Form history, and Email history already tell us what we need. Interest tags and referral tags are parked for v2.0.

Back to top

Task 8 - Build The Main Newsletter Signup Form

This is the form on the main newsletter landing page.

Step 1 - Create NL | Signup - Main as a Standalone Form

Use a Standalone Form so you can attach submit actions directly.

Step 2 - Add the visible fields

• Email - required.
• First Name - optional.
• A clear statement that submitting starts the confirmation process for the newsletter.
• A link to your Privacy Policy.

Email field

Make Email required. This is the address Mautic uses to identify the subscriber.

First Name field

Keep First Name optional so a visitor can subscribe with as little friction as possible.

Consent copy

State plainly that submitting the form starts the confirmation process for the newsletter. Link the words Privacy Policy to the real policy page.

Step 3 - Add spam protection

Add Mautic CAPTCHA in honeypot mode or another tested anti-bot method. Mautic recommends some form of CAPTCHA protection on every Form.

Step 4 - Add the hidden fields

Step 5 - Add the Form actions

• Record UTM Tags.
• Send Email to Contact: NL | Confirm Subscription.
• Do not add the Contact to the confirmed subscriber Segment yet.

Record attribution

Use Record UTM Tags so Mautic can store UTMs that are present on the page when the form is submitted.

Send confirmation

Use Send Email to Contact and select NL | Confirm Subscription.

Do not subscribe yet

Do not add the Contact to NL | Subscribers - Confirmed on this first form. Confirmation must happen first.

Step 6 - Redirect to the WordPress check-your-email page

After submission, the visitor should see clear instructions to open the confirmation email.

Back to top

Task 9 - Build The Public Issue Signup Form

This form sits inside each public WordPress newsletter issue and is important for the share-to-subscribe loop.

Step 1 - Create NL | Signup - Public Issue

Use the same core fields and anti-bot protection as the main form.

Step 2 - Set the source hidden field

Set Newsletter Signup Source to public-issue and Newsletter Consent Version to NL-V1.

Step 3 - Add Record UTM Tags

This lets Mautic record issue-level and share-source UTMs when the signup happens on the same public issue page.

Step 4 - Send the same confirmation email

All public signup routes should use the same double opt-in confirmation process.

Back to top

Task 10 - Build The Footer Signup Form

A site-wide footer form gives visitors another quiet way to join without adding popups to v1.0.

Step 1 - Create NL | Signup - Footer

Use Email, optional First Name, anti-bot protection, and the Privacy Policy link.

Step 2 - Set the hidden source values

Step 3 - Add Record UTM Tags and send the confirmation email

Use the same confirmation path as the other two signup forms.

Back to top

Task 11 - Build The Double Opt-In Confirmation Form

This extra form is the piece that keeps automatic link scanners from confirming a subscription just because they visited the confirmation URL.

Step 1 - Create NL | Confirm Subscription as a Standalone Form

Place this form only on the WordPress confirmation page linked from the confirmation email.

Step 2 - Include an Email field and a clear confirmation action

The Email field should be required. Try Mautic auto-fill so the subscriber does not need to type it again. Keep the field visible during testing so failures are obvious.

The submit button should say something plain such as Yes, subscribe me.

Step 3 - Prefill the Email from the confirmation link

The confirmation email can link to the WordPress confirmation page with an encoded Contact email token, such as ?email={contactfield=email|true}. Test this exact behavior on your Mautic 6 build before launch.

Step 4 - Add the confirmation Form actions in this order

• Remove Contact from Do Not Contact list. This safely supports a person who previously unsubscribed and is now confirming again.
• Modify Contact Segments: add NL | Subscribers - Confirmed.
• Send Email to Contact: NL | Welcome.
• Redirect to the WordPress confirmed page.

Step 5 - Add anti-bot protection

Use a honeypot or another low-friction anti-bot check here too.

Back to top

Task 12 - Build The Confirmation Email

The confirmation email has one job: get the subscriber to finish confirming.

Step 1 - Create NL | Confirm Subscription as a Template Email

Template Emails can be sent from Form actions. Keep this email short.

Step 2 - Use one confirmation button

Link the button to the WordPress confirmation page. Include the encoded email token needed to prefill the confirmation form.

Step 3 - Explain why they received it

Say that somebody entered this email address to join the newsletter. If it was them, click through and confirm. If not, they can ignore it.

Step 4 - Keep promotions out of this email

Do not add affiliate links or a pile of offers. Confirmation should feel clean and trustworthy.

Back to top

Task 13 - Build The Welcome Email

The welcome email is the first real newsletter relationship message.

Step 1 - Create NL | Welcome as a Template Email

The confirmation form sends this email immediately after successful confirmation.

Step 2 - Tell the subscriber what happens next

• What the newsletter is about.
• How often you send it.
• What address it will come from.
• How to reply to you.
• A link to one strong public issue or the newsletter archive.

Step 3 - Ask them to add the sender to Contacts

Make this a simple suggestion, not a technical lecture.

Step 4 - Include the normal unsubscribe footer

The welcome email is still marketing email. Give people a clear exit.

Back to top

Task 14 - Build The Master Newsletter Email Layout

Build this once. Clone it for each issue instead of rebuilding the newsletter every day.

Step 1 - Create NL | MASTER - Daily Newsletter as an unpublished Segment Email

Use it as the cloning source for each daily broadcast.

Step 2 - Use the permanent section order

• Preheader.
• Forwarded-reader subscribe line.
• Today's Issue.
• Today's Big Idea.
• Your Tiny Mission.
• Barb's Money Finds.
• Featured Find when used.
• Quick Finds.
• Who Needs This Today?
• Read/share the public issue link.
• Barb signoff.
• P.S. for forwarded readers.
• Affiliate disclosure when needed.
• Why you are receiving this.
• Postal address.
• Visible unsubscribe link.

Step 3 - Keep the email simple and readable

• Single-column layout around 600 pixels wide.
• Readable body text around 16 to 18 pixels.
• Large tap targets for important buttons.
• Good contrast.
• ALT text for useful images and empty ALT text for decorative images.
• Do not make the whole email one giant image.
• Make the plain-text version readable.

Step 4 - Keep the HTML under Gmail clipping limits

Aim to keep the HTML code comfortably under 102 KB so Gmail does not clip the bottom of the message, where unsubscribe and legal information often live.

Step 5 - Use safe personalization

If you use a first-name token, include fallback text. Example: {contactfield=firstname|there}. Never let a blank field create a strange greeting.

Step 6 - Keep link tracking on

Mautic should track newsletter links so you can measure real clicks. Only disable tracking on a link when you have a clear reason.

Back to top

Task 15 - Set Up Visible And Header Unsubscribe

The reader needs a clear unsubscribe link in the message, and receiving mail systems need the one-click unsubscribe headers.

Step 1 - Put a visible unsubscribe link in the footer

Use Mautic's unsubscribe token. Since v1.0 has only one newsletter, a custom Preference Center is not needed yet.

Step 2 - Keep Mautic one-click unsubscribe enabled

Do not disable Mautic's unsubscribe headers. Gmail and Yahoo expect proper one-click unsubscribe for subscription mail at applicable sending volumes.

Step 3 - Test with a real Segment Email

Mautic test emails sent to Mautic Users do not behave like real Contact emails. Use NL | Internal Testers for this test.

Step 4 - Add a Mautic 6 scanner safety test

Mautic 6.0.0 had a reported bug where a HEAD request to the one-click unsubscribe URL could set Do Not Contact. Use a disposable test Contact, inspect the List-Unsubscribe URL, make a HEAD request, and confirm that the Contact is not unsubscribed by the HEAD request alone. If it fails, stop launch and fix the Mautic version or unsubscribe behavior first.

Back to top

Task 16 - Confirm WordPress Tracking Is Still Working

You already have WordPress page tracking working. v1.0 should preserve it rather than rebuild it.

Step 1 - Test a fresh private-browser visit

Open a tracked WordPress page in a private browser, then identify yourself with a test form. Confirm that the page history appears on the Contact record.

Step 2 - Do not track your own work as subscriber behavior

Use private browsing and test Contacts for QA. If your WP Mautic settings track logged-in WordPress users, decide whether that is useful or noisy.

Back to top

Task 17 - Build The WordPress Newsletter Home Page

This is the main public signup destination.

Step 1 - Create a permanent newsletter URL

Use a simple permanent location such as /newsletter/.

Step 2 - Keep the page focused

• One clear promise.
• Who the newsletter is for.
• What readers will get.
• How often it arrives.
• The main signup form.
• A Privacy Policy link.

Step 3 - Remove unnecessary exits

Do not crowd the signup page with a large menu, unrelated offers, or a dozen competing buttons.

Step 4 - Test mobile speed and layout

Check the page on a phone and use a speed checker. Slow or awkward signup pages waste the traffic you already earned.

Back to top

Task 18 - Build The Check-Your-Email Page

The first signup form does not mean the person is subscribed yet. This page explains the next step.

Step 1 - Create /newsletter/check-email/

Tell the visitor that one more step is required.

Step 2 - Give simple instructions

• Open the confirmation email.
• Click the confirmation link.
• If it is missing, check Spam or Promotions.
• The newsletter does not start until confirmation is finished.

Back to top

Task 19 - Build The WordPress Confirmation Page

This page holds the second Mautic form and blocks automatic link scanners from completing the subscription on their own.

Step 1 - Create /newsletter/confirm/

Embed NL | Confirm Subscription on this page.

Step 2 - Keep the page extremely simple

• Short confirmation message.
• Email field.
• One clear Yes, subscribe me button.
• No promotional distractions.

Step 3 - Test email prefill

Click the confirmation email as a real test Contact. Confirm the email field prepopulates. If not, the visitor must still be able to type the email manually and continue.

Back to top

Task 20 - Build The Confirmed Page

This page appears only after the second form is successfully submitted.

Step 1 - Create /newsletter/confirmed/

Tell the subscriber they are now on the newsletter list.

Step 2 - Set the next expectation

• Tell them to look for the Welcome email.
• Show the sender address.
• Offer a link to the public newsletter archive.

Back to top

Task 21 - Build The Public Newsletter Archive

Every issue should keep working after the email send is over.

Step 1 - Create /newsletter/issues/

Use a WordPress category, custom post type, or archive method that your existing site can maintain easily.

Step 2 - Make every public issue easy to discover

Show issue title, short description, and a link. Do not turn the archive into a complicated magazine portal in v1.0.

Step 3 - Put a signup opportunity on the archive

Someone who browses old issues should have an obvious way to join.

Back to top

Task 22 - Build The Reusable Public Issue Template

The WordPress issue is the shareable version of each newsletter and a permanent subscriber-acquisition page.

Step 1 - Use one repeatable page structure

• Newsletter identification.
• Issue headline.
• Expanded Big Idea.
• Tiny Mission.
• Inline newsletter signup form.
• Money Finds when appropriate.
• Who Needs This Today?
• Share controls.
• Bottom signup invitation.

Step 2 - Use NL | Signup - Public Issue on the page

Keep the Form on the same page as the shared issue so the v1 UTM attribution has the best chance of being recorded on signup.

Step 3 - Add social sharing metadata

Make sure the page has a good social title, description, and share image so Facebook, LinkedIn, and other services do not produce an ugly blank preview.

Step 4 - Keep the permanent URL stable

Do not change the issue slug after the email has been sent unless you also preserve a redirect.

Back to top

Task 23 - Build The Who Needs This Today Share Box

Sharing should feel like helping a friend, not doing marketing work for Barb.

Step 1 - Write one person-specific prompt

Each issue should help the reader picture a specific person who needs that topic.

Step 2 - Offer a small set of share methods

• Copy link.
• Email.
• Facebook.
• LinkedIn.

Step 3 - Send shares to the public WordPress issue

Do not rely on literal email forwarding as the main sharing method. The public issue has the signup form and tracking.

Back to top

Task 24 - Set The v1.0 UTM Rules

UTMs let you see which issue and which traffic source generated a signup.

Step 1 - Use one permanent campaign name

Step 2 - Use reader-share UTMs

Step 3 - Use social-source UTMs

• Facebook: utm_source=facebook and utm_medium=organic_social.
• LinkedIn: utm_source=linkedin and utm_medium=organic_social.
• Keep utm_campaign=daily_newsletter and use the same issue-specific utm_content value.

Step 4 - Know the v1.0 attribution limit

Mautic's Record UTM Tags action records UTM values present on the page where the Form is submitted. v1.0 does not promise perfect first-touch attribution after a visitor leaves that issue and subscribes somewhere else.

Back to top

Task 25 - Connect The Mautic Forms To WordPress

Use one embedding method consistently so forms are easier to test and maintain.

Step 1 - Prefer the WP Mautic Form shortcode when practical

The WP Mautic plugin supports a shortcode such as [mautic type="form" id="1"]. Use the real Form ID from Mautic.

Step 2 - Verify each Form independently

• Main signup form creates or updates the Contact and sends confirmation.
• Public issue form records UTMs and sends confirmation.
• Footer form sends confirmation.
• Confirmation form removes DNC if needed, adds the confirmed Segment, and sends Welcome.

Step 3 - Check forms after WordPress caching changes

If your site uses caching or optimization plugins, retest the embedded forms after major changes.

Back to top

Task 26 - Update The Privacy And Consent Language

The signup promise and privacy information should match what the system really does.

Step 1 - Explain the newsletter use clearly

The signup form should say that the email address is being used to send the newsletter. Do not hide marketing consent inside unrelated terms.

Step 2 - Link the Privacy Policy from every signup form

Make sure the policy explains the email service, site tracking, and other data use that actually applies to your site.

Step 3 - Use extra consent checkboxes only when they have a real purpose

If you need separate consent for another marketing activity or legal requirement, use a separate clear checkbox. Do not add extra boxes simply because they look official.

Back to top

Task 27 - Create The Core Mautic Reports

v1.0 needs enough reporting to answer whether people joined, clicked, bounced, and unsubscribed.

Step 1 - Create NL | Email Performance

Use Emails or Emails Sent data to review sends, clicks, bounces, and unsubscribes.

Step 2 - Create NL | Signup Forms

Use Form Submissions to compare the Main, Public Issue, Footer, and Confirmation Forms.

Step 3 - Create NL | UTM Sources

Use UTM Codes to compare newsletter, reader_share, Facebook, LinkedIn, and issue-level utm_content values.

Step 4 - Create NL | Public Issue Page Hits

Use Page Hits to compare traffic to public newsletter issues.

Step 5 - Create NL | Do Not Contact And Bounces

Use Do Not Contact and bounce data to watch list health.

Step 6 - Do not automate report delivery yet

Scheduled report emails are useful later, but they are not needed to send Newsletter v1.0.

Back to top

Task 28 - Create Team Users And Roles

Colleagues should have enough access to do their jobs without giving every person the keys to the whole server.

Step 1 - Keep administrator accounts limited

Only people who truly need full system access should have it.

Step 2 - Create a Newsletter Editor role if needed

• View, create, and edit newsletter Emails and Forms as needed.
• Do not grant global configuration access unless required.
• Do not grant database exports unless required.
• Consider limiting delete and activate permissions.

Step 3 - Set the team time zone correctly

Make sure scheduling is not shifted because one User is working in the wrong Mautic time zone.

Back to top

Task 29 - Build The Real Test Contacts

Mautic test emails are not enough. The newsletter must be tested as real Contacts receive it.

Step 1 - Add real inboxes to NL | Internal Testers

• At least one Gmail address.
• At least one Outlook or Microsoft address when available.
• An Apple Mail or iCloud test when available.
• A Yahoo test when available.

Step 2 - Keep testers as Contacts, not only Mautic Users

Mautic says unsubscribe and tracked-link behavior is different in test/example emails sent to Mautic Users.

Step 3 - Use plus-address aliases for repeated signup tests when your mail provider supports them

For example, barb+nltest1@example.com can often arrive in the same inbox while Mautic sees a different address.

Back to top

Task 30 - Run The Deliverability And Header Test

Do this before the first public send.

Step 1 - Send a real Segment Email only to Internal Testers

Do not rely on Send Example.

Step 2 - Inspect the received message headers

• SPF passes.
• DKIM passes.
• DMARC passes.
• From domain alignment looks correct.
• List-Unsubscribe is present when expected.
• List-Unsubscribe-Post shows one-click support.

Step 3 - Run the Mautic 6 HEAD-request safety check

Use only a disposable test Contact. Confirm that an automatic HEAD request does not mark the Contact Do Not Contact.

Step 4 - Click the visible unsubscribe link

Confirm the Contact becomes Do Not Contact for email and does not receive the next marketing Segment Email.

Back to top

Task 31 - Run The Complete Signup Test

Test the whole journey with fresh addresses before asking the public to use it.

Step 1 - Test the Main signup

• Submit the Main Form.
• Confirm the Contact exists in Mautic.
• Confirm source = website-main.
• Confirm consent version = NL-V1.
• Confirm the Contact is NOT yet in NL | Subscribers - Confirmed.
• Confirm the confirmation email arrives.

Step 2 - Complete confirmation

• Click the confirmation email link.
• Confirm the WordPress confirmation page loads.
• Confirm the email field is filled or can be entered manually.
• Submit Yes, subscribe me.
• Confirm the Contact enters NL | Subscribers - Confirmed.
• Confirm the Welcome email arrives.

Step 3 - Repeat through Public Issue and Footer forms

Verify each source value and its UTM behavior independently.

Back to top

Task 32 - Run The Newsletter Layout And Accessibility QA

An email is not finished when it looks good in the builder. It is finished when it works in actual inboxes.

Step 1 - Check the inbox view

• From name is correct.
• Subject is accurate.
• Preheader adds useful information instead of repeating the subject.
• Reply-To is correct.

Step 2 - Check desktop and mobile

• No horizontal scrolling.
• Text is readable without zooming.
• Buttons are easy to tap.
• Images scale correctly.
• Footer remains readable.

Step 3 - Check accessibility

• Logical heading order.
• Useful ALT text.
• Good color contrast.
• Links make sense out of context.
• The message still makes sense when images are blocked.

Step 4 - Check Dark Mode

Make sure important text, buttons, and logos stay readable when an inbox changes the colors.

Step 5 - Check HTML size

Keep the message under 102 KB of HTML code to avoid Gmail clipping.

Step 6 - Check the plain-text version

Make sure it is readable and contains working URLs.

Back to top

Task 33 - Run The Unsubscribe And Resubscribe Test

People change their minds. v1.0 must handle both directions cleanly.

Step 1 - Unsubscribe a confirmed test Contact

Confirm Mautic marks the Contact Do Not Contact and suppresses the next marketing broadcast.

Step 2 - Sign up again through a public form

Test this with a previously unsubscribed Contact on your own Mautic 6 build. The confirmation message must arrive before the person can confirm again. If it does not, stop and fix the resubscribe path before launch.

Step 3 - Confirm again

Submit the confirmation form. Its Remove Contact from Do Not Contact action should restore email permission, and the Contact should remain or return in NL | Subscribers - Confirmed.

Step 4 - Send another test Segment Email

Confirm the resubscribed Contact receives it.

Back to top

Task 34 - Publish The First Public Newsletter Issue

The public issue must exist before the email goes out so every share link works.

Step 1 - Publish the WordPress issue first

Use the reusable public issue template.

Step 2 - Verify the public issue page

• Headline and copy are correct.
• Signup form works.
• Who Needs This Today? is specific.
• Share controls work.
• Social preview title, description, and image look right.
• The page is fast and mobile-friendly.

Step 3 - Create the issue UTM values

Use one consistent issue label such as issue-001-topic-slug across email, reader-share, and social links.

Back to top

Task 35 - Build And Test Newsletter Issue #1 In Mautic

The real issue is cloned from the master and tested before it touches the subscriber list.

Step 1 - Clone NL | MASTER - Daily Newsletter

Name it with a clean internal issue name such as NL | Issue 001 - Topic Name.

Step 2 - Add the public WordPress issue link

Use the newsletter email UTM values on links from the email to WordPress.

Step 3 - Set the receiving Segment

Target only NL | Subscribers - Confirmed for the public broadcast.

Step 4 - Set an unpublish time

Mautic's broadcast cron can send an old Segment Email to Contacts who enter the Segment later while the email is still published. Set an unpublish time before the next issue so a new subscriber does not receive yesterday's broadcast by surprise.

Step 5 - Clone or temporarily retarget a test copy to Internal Testers

Use real Contacts to verify tracking, rendering, unsubscribe, and WordPress links.

Back to top

Task 36 - Send Newsletter Issue #1

This is the final launch gate.

Step 1 - Complete the pre-send checklist

• Subject matches the email.
• Preheader is correct.
• All links work.
• UTMs are correct.
• Public issue is live.
• Signup form on public issue works.
• Unsubscribe works.
• Postal address is present.
• Affiliate disclosure is present when needed.
• Mobile, desktop, and Dark Mode checks passed.
• HTML size is under the clipping limit.
• No placeholder text remains.

Step 2 - Schedule or send to NL | Subscribers - Confirmed

Use the actual Segment Email, not the test copy.

Step 3 - Confirm the send started correctly

Check Mautic for the expected send activity and watch for immediate delivery errors.

Back to top

Task 37 - Review The First Send

The first report is not about proving success. It is about proving the machine works.

Step 1 - Check the basic delivery signals

• Sent.
• Hard bounces.
• Spam complaints if available.
• Unsubscribes.
• Clicks.

Step 2 - Check subscriber growth

• Main signup submissions.
• Public issue submissions.
• Footer submissions.
• Confirmed subscribers.
• UTM source values.

Step 3 - Check the share loop

Look for reader_share UTMs and public issue signups. v1.0 measures issue-level sharing, not which individual subscriber made the referral.

Step 4 - Fix only real problems

If a form, link, header, page, or workflow is broken, fix it. Do not add new feature ideas just because the first issue has been sent.

Back to top

Task 38 - Run The v1.0 Maintenance Routine

A small amount of routine maintenance keeps the system trustworthy.

Step 1 - Before every issue

• Publish and test the public issue.
• Clone the master email.
• Check links and UTMs.
• Send to Internal Testers.
• Check mobile and desktop.
• Set the unpublish time.
• Send to confirmed subscribers.

Step 2 - Weekly

• Review bounces and DNC activity.
• Review clicks and signup sources.
• Check that cron jobs are still running.
• Spot-check WordPress tracking.

Step 3 - Monthly

• Review domain reputation and complaint data where available.
• Back up Mautic.
• Review Mautic security notices and support status.
• Confirm forms and unsubscribe still work.
• Review which public issues produced confirmed subscribers.

Step 4 - Keep v2.0 ideas out of the production checklist

Store future ideas in the v2.0 parking-lot file until the v1.0 machine has enough real data to justify them.

Back to top