site(learn): remove em dashes from all learn subpages

site/src/pages/learn/cold-email-rules.astro

@@ -3,7 +3,7 @@ import Learn from '../../layouts/Learn.astro';
 ---
 <Learn
   title="Cold email rules across regions"
-  description="CAN-SPAM, GDPR, CASL, PECR — what each actually says, and how to send cold mail compliantly without hiring a lawyer."
+  description="CAN-SPAM, GDPR, CASL, PECR. what each actually says, and how to send cold mail compliantly without hiring a lawyer."
   reading="10 min read"
   updated="2026-05-02"
 >
@@ -15,7 +15,7 @@ import Learn from '../../layouts/Learn.astro';
     This guide is general information, not legal advice. If you're sending at scale to regulated jurisdictions, run your specific approach past counsel.
   </p>
 
-  <h2>United States — CAN-SPAM (2003)</h2>
+  <h2>United States. CAN-SPAM (2003)</h2>
   <p>
     CAN-SPAM applies to "commercial electronic mail messages". It does <em>not</em> require prior consent for cold B2B email. It does require:
   </p>
@@ -30,7 +30,7 @@ import Learn from '../../layouts/Learn.astro';
     For Warmbly's defaults, this means: include a physical address in your sender profile, never spoof a name or domain, and ensure unsubscribe replies are auto-suppressed.
   </p>
 
-  <h2>European Union and UK — GDPR + PECR</h2>
+  <h2>European Union and UK. GDPR + PECR</h2>
   <p>
     GDPR applies to personal data of EU/UK residents. PECR (in the UK) and ePrivacy directives in EU member states specifically cover electronic marketing.
   </p>
@@ -57,7 +57,7 @@ import Learn from '../../layouts/Learn.astro';
     Keep a record of where you sourced each contact and the legitimate interest you relied on. Warmbly's contact import wizard captures source and import notes for exactly this.
   </p>
 
-  <h2>Canada — CASL (2014)</h2>
+  <h2>Canada. CASL (2014)</h2>
   <p>
     CASL is the strictest of the major regimes. It requires <em>express or implied consent</em> before sending commercial electronic messages to Canadian recipients.
   </p>
@@ -68,7 +68,7 @@ import Learn from '../../layouts/Learn.astro';
     Every message must include sender identification, contact info, and a working unsubscribe. Penalties for non-compliance can reach CAD $10M per violation for organisations.
   </p>
 
-  <h2>Australia — Spam Act 2003</h2>
+  <h2>Australia. Spam Act 2003</h2>
   <p>
     Requires consent (express, inferred or implied), accurate sender identification and a functional unsubscribe. Inferred consent is generous for B2B but not consumer marketing.
   </p>
@@ -77,11 +77,11 @@ import Learn from '../../layouts/Learn.astro';
   <ol>
     <li>Use a real From: name and a domain you actually own.</li>
     <li>Include a physical mailing address in your sender profile / footer.</li>
-    <li>Provide a clear opt-out — "Reply STOP to opt out" or a one-click link.</li>
+    <li>Provide a clear opt-out. "Reply STOP to opt out" or a one-click link.</li>
     <li>Auto-suppress recipients who opt out, across all future sequences and campaigns.</li>
     <li>Record where each contact was sourced and your basis for contacting them.</li>
     <li>Only contact role accounts and named business addresses for B2B; avoid personal addresses unless you have explicit consent.</li>
-    <li>Customise the message for relevance — boilerplate to thousands of strangers is the loudest possible compliance and reputation risk.</li>
+    <li>Customise the message for relevance. boilerplate to thousands of strangers is the loudest possible compliance and reputation risk.</li>
     <li>Skip Canadian and EU consumer-mail recipients unless you have documented consent.</li>
     <li>Honour opt-outs within 24 hours, not the legal maximum.</li>
     <li>If you operate a privacy policy, link to it from your footer.</li>

site/src/pages/learn/email-warmup.astro

