Skip to main content
Email deliverability is the likelihood that a message reaches the inbox rather than the spam folder. It depends on DNS authentication records (DKIM, SPF, DMARC), your sending reputation, and whether your IP or domain appears on any blacklists.

Running an audit

wraps email check yourapp.com
The command queries DNS, tests MX server TLS, and checks your domain and sending IPs against major blacklists. It then produces a scored report with letter grade.
╭──────────────────────────────────────────────────────────────────────────────╮
│                                                                              │
│   wraps email check                                                          │
│                                                                              │
│   Domain: yourapp.com                                                        │
│                                                                              │
│   ████████████████████████████████████████████████████████░░░░░░  A         │
│   Score: 92/100                                                              │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯

What gets checked

Authentication

CheckWhat it verifies
DKIMCNAME records exist and the keys are valid (not revoked)
SPFTXT record is present, syntactically valid, and uses ≤ 10 DNS lookups
DMARCTXT record at _dmarc is present, valid, and has a policy set

Infrastructure

CheckWhat it verifies
MX recordsMX records exist and all hostnames resolve
Mail server TLSMX servers support STARTTLS on port 25
Reverse DNSSending IPs have valid PTR records
IPv6MX records have AAAA records and SPF covers IPv6

Reputation

CheckWhat it verifies
BlacklistsDomain and IPs are not listed on major blocklists
Domain ageDomain is not newly registered (new domains have lower trust)

All flags

FlagDescription
-q, --quickFewer checks — top blacklists only, fewer DKIM selectors scanned
-j, --jsonOutput full results as JSON (useful for CI pipelines)
--verboseShow all checks, including ones that passed
--dkimSelectorCheck a specific DKIM selector by name
--skipBlacklistsSkip blacklist checks (faster)
--skipTlsSkip MX TLS checks
--timeoutDNS lookup timeout in milliseconds (default: 5000)

Examples

# Quick scan for CI
wraps email check yourapp.com --quick

# Full verbose output
wraps email check yourapp.com --verbose

# JSON output for scripts
wraps email check yourapp.com --json

# Check a specific DKIM selector
wraps email check yourapp.com --dkimSelector ses

# Skip slow checks
wraps email check yourapp.com --skipBlacklists --skipTls

Common issues and fixes

Symptom: ✗ DKIM — No DKIM selectors foundFix: Follow the Domain Setup guide to generate DKIM tokens and add the three CNAME records to your DNS provider.
wraps email domains get-dkim -d yourapp.com
# Add the printed CNAME records to your DNS provider, then:
wraps email domains verify -d yourapp.com
Symptom: ⚠ SPF — Softfail (~all) — consider using -all for strict enforcementFix: Change ~all (softfail) to -all (hardfail) once you’re confident all legitimate senders are listed:
# Before (softfail — suspicious mail is accepted but marked)
v=spf1 include:amazonses.com ~all

# After (hardfail — mail from unlisted sources is rejected)
v=spf1 include:amazonses.com -all
Only switch to -all after reviewing DMARC reports to confirm you haven’t missed any sending sources.
Symptom: ✗ DMARC — Not foundFix: Add a TXT record at _dmarc.yourapp.com:
v=DMARC1; p=none; rua=mailto:[email protected]
Start with p=none to collect aggregate reports without affecting delivery. Once you’ve confirmed DKIM and SPF are working correctly, tighten the policy:
# Quarantine (move failing mail to spam)
v=DMARC1; p=quarantine; rua=mailto:[email protected]

# Reject (block failing mail entirely)
v=DMARC1; p=reject; rua=mailto:[email protected]
Symptom: ✗ Blacklists — Listed on 1 listFix:
  1. Check which blacklist flagged your domain or IP in the report output
  2. Visit that blacklist’s website — most have a self-service delisting form
  3. Common public blacklists and their delisting pages:
  4. After delisting, re-run the check to confirm:
    wraps email check yourapp.com
    
Getting delisted is faster when you can show you’ve resolved the underlying issue (e.g., closed a compromised account that was sending spam).
Symptom: ⚠ SPF — 11/10 DNS lookups usedFix: SPF limits you to 10 DNS lookups per evaluation. Reduce the number of include: mechanisms or replace them with explicit ip4: and ip6: directives. Tools like MXToolbox SPF Flattener can help.

Best practices for production sending

  • Set a DMARC policy of at least p=quarantine before sending at volume. Start with p=none to review reports first.
  • Monitor bounce and complaint rates. High bounce rates damage your sending reputation. The Wraps production and enterprise presets include event tracking and reputation metrics.
  • Warm up new domains gradually. Start with a few hundred emails per day and ramp up over two to four weeks.
  • Avoid spam trigger words in subject lines and keep your unsubscribe link visible.
  • Authenticate all sending sources. If you use third-party email tools alongside Wraps, include all of them in your SPF record.

Bounce and complaint tracking

Wraps automatically processes SES bounce and complaint notifications and suppresses addresses that have hard-bounced. With the production preset, events are stored in DynamoDB for 90 days. High bounce rates (above 5%) or complaint rates (above 0.1%) trigger SES sending limits. The enterprise preset includes full reputation metrics to monitor these in real time.

Dedicated IP

The enterprise preset provisions a dedicated IP for your account. A dedicated IP means your reputation is entirely your own — other senders on AWS SES cannot affect your deliverability.
wraps email init --preset enterprise
Dedicated IPs require a warm-up period of several weeks before reaching full reputation.

Build docs developers (and LLMs) love