Everything we know about
getting email to the inbox.

Domain warm-up: the silent half of reputation

IP reputation gets all the attention, but in the post-2024 world, domain reputation matters more. Gmail explicitly states their reputation is tied to the From: domain, not the IP.

Why domain warm-up exists

If you set up a brand-new sending domain (say send.acme.com) and start blasting from a warmed shared IP pool, Gmail still doesn't know your domain. It will throttle your delivery and rate-limit based on the domain's lack of history — even if the IP is perfectly clean.

How to warm a domain

Treat the domain warm-up exactly like an IP warm-up — but the volumes don't reset when you change IPs:

• Week 1: Use the domain only for transactional (receipts, password resets) to highly engaged users.
• Week 2–3: Add lifecycle / onboarding messages.
• Week 4+: Begin marketing campaigns. Maintain consistent daily volume.

Best practice: use sub-domains by traffic type

Don't send from your bare apex domain. Use stream-specific subdomains so a marketing complaint never poisons your transactional reputation:

• tx.yourbrand.com — OTPs, receipts, security alerts
• mail.yourbrand.com — marketing & promos
• notify.yourbrand.com — product notifications
• news.yourbrand.com — newsletter

SPF, DKIM & Return-path explained

These three records are the foundation of email authentication. Without them, you are virtually guaranteed to land in spam — and after Feb 2024, you may not be accepted at all.

SPF — Sender Policy Framework

SPF is a TXT record on your domain that lists which IP addresses (or "include" providers) are allowed to send mail "as" you. It's how a receiver answers: "Did this email really come from a server this domain authorized?"

Example SPF record

v=spf1 include:_spf.maildoot.net include:_spf.google.com ~all

• v=spf1 — version (always this)
• include: — delegates to another domain's SPF (Maildoot, Google, etc.)
• ~all — soft-fail unauthorized senders (recommended). Use -all for hard-fail once you're confident.

DKIM — DomainKeys Identified Mail

DKIM signs every outgoing email with a cryptographic signature in the headers. The receiver fetches your public key from DNS and verifies the signature. This answers: "Did this email's body and headers arrive unaltered, and is the sender who they claim to be?"

How DKIM works

• You publish a public key at selector._domainkey.yourdomain.com as a TXT record.
• The sending server signs each message with the matching private key.
• The receiver fetches your public key and verifies the signature.

Example DKIM record

Host:  md1._domainkey
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Maildoot generates a 2048-bit RSA key pair per domain on signup and publishes the public half for you. You never see the private key.

Return-path (the bounce address)