@@ -12,12 +12,12 @@ import Learn from '../../layouts/Learn.astro';
     Warmup is the practice of sending small, conversational volumes of mail from a new (or recently dormant) mailbox to gradually build a positive reputation with mailbox providers like Google, Microsoft, Yahoo and Apple. The goal isn't a one-off score. It's a track record. Mailbox providers reward consistency.
   </p>
   <p>
-    Modern warmup tools generate this traffic between participating mailboxes — your mailbox sends short, plain-text messages to other warmed mailboxes, those mailboxes open and reply, and the cycle repeats. Done well, the pattern looks like a real human starting to use a new inbox.
+    Modern warmup tools generate this traffic between participating mailboxes. your mailbox sends short, plain-text messages to other warmed mailboxes, those mailboxes open and reply, and the cycle repeats. Done well, the pattern looks like a real human starting to use a new inbox.
   </p>
 
   <h2>Why providers care about it</h2>
   <p>
-    Inbox placement is reputation-driven. When a brand-new domain or mailbox starts sending dozens of cold messages to strangers, Gmail and Outlook treat it as suspicious by default. They don't know whether you're a small startup or a spammer. The safest assumption — for them — is spammer.
+    Inbox placement is reputation-driven. When a brand-new domain or mailbox starts sending dozens of cold messages to strangers, Gmail and Outlook treat it as suspicious by default. They don't know whether you're a small startup or a spammer. The safest assumption. for them. is spammer.
   </p>
   <p>
     Warmup gives them signal. Mailboxes that send small volumes, get opens, get replies, and don't trigger complaints look like real human inboxes. Providers loosen the screws as that pattern persists.
@@ -26,7 +26,7 @@ import Learn from '../../layouts/Learn.astro';
   <h2>What good warmup looks like</h2>
   <h3>Gradual volume growth</h3>
   <p>
-    Start low and ramp slowly. Warmbly's defaults are 10 emails per day to start, +1 per day, with a ceiling of 40 per day. That ceiling exists on purpose — warmup that climbs to 100/day looks unnatural and starts to look like a bot.
+    Start low and ramp slowly. Warmbly's defaults are 10 emails per day to start, +1 per day, with a ceiling of 40 per day. That ceiling exists on purpose. warmup that climbs to 100/day looks unnatural and starts to look like a bot.
   </p>
 
   <h3>Realistic spacing</h3>
@@ -41,7 +41,7 @@ import Learn from '../../layouts/Learn.astro';
 
   <h3>Quality recipients</h3>
   <p>
-    Warmup recipients should be other warmed, healthy mailboxes — not free trial mailboxes, not throwaways, not lookalikes of catch-all domains. Pool quality matters more than pool size.
+    Warmup recipients should be other warmed, healthy mailboxes. not free trial mailboxes, not throwaways, not lookalikes of catch-all domains. Pool quality matters more than pool size.
   </p>
 
   <h3>Token verification</h3>
@@ -52,7 +52,7 @@ import Learn from '../../layouts/Learn.astro';
   <h2>What bad warmup looks like</h2>
   <ul>
     <li><strong>Synthetic blasting:</strong> sending 200 identical messages a day to the same handful of recipients. Looks great on a vendor dashboard. Looks awful to Gmail.</li>
-    <li><strong>Throwaway pools:</strong> generating recipient mailboxes from free providers on the fly. Providers know what disposable inboxes look like and weight signals from them at zero — or worse.</li>
+    <li><strong>Throwaway pools:</strong> generating recipient mailboxes from free providers on the fly. Providers know what disposable inboxes look like and weight signals from them at zero. or worse.</li>
     <li><strong>Open/click theatre:</strong> simulating opens and clicks at unrealistic rates. Apple Mail Privacy already pollutes open rates; pumping the number from a bot makes the entire signal worthless.</li>
     <li><strong>Stopping at "ready":</strong> many tools stop warmup the moment campaigns begin. Reputation has to be maintained, not earned once and forgotten.</li>
   </ul>
