email-deliverability
Make sure email actually reaches inboxes. Use this skill when setting up email authentication (SPF, DKIM, DMARC), diagnosing emails landing in spam, planning a domain reputation strategy, monitoring sender reputation, or hardening against email spoofing. Triggers on email deliverability, SPF, DKIM, DMARC, spam folder, sender reputation, mailbox provider, soft bounces, bounce rate, BIMI, MTA-STS, deliverability audit. Also triggers when a marketing or transactional email isn't reaching users.
Works with
--- name: email-deliverability description: Make sure email actually reaches inboxes. Use this skill when setting up email authentication (SPF, DKIM, DMARC), diagnosing emails landing in spam, planning a domain reputation strategy, monitoring sender reputation, or hardening against email spoofing. Triggers on email deliverability, SPF, DKIM, DMARC, spam folder, sender reputation, mailbox provider, soft bounces, bounce rate, BIMI, MTA-STS, deliverability audit. Also triggers when a marketing or transactional email isn't reaching users. license: MIT --- # Email Deliverability Get email into inboxes, not spam folders. Set up authentication. Monitor reputation. Diagnose problems before they hurt the business. --- ## When to use - Setting up email for a new domain - A meaningful percentage of email is going to spam - Customers report they're not receiving emails - Setting up DMARC, SPF, or DKIM - Hardening against domain spoofing - Migrating email service providers - Sender reputation has dropped - Pre-launch audit before sending volume increases ## When NOT to use - Writing the email content itself (use `email-sequences`) - Designing the email program strategy (use `email-sequences`) - DNS records in general (use `domain-strategy`) - Outbound spam coming FROM your account (different problem; investigate compromised credentials) --- ## Required inputs - The sending domain(s) - The email service provider (ESP, transactional service, mail server) - Current DNS records (or access to them) - Email volume (transactional vs marketing, daily volume) - Current deliverability state (if known: bounce rate, spam complaints) --- ## The framework: 3 pillars Email deliverability rests on three pillars. Weakness in any one limits the others. ### Pillar 1: Authentication Mailbox providers verify email is actually from who it claims to be from. Three records. **SPF (Sender Policy Framework)** Lists which servers are authorized to send mail for the domain. Published as a TXT record at the apex. ``` v=spf1 include:_spf.mailprovider.com -all ``` - `include:` adds another sender's authorized list - `-all` (hard fail): mail from unlisted senders fails authentication - `~all` (soft fail): unlisted senders are suspicious but pass; useful during rollout - `+all`: never use; allows anyone to send Only one SPF record per domain. Multiple SPF records break SPF entirely. Combine senders into a single record. SPF has a 10-DNS-lookup limit. Each `include:` may use multiple lookups. Hit the limit and SPF stops working. Watch this carefully. **DKIM (DomainKeys Identified Mail)** A cryptographic signature on each outgoing email. The mail server signs with a private key; the public key is published in DNS. ``` selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0G..." ``` Selectors differ by ESP. Some use `default._domainkey`, some use unique selectors per service. Most ESPs walk you through publishing the records. DKIM proves the message wasn't modified in transit and that the sender controls the domain. **DMARC (Domain-based Message Authentication, Reporting, and Conformance)** The policy layer. Tells receivers what to do when SPF or DKIM fails, and where to send reports. ``` _dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-aggregate@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; adkim=s; aspf=s" ``` Components: - `p=`: policy. `none`, `quarantine`, or `reject`. - `rua=`: aggregate reports (daily, summary). Always set this. - `ruf=`: forensic reports (per-message). Optional, can be high volume. - `pct=`: percentage of failing mail subject to the policy. Useful for gradual rollout. - `adkim=`, `aspf=`: alignment mode. `s` (strict), `r` (relaxed). Strict means From: domain must match exactly. DMARC is the most important record. It's what makes spoofing your domain hard. ### Pillar 2: Reputation Mailbox providers (Gmail, Outlook, Yahoo) score every sender. Reputation drives delivery. Reputation factors: - **Authentication pass rates** (SPF, DKIM, DMARC) - **Engagement signals** (opens, replies, marking as not-spam) - **Negative signals** (spam complaints, deletions without opens, blocking) - **List hygiene** (low bounce rates, no spam traps) - **Volume consistency** (sudden spikes look like spam) - **Content patterns** (link reputation, attachment patterns) - **IP and domain history** Reputation is per (sending domain × mailbox provider). Gmail's view of you is independent of Outlook's. ### Pillar 3: List quality and engagement Authentication and reputation rest on list quality. Bad list = bad reputation eventually. - Only send to people who explicitly opted in - Confirmed (double) opt-in for marketing wherever feasible - Honor unsubscribes immediately and reliably - Remove hard bounces immediately - Sunset disengaged contacts (no opens in 6 months: reduce frequency or remove) - Avoid third-party lists, scraped emails, or "purchased opt-ins" The single biggest deliverability lever for most senders is list hygiene. --- ## Workflow ### Step 1: Audit current state Check the current DNS records: ```bash dig +short txt example.com dig +short txt selector1._domainkey.example.com dig +short txt _dmarc.example.com ``` Also check: - Current bounce rate (target: under 2%) - Current spam complaint rate (target: under 0.1%) - Current open rate (varies by industry; falling trend is a warning) - Current sending volume Tools: mxtoolbox.com, dmarcian.com, mail-tester.com (for individual messages). ### Step 2: Fix authentication If any of SPF, DKIM, DMARC is missing or misconfigured, fix first. **SPF fix order:** 1. Identify all legitimate senders (transactional ESP, marketing ESP, support tools, etc.) 2. Get the `include:` value or IP for each 3. Combine into a single SPF record 4. Verify lookup count is under 10 5. Use `-all` for hard fail (or `~all` if rolling out gradually) **DKIM fix order:** 1. Generate a new selector per sending service 2. Publish the public key in DNS 3. Configure the ESP to sign with the private key 4. Verify with a test send (check headers for `dkim=pass`) **DMARC fix order:** 1. Publish DMARC with `p=none` initially (monitoring mode) 2. Set up an aggregate report endpoint (use a DMARC analytics service or your own) 3. Watch reports for at least 2-4 weeks 4. Identify any legitimate senders failing alignment; fix them 5. Move to `p=quarantine` with `pct=10`, gradually increase 6. Move to `p=reject` once confidence is high The full progression typically takes 2-3 months. Rushing causes legitimate mail to bounce. ### Step 3: Set up monitoring Ongoing visibility: - **DMARC aggregate reports**: parsed daily. Watch for new sources, alignment failures, volume changes. - **Bounce rate**: per ESP dashboard. Target under 2% for transactional, under 5% for marketing. - **Spam complaint rate**: target under 0.1%. - **Reputation tools**: Google Postmaster Tools (free), Microsoft SNDS, Talos, Sender Score. - **Blacklist monitoring**: most ESPs include this; otherwise mxtoolbox.com or hetrixtools.com. ### Step 4: Address list hygiene - Remove hard bounces from your sending lists immediately (most ESPs do this; verify) - Set up suppression lists (unsubscribes, manual blocks, deliverability sinkholes) - Sunset disengaged contacts (re-engagement campaigns or just remove) - Review opt-in flows: do people know what they're signing up for? ### Step 5: Content and pattern audit If reputation is good and authentication passes, check content: - HTML-only emails (no plain-text alternative) raise flags - Heavy image-to-text ratios raise flags - Suspicious link patterns (bare IPs, URL shorteners, hijacked domains) - Specific spam-trigger words in subject lines (less important than it used to be, still real) - Lots of mismatched domains in URLs - Generic from-name like "info@" rather than a real-sounding sender ### Step 6: Plan for growth Email volume affects reputation. Sudden spikes look like spam. - Warm up new sending IPs gradually (start at 50/day, 2x daily) - Warm up new domains gradually (similar pattern) - Spread sends throughout the day - Don't switch ESPs the week before a big launch ### Step 7: Set up BIMI (optional but valuable) BIMI (Brand Indicators for Message Identification) shows your logo next to authenticated emails in supporting clients (Gmail, Apple Mail, Yahoo, others). Requires: - DMARC at `p=quarantine` or `p=reject` (so this comes after the DMARC progression) - A trademarked logo as an SVG (specific format requirements) - A Verified Mark Certificate (VMC) from a CA, for Gmail and others - A `_bimi` DNS record pointing to the SVG and VMC BIMI improves trust signals and engagement. Worth doing once DMARC enforcement is in place. ### Step 8: Document and revisit Document the email architecture: - Sending domains and subdomains - Each ESP and what it sends - DNS records for each - Monitoring setup - Escalation if deliverability degrades Revisit quarterly or when a new ESP is added. --- ## Failure patterns **Multiple SPF records.** Two or more SPF records on the same domain breaks SPF. Combine into one. **SPF DNS lookup limit exceeded.** Too many `include:` directives or chained includes. Flatten or simplify. **DMARC at `p=none` forever.** Monitoring without enforcement. Spoofing remains easy. Move to enforcement. **DMARC at `p=reject` too quickly.** Legitimate mail bounces because alignment wasn't verified. Use the gradual rollout. **Sending from a different domain than the From: address.** Causes alignment failures. Fix the From: domain or ensure proper alignment. **Using a shared ESP IP without ESP-specific configuration.** Some ESPs don't sign with your DKIM by default; the signature is the ESP's, not yours. Configure custom DKIM. **Sending from a domain that also sends marketing.** A spam complaint on a marketing email hurts transactional deliverability. Use a subdomain for transactional (`transactional.example.com`) or marketing (`mail.example.com`). **No bounce monitoring.** Hard bounces accumulate, reputation tanks, deliverability cliff-falls. Monitor. **Bought lists or scraped contacts.** Spam traps in those lists destroy reputation. Don't. **No double opt-in for marketing.** Single opt-in lets bots and typos onto the list. Bots generate spam complaints, destroy reputation. **Ignoring DMARC reports.** Reports show problems early. Set up a parser. Look weekly. **Treating "marked as not-spam" as the goal.** The goal is to never land in spam in the first place. Once reputation is bad, recovery takes months. --- ## Output format A deliverability audit document includes: - **Domain inventory:** every sending domain - **Authentication status:** SPF, DKIM, DMARC per domain - **Sender inventory:** every ESP or service that sends mail, what's configured - **Reputation status:** per major mailbox provider where measurable - **List hygiene:** bounce rate, complaint rate, opt-in process - **Findings:** prioritized issues - **Roadmap:** SPF/DKIM/DMARC fixes, BIMI plan, monitoring plan - **Monitoring setup:** what's watched, where alerts go --- ## Reference files - [`references/dmarc-rollout-playbook.md`](references/dmarc-rollout-playbook.md): Step-by-step for moving from no DMARC to `p=reject`, with timing, monitoring, and how to handle problems found along the way.
More Security skills
azure-cost
microsoft/azure-skills
Azure cost management: query costs, forecast spending, optimize to reduce waste. WHEN: \"Azure costs\", \"Azure bill\", \"cost breakdown\", \"how much am I spending\", \"forecast spending\", \"optimize costs\", \"reduce spending\", \"orphaned resources\", \"rightsize VMs\", \"cost spike\", \"reduce storage costs\", \"AKS cost\". DO NOT USE FOR: deploying resources, provisioning, diagnostics, or security audits.
entra-app-registration
microsoft/azure-skills
Guides Microsoft Entra ID app registration, OAuth 2.0 authentication, and MSAL integration. USE FOR: create app registration, register Azure AD app, configure OAuth, set up authentication, add API permissions, generate service principal, MSAL example, console app auth, Entra ID setup, Azure AD authentication. DO NOT USE FOR: Key Vault secrets (use azure-keyvault-expiration-audit), general Azure resource security guidance.
azure-messaging
microsoft/azure-skills
Troubleshoot and resolve issues with Azure Messaging SDKs for Event Hubs and Service Bus. Covers connection failures, authentication errors, message processing issues, and SDK configuration problems. WHEN: event hub SDK error, service bus SDK issue, messaging connection failure, AMQP error, event processor host issue, message lock lost, message lock expired, lock renewal, lock renewal batch, send timeout, receiver disconnected, SDK troubleshooting, azure messaging SDK, event hub consumer, service bus queue issue, topic subscription error, enable logging event hub, service bus logging, eventhub python, servicebus java, eventhub javascript, servicebus dotnet, event hub checkpoint, event hub not receiving messages, service bus dead letter, batch processing lock, session lock expired, idle timeout, connection inactive, link detach, slow reconnect, session error, duplicate events, offset reset, receive batch.