Also called the envelope sender or MAIL FROM. This is the address that receives bounce notifications — and it must be on your domain (not Maildoot's) for DMARC alignment.

How it's set up

You add a CNAME record like:

Host:  bounce.yourdomain.com
Type:  CNAME
Value: bounces.maildoot.net

Maildoot then sets the envelope sender to bounce-{msg_id}@bounce.yourdomain.com. Bounces hit our infrastructure but appear to come from your domain — satisfying DMARC alignment.

DMARC: from p=none to p=reject

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers what to do when SPF or DKIM fail — and gives you visibility into who's spoofing your domain.

The three policy modes

• p=none — Monitor only. Receivers send you reports but take no action. Use this for the first 2–4 weeks while you collect data.
• p=quarantine — Send to spam. Failing messages land in the recipient's spam folder. Use this once you've fixed all alignment issues.
• p=reject — Drop entirely. Failing messages are rejected at SMTP. This is the goal — and Gmail/Yahoo's 2024 policy requires it for senders > 5,000/day.

Example DMARC record

Host:  _dmarc
Type:  TXT
Value: v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com;
       ruf=mailto:dmarc-forensic@yourdomain.com; fo=1; adkim=s; aspf=s

Tag reference

• p= — policy (none, quarantine, reject)
• rua= — aggregate report mailbox (daily XML reports)
• ruf= — forensic report mailbox (per-message failures)
• pct= — percentage of failing mail to apply the policy to (use during rollout: pct=10, pct=50, pct=100)
• adkim= / aspf= — alignment mode: s = strict (exact match), r = relaxed (subdomain OK)
• fo= — forensic options (1 = report any failure)

The recommended rollout

1. Week 1: publish p=none, start collecting RUA reports.
2. Week 2: parse reports — find every sending source. Authorise legit ones, ignore spoof attempts.
3. Week 3: shift to p=quarantine; pct=10.
4. Week 4: ramp pct to 50, then 100.
5. Week 5+: move to p=reject; pct=100.

Gmail & Yahoo's 2024 bulk-sender requirements

On February 1, 2024, Gmail and Yahoo jointly raised the bar for any sender that delivers more than 5,000 messages per day to their inboxes. Failure to comply means rejected mail. Period.

The four hard requirements

1. Authenticate with SPF, DKIM, and DMARC

All three must be in place, and your DMARC policy must be at least p=none. The DMARC record must align with either SPF or DKIM (or both).

2. Send only wanted email — keep complaint rate < 0.3%

This is measured by Gmail Postmaster Tools. A complaint rate above 0.3% triggers throttling; above 0.5% may cause outright rejection. 0.1% should be your internal target.

3. Make unsubscribing trivial — one-click List-Unsubscribe

You must support RFC 8058 one-click unsubscribe via List-Unsubscribe headers. Both headers must be present:

List-Unsubscribe: <https://yourapp.com/u/abc123>, <mailto:unsub+abc123@yourapp.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The unsubscribe URL must process a single POST — no login screens, no "are you sure" pages.

4. Use TLS for transmission

Outgoing SMTP must use TLS 1.2 or higher. Maildoot enforces this by default; if you're running self-hosted relays, verify STARTTLS is mandatory.

What changes for your domain

• If you send < 5,000/day to Gmail+Yahoo combined, you have most of these requirements but not all.
• If you send > 5,000/day, all four are mandatory.
• The 5,000 threshold is aggregated across subdomains. tx.acme.com + mail.acme.com = one bucket.

How Maildoot handles it

• SPF — auto-flattened to stay under the 10-lookup cap
• DKIM — 2048-bit RSA, rotated quarterly
• DMARC — guided wizard from p=none through p=reject
• List-Unsubscribe — injected automatically on marketing-tagged sends, with a one-click POST endpoint we host
• TLS — mandatory 1.2+ everywhere

Setting up DNS records on any registrar

Maildoot generates exactly five records when you add a sending domain. Here's what each one does and how to paste them into the major registrars.

The five records Maildoot needs

GoDaddy

1. Sign in → My Products → DNS next to your domain.
2. Click Add, choose TXT (or CNAME).
3. Paste Host and TXT Value from your Maildoot dashboard.
4. Set TTL to 1 hour. Save.

Cloudflare

1. Select your domain → DNS → Records → Add record.
2. Choose type (TXT or CNAME), paste Name and Content.
3. Important: Set proxy status to DNS only (grey cloud) for CNAMEs — orange-clouding the bounce/tracking CNAME breaks email.
4. Save.

AWS Route 53

1. Hosted zones → your zone → Create record.
2. Set Record name (e.g. _dmarc), Record type (TXT/CNAME), and Value.
3. TTL 300. Create record.

Google Domains / Squarespace, Namecheap, BigRock

Similar — find the "DNS" or "Advanced DNS" section and add records with matching Host, Type, and Value fields.

Verification

DNS can take up to 48 hours to propagate, but most updates are visible in 5–15 minutes. Maildoot's verify button polls every 30 seconds — you'll see a green check the moment the records resolve. You can also verify manually:

dig TXT yourdomain.com +short
dig TXT md1._domainkey.yourdomain.com +short
dig CNAME bounce.yourdomain.com +short

BIMI: get your logo in the inbox

Brand Indicators for Message Identification (BIMI) lets compliant senders display their logo next to messages in Gmail, Yahoo, Apple Mail, and Fastmail. It's a trust signal — and a conversion lift.

Requirements

• DMARC at p=quarantine or p=reject with pct=100
• An SVG Tiny PS logo at a publicly hosted URL
• For Gmail and Apple: a Verified Mark Certificate (VMC) from DigiCert or Entrust (~$1,500/year)

Example BIMI record

Host:  default._bimi
Type:  TXT
Value: v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem

Feedback loops and suppression hygiene

A feedback loop (FBL) is a notification from an ISP that a recipient marked your mail as spam. Honouring FBLs immediately — by suppressing that recipient — is non-negotiable in 2024.

The major FBLs

• Yahoo! — open registration via Yahoo Sender Hub
• Microsoft (Outlook/Hotmail) — SNDS + JMRP
• Apple iCloud — registered per IP
• AOL — merged with Yahoo
• Gmail — no per-recipient FBL, but aggregate complaint data via Postmaster Tools

What Maildoot does automatically

Maildoot is registered for every major FBL on your behalf. Complaints are processed within seconds and the recipient is moved to your account's suppression list — never sent to again until you explicitly remove them. Your dashboard shows a per-domain, per-ISP complaint timeline.