@@ -62,7 +62,7 @@ import Learn from '../../layouts/Learn.astro';
     Domain warmup commonly takes 3–6 weeks to reach a stable state. New domains take longer than re-warming an existing one. New mailboxes on warmed domains often stabilise within a week or two if the domain reputation is already healthy.
   </p>
   <p>
-    What matters is not <em>finishing</em> warmup — it's running it indefinitely at a low volume in parallel with your cold sending, so any reputation dip is caught and offset before campaigns hit it.
+    What matters is not <em>finishing</em> warmup. it's running it indefinitely at a low volume in parallel with your cold sending, so any reputation dip is caught and offset before campaigns hit it.
   </p>
 
   <h2>Free pools vs paid pools</h2>
@@ -70,7 +70,7 @@ import Learn from '../../layouts/Learn.astro';
     Free warmup pools are useful for testing but mix higher-risk participants. Paid pools should be stricter: only vetted, monitored mailboxes participate, and misbehaving senders are quarantined fast.
   </p>
   <p>
-    In Warmbly, free-tier mailboxes never silently appear in the premium pool. Even dedicated-worker customers participate in the premium pool by default — dedicated infrastructure isn't a reputation shortcut, it's an isolation tool.
+    In Warmbly, free-tier mailboxes never silently appear in the premium pool. Even dedicated-worker customers participate in the premium pool by default. dedicated infrastructure isn't a reputation shortcut, it's an isolation tool.
   </p>
 
   <h2>When to quarantine a mailbox</h2>
@@ -81,7 +81,7 @@ import Learn from '../../layouts/Learn.astro';
     <li><strong>Watch:</strong> spam placement ≥ 10% over a 20-delivery sample. Lower volume, increase spacing.</li>
     <li><strong>Quarantine:</strong> spam placement ≥ 20%, or complaint rate ≥ 0.10%, or bounce rate ≥ 5%. 7-day removal from the paid pool.</li>
     <li><strong>Block:</strong> spam placement ≥ 40%, or complaint rate ≥ 0.30%. 30-day block, manual review to re-enter.</li>
-    <li><strong>Catastrophic:</strong> spam placement ≥ 80%. Long block plus reputation reset — no automatic re-entry.</li>
+    <li><strong>Catastrophic:</strong> spam placement ≥ 80%. Long block plus reputation reset. no automatic re-entry.</li>
   </ul>
 
   <h2>Practical checklist</h2>

site/src/pages/learn/inbox-placement.astro

@@ -9,7 +9,7 @@ import Learn from '../../layouts/Learn.astro';
 >
   <h2>Delivery vs placement</h2>
   <p>
-    Most cold-email tools report "delivery rate" — the percentage of messages that the receiving SMTP server accepted. That number is almost always close to 100% and tells you almost nothing.
+    Most cold-email tools report "delivery rate". the percentage of messages that the receiving SMTP server accepted. That number is almost always close to 100% and tells you almost nothing.
   </p>
   <p>
     A receiving server can accept a message (delivery) and then immediately filter it into Spam, Promotions, or out of the inbox entirely. Placement is the share of accepted messages that land in the recipient's primary inbox.
@@ -21,7 +21,7 @@ import Learn from '../../layouts/Learn.astro';
   <h2>How placement is measured</h2>
   <h3>Warmup probes</h3>
   <p>
-    Warmbly's warmup pool is also a placement probe. Pool members report where each warmup message arrived — inbox, spam, promotions. We aggregate per sending mailbox over a rolling sample window.
+    Warmbly's warmup pool is also a placement probe. Pool members report where each warmup message arrived. inbox, spam, promotions. We aggregate per sending mailbox over a rolling sample window.
   </p>
   <p>
     Probe accuracy depends on pool diversity. A pool that only contains Gmail addresses can't tell you anything about Outlook placement. Our premium pool spans Gmail, Outlook, Yahoo, iCloud and self-hosted IMAP servers in proportion to the broader receiver landscape.
