Email deliverability checklist

Magic-link emails are only useful if they reach the inbox. New sending domains face a "cold start" problem — Gmail/Outlook don't trust you yet. This page covers the checklist, ordered by importance.

1. Use a managed SMTP provider (recommended)

If you're not already running a mail server, use Postmark, Amazon SES, SendGrid, Mailgun, or Resend. They handle the hard parts (rDNS, IP reputation, feedback loops, bounce processing). You configure DNS once and forget it.

2. Set SPF, DKIM, and DMARC on your sending domain

These are the three modern email authentication mechanisms. Receivers cross-check them against your DNS to decide whether your mail is forged.

SPF

One TXT record at the apex telling receivers which IPs/services may send for you:

example.com.    TXT    "v=spf1 include:_spf.google.com -all"
# Or for SES:    "v=spf1 include:amazonses.com -all"
# Or for your own server:   "v=spf1 ip4:192.0.2.10 -all"
# Or via MX:    "v=spf1 mx -all"  (resolves MX records and uses their IPs)

DKIM

Your SMTP provider gives you a TXT record per selector. Add them all. SpeedyFiles itself doesn't sign — the SMTP server does (because the server has the private keys).

DMARC

One TXT record at _dmarc.example.com declaring your policy:

# Monitor-only (recommended to start)
_dmarc.example.com.   TXT   "v=DMARC1; p=none; rua=mailto:postmaster@example.com"

# After 2+ weeks of clean monitoring, tighten:
_dmarc.example.com.   TXT   "v=DMARC1; p=quarantine; pct=10; rua=..."

# Eventually:
_dmarc.example.com.   TXT   "v=DMARC1; p=reject; rua=..."

3. PTR / rDNS for your sending IP

If you're sending from a server you control (not a managed provider), the IP needs a PTR record pointing to a hostname that forward-confirms back to that IP. Without it, Gmail / Microsoft heavily penalize.

# Forward (your DNS):
mail.example.com.   A      192.0.2.10
# Reverse (set by your ISP / hosting provider):
10.2.0.192.in-addr.arpa.   PTR   mail.example.com.

Verify with dig -x 192.0.2.10 — should return mail.example.com.

4. HELO matches PTR

Set the HELO/EHLO hostname in SpeedyFiles → Settings → Mail to the same name your PTR resolves to. Mismatched HELO is a moderate spam signal.

5. Set Date and Message-ID

SpeedyFiles does this automatically. Verify by checking Show original in Gmail on a received message — both headers should be present and Message-ID should end in your sending domain (e.g. <abc...@example.com>).

6. Warm up new IPs / domains

A brand-new sending domain gets cold-start treatment. Strategies:

Send a few low-volume, high-engagement messages first (to people who will reply / mark not-spam)
Tell recipients: "If it lands in spam, please mark it as Not Spam — it'll go to inbox next time"
Avoid bulk sends for the first 2 weeks. Real-customer transactional volume is fine.

7. Register with postmaster tools

Gmail Postmaster Tools — verify your domain, see reputation reports
Microsoft SNDS — Smart Network Data Service for Outlook/Hotmail

8. Use a real From address

Don't send as noreply@example.com if you can avoid it. Use files@example.com or support@example.com — addresses that can actually receive replies. Receivers' classifiers heavily weight whether mail looks like a legitimate two-way conversation.

9. Test before going live

mail-tester.com — send a message to a generated address, get a 0–10 spam score with full breakdown
Send a test to yourself at Gmail/Outlook/Yahoo. Show original. Confirm:
```
spf=pass
dkim=pass header.s=<selector>
dmarc=pass
```

10. Monitor

SpeedyFiles audit log records every magic-link hit. If a customer reports they didn't get a link, check /dash/packages/<id>:

If token_view never fired → message didn't reach (or wasn't clicked) → check SMTP logs / try resending
If token_view + file_download both fired → it worked, customer might be confused