## TL;DR
Give every merge tag a fallback default and add a pre-send render check that scans the final email for unreplaced tags. The tag rendered literally because the candidate record had no first name and the template had no fallback, so the raw placeholder went out. Candidates read a literal {first_name} as a phishing tell, which is why the reports followed.

## The error
```text
Hi {first_name}, just following up on the role - the merge tag rendered literally and candidates reported the email as phishing
```

## Steps
1. Pause the campaign and pull a sample of sent emails to confirm which tags rendered raw.
   Expected: you see exactly which fields were empty (first name, company, and so on).
2. Add fallback defaults to every merge tag in the template (fall back to a neutral greeting or drop the clause when the name is missing).
   Expected: rendering a record with empty fields produces clean, grammatical text.
3. Add a pre-send check that renders each email and scans for unreplaced tag patterns before it is allowed to send.
   Expected: any email with a raw tag is blocked and logged, never sent.
4. Backfill the missing fields where you can (re-parse the resume, check the ATS record) so fallbacks stay the exception.
   Expected: fallback usage drops to near zero on the next send.
5. Send test renders to seed inboxes covering every empty-field combination.
   Expected: all test emails read naturally with no raw tags.

## Use this when
- An agent sends templated emails with merge tags or personalization fields
- Recipients report seeing raw placeholders in the email
- Phishing reports spike on an outreach campaign

## Not for this skill when
- The tags render fine but engagement is low (that is a copy and targeting problem)
- The email client is mangling formatting (check HTML versus plain-text rendering instead)
- Personalization comes from an LLM writing free text (then the fix is output validation, not tag fallbacks)

## Variant phrasings
- merge tag rendered literally in outreach email
- {first_name} showing raw in candidate emails
- personalization placeholder not replaced, reported as phishing
- email template tags showing in sent emails

## Why it happens
The template assumed every record had every field. When the parser missed a first name or the source profile had none, the tag had nothing to substitute and the raw placeholder shipped. Recipients have been trained that a literal {first_name} means a mass phishing blast, so the deliverability damage goes beyond one awkward email.

## Edge cases
- Nested or conditional tags: test the fallback inside every conditional branch, not just the top level.
- Encoding: some parsers store names with odd characters; sanitize before rendering.
- Localization: fallbacks must read naturally in every language the template ships in.
- Audit the whole template library: one broken tag usually means siblings have the same missing fallback.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QDbGRQEn6376c_8R5MC09w