@@ -29,7 +29,7 @@ import Learn from '../../layouts/Learn.astro';
 
   <h3>Seed lists</h3>
   <p>
-    Some teams maintain a "seed list" — a fixed set of mailboxes across providers that always receive a copy of every campaign send. The placement on the seed list approximates placement for the full campaign.
+    Some teams maintain a "seed list". a fixed set of mailboxes across providers that always receive a copy of every campaign send. The placement on the seed list approximates placement for the full campaign.
   </p>
   <p>
     Seed lists are useful but not free of bias. They tend to be older, more engaged inboxes than your real cold recipients. Treat them as a directional signal.
@@ -45,7 +45,7 @@ import Learn from '../../layouts/Learn.astro';
     <li>Unauthenticated mail (missing or misaligned SPF, DKIM, DMARC).</li>
     <li>Sudden volume spikes from an otherwise quiet mailbox.</li>
     <li>Cold mail with heavy HTML, unsolicited attachments, or tracking-pixel-only bodies.</li>
-    <li>Word-for-word identical content across thousands of sends — content fingerprinting catches it.</li>
+    <li>Word-for-word identical content across thousands of sends. content fingerprinting catches it.</li>
     <li>Long URLs to suspicious TLDs, or URL shorteners that have been abused.</li>
     <li>Recipients consistently deleting without opening.</li>
     <li>Recipients marking as spam (the worst signal of all).</li>
@@ -55,10 +55,10 @@ import Learn from '../../layouts/Learn.astro';
   <ul>
     <li>Plain text bodies for cold sequences.</li>
     <li>Sensible volume relative to historical baseline for the mailbox.</li>
-    <li>Real replies from real recipients — this is the strongest positive signal.</li>
+    <li>Real replies from real recipients. this is the strongest positive signal.</li>
     <li>Variation in subject and opening line across recipients.</li>
     <li>Tight, well-targeted contact lists. Sending to obviously-bad addresses (parsed from web pages, role accounts, etc.) inflates bounces and complaint risk.</li>
-    <li>Consistent sending pattern — same business hours every day, with weekends off.</li>
+    <li>Consistent sending pattern. same business hours every day, with weekends off.</li>
   </ul>
 
   <h2>Targets to aim for</h2>

site/src/pages/learn/reputation-recovery.astro

@@ -31,7 +31,7 @@ import Learn from '../../layouts/Learn.astro';
     <li><strong>DKIM:</strong> selector resolves? Key length ≥ 1024? Rotated within the last year?</li>
     <li><strong>DMARC:</strong> exists? Aligned? Reporting address receives mail? Policy appropriate for your maturity?</li>
     <li><strong>PTR:</strong> sending IP has a reverse DNS record that resolves back?</li>
-    <li><strong>Mailbox content:</strong> last 90 days of sent mail — any HTML-heavy, image-only, or link-bait messages?</li>
+    <li><strong>Mailbox content:</strong> last 90 days of sent mail. any HTML-heavy, image-only, or link-bait messages?</li>
   </ol>
   <p>
     Fix anything that's broken before you start the volume work. Recovery on a misconfigured domain is futile.
@@ -56,7 +56,7 @@ import Learn from '../../layouts/Learn.astro';
   <ul>
     <li>Recipients who replied positively in the past 6 months.</li>
     <li>Contacts at organisations you have customer relationships with.</li>
-    <li>Subscribers (newsletter, podcast, blog) — addresses you've already had positive engagement from.</li>
+    <li>Subscribers (newsletter, podcast, blog). addresses you've already had positive engagement from.</li>
   </ul>
   <p>
     Reply-rich first sends rebuild engagement signal fast. Cold sends to brand-new contact lists during recovery are the easiest way to undo the work.
@@ -77,7 +77,7 @@ import Learn from '../../layouts/Learn.astro';
     If after 8 weeks of disciplined recovery the mailbox still hovers below 80% placement, the address has likely picked up reputation damage that won't reverse. Options:
   </p>
   <ul>
-    <li>Retire the mailbox and create a new one on the same domain — re-warm from scratch.</li>
+    <li>Retire the mailbox and create a new one on the same domain. re-warm from scratch.</li>
     <li>Move cold sending to a new sub-domain (e.g. <code>outreach2.acme.com</code>) and start with fresh SPF/DKIM/DMARC.</li>
     <li>If the whole domain is the problem, register a new sending sub-domain and warm it for 6 weeks before reusing.</li>
   </ul>

site/src/pages/learn/spf-dkim-dmarc.astro

@@ -19,20 +19,20 @@ import Learn from '../../layouts/Learn.astro';
     SPF answers the first. DKIM answers both. DMARC ties the answers to the visible "From" address and tells the receiver what to do if anything is off.
   </p>
 
-  <h2>SPF — Sender Policy Framework</h2>
+  <h2>SPF. Sender Policy Framework</h2>
   <p>
     SPF is a TXT record on your sending domain that lists the servers and services allowed to send mail "on behalf" of you. Receivers check the SMTP envelope sender ("MAIL FROM") domain against your SPF record.
   </p>
   <p>An example for a domain that sends through Google Workspace and Warmbly:</p>
   <pre><code>v=spf1 include:_spf.google.com include:spf.warmbly.com ~all</code></pre>
   <ul>
-    <li><code>v=spf1</code> — version.</li>
-    <li><code>include:</code> — defer to another SPF record (Google's, ours).</li>
-    <li><code>~all</code> — softfail anything not listed. Receivers downgrade reputation but may still deliver.</li>
+    <li><code>v=spf1</code>. version.</li>
+    <li><code>include:</code>. defer to another SPF record (Google's, ours).</li>
+    <li><code>~all</code>. softfail anything not listed. Receivers downgrade reputation but may still deliver.</li>
   </ul>
   <p><strong>Watch out for:</strong> the 10 DNS lookup limit. Every <code>include:</code> counts. Stack too many and SPF returns PermError, which DMARC treats as fail.</p>
 
-  <h2>DKIM — DomainKeys Identified Mail</h2>
+  <h2>DKIM. DomainKeys Identified Mail</h2>
   <p>
     DKIM signs outgoing mail with a cryptographic signature. The signature lives in a header; the public key lives in DNS under a "selector". When a receiver gets your message, it fetches your public key, verifies the signature, and confirms the message wasn't altered in flight.
   </p>
@@ -42,7 +42,7 @@ import Learn from '../../layouts/Learn.astro';
     The <code>google._</code> part is the selector. You'll have one per sending service, so different providers don't trample each other's keys. Use 2048-bit keys when the provider supports them; 1024 is the minimum.
   </p>
 
-  <h2>DMARC — the policy that ties it together</h2>
+  <h2>DMARC. the policy that ties it together</h2>
   <p>
     DMARC sits on top of SPF and DKIM. It does three things:
   </p>
@@ -54,10 +54,10 @@ import Learn from '../../layouts/Learn.astro';
   <p>A starter DMARC record at <code>_dmarc.acme.com</code>:</p>
   <pre><code>v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.com; ruf=mailto:dmarc-reports@acme.com; pct=100; aspf=r; adkim=r</code></pre>
   <ul>
-    <li><code>p=none</code> — monitor only. Start here.</li>
-    <li><code>rua</code> — aggregate report mailbox.</li>
-    <li><code>ruf</code> — forensic report mailbox.</li>
-    <li><code>aspf=r</code>, <code>adkim=r</code> — relaxed alignment. <code>s</code> is strict.</li>
+    <li><code>p=none</code>. monitor only. Start here.</li>
+    <li><code>rua</code>. aggregate report mailbox.</li>
+    <li><code>ruf</code>. forensic report mailbox.</li>
+    <li><code>aspf=r</code>, <code>adkim=r</code>. relaxed alignment. <code>s</code> is strict.</li>
   </ul>
 
   <h3>Alignment in plain English</h3>
@@ -84,19 +84,19 @@ import Learn from '../../layouts/Learn.astro';
 
   <h2>Common mistakes</h2>
   <ul>
-    <li>Multiple SPF records on the same domain — receivers treat that as PermError. There must be exactly one SPF record.</li>
+    <li>Multiple SPF records on the same domain. receivers treat that as PermError. There must be exactly one SPF record.</li>
     <li>Forgetting <code>include:</code> for a new sending service. Mail still leaves; reputation slowly tanks.</li>
     <li>1024-bit DKIM keys never rotated. Mailbox providers are starting to penalise stale keys.</li>
-    <li>DMARC <code>p=reject</code> on a domain with services you forgot about — legitimate mail starts disappearing.</li>
+    <li>DMARC <code>p=reject</code> on a domain with services you forgot about. legitimate mail starts disappearing.</li>
     <li>Cold mail from your transactional domain. Reputation issues bleed across.</li>
   </ul>
 
   <h2>Recommended sub-domain pattern</h2>
   <p>For a company at <code>acme.com</code>:</p>
   <ul>
-    <li><code>acme.com</code> — transactional and human mail. DMARC reject after rollout.</li>
-    <li><code>outreach.acme.com</code> — cold campaigns. Its own SPF, DKIM, DMARC.</li>
-    <li><code>news.acme.com</code> — newsletters. Separate authentication and reputation.</li>
+    <li><code>acme.com</code>. transactional and human mail. DMARC reject after rollout.</li>
+    <li><code>outreach.acme.com</code>. cold campaigns. Its own SPF, DKIM, DMARC.</li>
+    <li><code>news.acme.com</code>. newsletters. Separate authentication and reputation.</li>
   </ul>
   <p>
     The sub-domain pattern keeps cold reputation issues from contaminating the inboxes you use to run the company. It also lets you change cold-email providers without disturbing transactional mail.

site/src/pages/learn/warmup-pools.astro

@@ -12,7 +12,7 @@ import Learn from '../../layouts/Learn.astro';
     A warmup pool is a group of mailboxes that send warmup mail to one another. Your mailbox sends a short message to another mailbox in the pool. That mailbox opens it, sometimes replies, and the pattern reverses with mail from another pool member.
   </p>
   <p>
-    From a mailbox provider's point of view, the pattern looks like normal individual mailbox activity — low volume, conversational, mixed senders.
+    From a mailbox provider's point of view, the pattern looks like normal individual mailbox activity. low volume, conversational, mixed senders.
   </p>
 
   <h2>Why pool quality matters more than size</h2>
@@ -46,7 +46,7 @@ import Learn from '../../layouts/Learn.astro';
     <li>Never silently mix free-tier mailboxes into the premium recipient set.</li>
   </ul>
   <p>
-    In Warmbly, free and premium pools are physically separated. Dedicated-worker customers still participate in the premium pool by default — dedicated infrastructure is for isolation and IP control, not a reputation shortcut.
+    In Warmbly, free and premium pools are physically separated. Dedicated-worker customers still participate in the premium pool by default. dedicated infrastructure is for isolation and IP control, not a reputation shortcut.
   </p>
 
   <h2>What "dedicated" should mean</h2>
@@ -62,7 +62,7 @@ import Learn from '../../layouts/Learn.astro';
   <ul>
     <li>Bypass per-mailbox health rules.</li>
     <li>Let you ignore complaint or bounce thresholds.</li>
-    <li>Magically warm a brand-new IP — dedicated IPs need their own warmup ramp.</li>
+    <li>Magically warm a brand-new IP. dedicated IPs need their own warmup ramp.</li>
   </ul>
 
   <h2>Re-entry after quarantine</h2>