The Complete Resource for Better Email Marketing

Why mailbox providers distrust new senders

Google, Microsoft, and Yahoo have no history for a new sending domain. No engagement data, no complaint history, no baseline volume patterns. From their perspective, a brand-new domain sending 10,000 emails on day one looks identical to a spammer who just registered a throwaway domain. The filtering default is aggressive.

Warming is the process of building that history deliberately — starting with small volumes to a known-good audience, then expanding as positive engagement signals accumulate. Providers see opens, clicks, and replies; they conclude real recipients want this mail; they relax filtering over time.

The non-negotiables before you start

Warmup fails if your technical setup is wrong. Confirm these before sending a single warmup email:

• SPF record published and including your sending infrastructure
• DKIM signing active and keys published in DNS (2048-bit minimum)
• DMARC record set to at least p=none with a reporting address
• Custom tracking domain configured (not a shared provider subdomain)
• Unsubscribe header and one-click unsubscribe functional

Missing any of these and warmup sends will generate authentication failures, which work directly against the reputation you're trying to build.

The 8-week volume schedule

These targets assume you want to reach roughly 50,000 emails/day at full volume. Scale proportionally for higher or lower targets — the percentage increases matter more than the raw numbers.

The role of automated warmup tools

The schedule above covers your real-list sends. The problem: at weeks one and two, you're sending 50–100 emails per day. That's not enough volume to build meaningful reputation signals — especially on weekends when your list send may drop to zero.

Warmy runs alongside your real sends 24 hours a day. Its network of 15,000+ real mailboxes sends, receives, opens, and replies to emails from your domain constantly — filling the volume gaps and generating the engagement signals that move your reputation score faster than real-list sends alone can achieve. The warmup runs on its own schedule; you set it once and monitor the dashboard.

Folderly runs inbox placement tests throughout the warmup period, showing you exactly where your mail lands across Gmail, Outlook, Yahoo, and iCloud at each stage. Without placement testing, you're flying blind — a warmup that looks successful by volume can still be routing to spam on specific providers.

Red flags that tell you to slow down

Check these metrics after every send during warmup. Any of these signals means you hold at the current volume for another week before increasing:

• Bounce rate above 2% on any single send
• Complaint rate above 0.05% (visible in Gmail Postmaster Tools)
• Inbox placement below 90% on Folderly's placement test
• Domain reputation showing "Low" or "Bad" in Gmail Postmaster Tools

After the warmup: what changes

A completed warmup doesn't mean you stop monitoring. Reputation is dynamic — a bad batch of sends can erode weeks of positive signals. Keep Folderly running for ongoing placement monitoring, and keep Warmy running at a lower maintenance level to sustain the engagement signals. Most established senders run warmup tools indefinitely at reduced volume as reputation insurance.

Content filters run before reputation checks

Providers run emails through two layers of filtering. The first is reputation-based — IP and domain scores. The second is content-based — the actual HTML, images, links, and text patterns inside the message. A sender with solid reputation can still fail content filtering if the template structure triggers enough signals.

Content filtering is not about specific banned words anymore. Modern filters use machine learning to evaluate the overall pattern of an email: image-to-text ratio, link density, HTML cleanliness, structural similarity to known spam templates, and dozens of other signals simultaneously.

Issue 1: Too many images, too little text

Spam filters cannot read images. An email that's mostly image — a single large graphic with a tiny text footer — looks exactly like a phishing attempt or image-based spam campaign, because that's what those look like. The filter has no content to evaluate, so it defaults toward caution.

Aim for a 60:40 text-to-image ratio at minimum. Promotional emails can lean more image-heavy, but every image should have meaningful alt text, and the overall message should be comprehensible with images blocked. Test this in your ESP: disable images and read the email. If it makes no sense, rebalance.

Issue 2: Dirty HTML from copy-paste

Copy-pasting content from Google Docs, Word, or a CMS into an email editor drags along invisible formatting: Microsoft-specific XML tags, nested span elements, inline styles that contradict each other, and encoding artifacts. These create HTML that looks fine rendered but reads as garbage to a content filter.

Always paste as plain text first, then apply formatting inside the email editor. Or build in a tool that generates clean output from scratch. Stripo produces clean, standards-compliant HTML regardless of how you assemble the content — no paste artifacts, no junk markup.

Issue 3: Missing plain-text version

Every email has two parts: the HTML version and a plain-text alternative. Legitimate senders always include both. Spam campaigns frequently don't — generating the plain-text is an extra step that automated spam tools skip. Filters look for both parts; a missing plain-text version pushes your spam score up.

Most ESPs generate the plain-text version automatically if you let them. The problem is auto-generated plain-text often looks terrible — stripped of formatting, full of link URLs, missing line breaks. Stripo generates a clean plain-text version alongside the HTML automatically, and lets you edit it before sending.

Issue 4: Links pointing to low-reputation domains

Filters check every URL in your email against blacklists and reputation databases. One link to a domain with a spam history — even a third-party link in your footer, or a tracking subdomain that shares infrastructure with known spam senders — can flag the entire message.

Audit every link in templates before sending. Pay particular attention to: tracking subdomains (use a custom domain, not a provider default), social media share links (verify the destination URLs are clean), and any partner or affiliate links you've added recently. Run the email through a spam checker before sending.

Issue 5: Trigger words and patterns

Specific phrases still carry weight in content scoring, particularly in subject lines. These aren't just obvious ones like "FREE MONEY" — subtler patterns matter too:

• Excessive punctuation: "Act now!!!" or "Limited time????"
• ALL CAPS words anywhere in the subject line
• "Guaranteed," "risk-free," "no obligation," "winner"
• Dollar signs and percentages in subject lines ("Save $50 — 70% off today only")
• Urgency stacking: "Last chance," "Expires tonight," "Only 3 left" in the same email

None of these are automatic disqualifiers on their own. Filters score them additively — five mild signals in one email add up the same as one severe signal.

Issue 6: Missing or broken unsubscribe

CAN-SPAM requires a functional unsubscribe mechanism. Gmail and Yahoo now require one-click unsubscribe for bulk senders. Filters check for the presence of a valid List-Unsubscribe header. Missing it is both a legal problem and a deliverability problem.

More importantly: a working, visible unsubscribe link lowers complaint rates. Recipients who can't find the unsubscribe button hit "report spam" instead. Spam complaints damage your reputation far more than unsubscribes do.

How to audit a template before sending

Run every new template through this checklist before it goes live:

• Disable images — can you still read and understand the email?
• Check the HTML source for Microsoft Office or Google Docs markup artifacts
• Verify the plain-text version exists and reads cleanly
• Run every link through a URL reputation checker
• Count exclamation points and ALL CAPS words in the subject line (target: zero)
• Confirm the unsubscribe link works and the List-Unsubscribe header is present
• Run the assembled email through a spam score tool

Stripo runs a spam score check before every export and surfaces the specific issues driving the score up — not just a pass/fail number. It also previews rendering across 90+ email clients, which catches display problems in Outlook and older mobile clients that a spam score tool misses.

What the current bulk sender rules require

Google and Yahoo jointly enforce requirements for senders of more than 5,000 emails/day to Gmail or Yahoo addresses. The rules: valid SPF or DKIM on every message, DMARC alignment at minimum p=none, a functional one-click unsubscribe, and a spam complaint rate below 0.1%.

The 5,000/day threshold is per domain, not per campaign. A sender who sends 200 emails/day to Gmail addresses for 25 days in a month crosses it. And while the formal requirement is for bulk senders, providers apply the same authentication signals to all mail — smaller senders without authentication face increased filtering even below the threshold.

SPF: authorizing your sending servers

SPF (Sender Policy Framework) is a TXT record in your DNS that lists every server allowed to send email from your domain. Add it at the root of your sending domain — if you send from hello@yourdomain.com, the record goes on yourdomain.com.

For SMTP2GO:

For Ahasend:

If you send from multiple platforms (e.g., your ESP plus a transactional provider), combine them in a single record:

SPF has a 10-lookup limit. Each include: counts as one lookup. If you add too many providers, use an SPF flattening tool to stay within the limit.

The ~all at the end soft-fails unauthorized senders. Switch to -all (hard fail) after you've verified all your legitimate sending sources are included. Starting with ~all avoids accidentally blocking legitimate mail during setup.

DKIM: signing your messages

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. Your sending platform holds the private key and signs each message. The corresponding public key lives in your DNS as a TXT record. Receiving servers fetch the public key and verify the signature — confirming the message came from your domain unaltered.

Both SMTP2GO and Ahasend generate your DKIM keys and provide the DNS record to publish. The record format looks like this:

The selector is a label assigned by your sending platform (e.g., smtp2go or ahasend1). Your provider's dashboard will give you the exact name and value to copy. Use a 2048-bit key minimum — 1024-bit is considered weak by modern standards and some providers reject it.

DMARC: policy and reporting

DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of SPF and DKIM. It tells receiving servers what to do when a message fails both checks, and it sends you reports showing authentication results across all mail claiming to come from your domain.

DMARC is published as a TXT record at _dmarc.yourdomain.com:

Start with p=none. This puts DMARC in monitor-only mode — it sends you reports but doesn't block or filter anything. Run it for two to four weeks and read the reports. You'll see every source sending mail from your domain, including sources you didn't know about (marketing automation tools, CRMs, customer service platforms). Make sure each one has SPF or DKIM configured before you tighten the policy.

Once you've accounted for all legitimate senders, move to p=quarantine:

The pct=25 applies the policy to only 25% of failing messages initially. Raise it to 50%, then 100% over two to four weeks as you confirm no legitimate mail is getting caught. Then move to p=reject for full protection.

Custom tracking domains

Most ESPs and SMTP providers use their own domains for click tracking and open tracking by default — links in your email resolve through something like click.smtp2go.net. This means the tracked links in your email don't match your sending domain, which can affect DMARC alignment and triggers filters that compare the From domain against embedded link domains.

Both SMTP2GO and Ahasend support custom tracking domains — you create a CNAME record pointing a subdomain of your own domain (like track.yourdomain.com) to their tracking infrastructure. This aligns your tracking links with your sending domain and is a meaningful deliverability improvement, especially at higher volumes.

Verifying everything works

After publishing all three records, verify before sending:

• MXToolbox SPF Lookup — confirms your SPF record resolves correctly and stays under the 10-lookup limit
• MXToolbox DKIM Lookup — verifies the public key is published and readable (use your selector and domain)
• MXToolbox DMARC Lookup — confirms the DMARC record is valid and the reporting address is reachable
• Send a test to a Gmail address — open the email, click the three-dot menu, select "Show original," and verify the Authentication-Results header shows SPF: pass, DKIM: pass, and DMARC: pass
• Gmail Postmaster Tools — verify your domain shows as authenticated after your first real send

On the horizon: DKIM2

Today's DKIM has a well-known weakness: signatures break when a message is forwarded, modified by a mailing list, or routed through an intermediary. When DKIM breaks, DMARC fails, and legitimate mail lands in spam — even when the original sender did everything right. ARC (Authenticated Received Chain) was added as a patch, but it didn't fix the root cause.

DKIM2 is a next-generation revision being drafted at the IETF. It's still a draft, not yet a standard, but the direction is clear: chainable signatures that survive forwarding and mailing-list handling, clearer attribution of who handled the message at each hop, and stronger signals to mailbox providers about who is actually responsible for the send. For marketers, the practical payoff is fewer "why is our legitimate email in spam after a forward?" incidents.

What to do today: nothing urgent. Keep SPF, current DKIM, and DMARC correctly configured — DKIM2 builds on the same foundation, not a replacement. Your ESP, SMTP relay, or self-hosted MTA will roll out DKIM2 support once the spec stabilizes; watch their release notes.

On the horizon: DMARCbis

DMARC's original spec (RFC 7489) has been "informational" for nearly a decade. In practice, receivers each interpreted some edge cases their own way — especially around how to determine the organizational domain, how subdomain policies inherit, and how to safely test new policies. DMARCbis is the updated revision moving DMARC from informational guidance to a Proposed Standard, so receivers behave more consistently.

The most important changes for marketers:

• DNS tree walk replaces the Public Suffix List. Today, receivers rely on a community-maintained list to figure out where your "organizational domain" ends and a public suffix (like co.uk) begins. DMARCbis walks DNS itself, which is more reliable for unusual TLDs, country-code domains, and brand-owned suffixes.
• New psd tag — explicitly marks a domain as a public suffix so receivers don't accidentally apply policy to every tenant under it.
• New np tag — a separate policy for non-existent subdomains. Attackers love spoofing invoices.yourbrand.com even when you've never sent from it; np=reject shuts that down without affecting your real subdomains.
• New t tag — a clean "testing" signal so you can stage policy changes without surprising receivers.
• pct is being retired. The percentage tag was widely misunderstood and inconsistently applied. Future ramps happen via the testing tag and monitored aggregate reports instead.

Why marketers should care:

• Fewer "mystery" placement issues on unusual domains. The DNS tree walk removes a class of bugs where DMARC was technically correct but a receiver disagreed about what your organizational domain was — costing you alignment and inbox placement.
• Stronger protection against subdomain spoofing. np=rejectcloses a real attack path that today's sp tag doesn't cover, protecting your brand reputation (and the deliverability of every other sender on your domain).
• Safer policy progression. Moving from monitor to enforcement with a proper testing tag — instead of percentage-based guesswork — means fewer legitimate sends getting caught when you tighten policy.
• More consistent enforcement across mailbox providers. A Proposed Standard means Gmail, Microsoft, Yahoo, Apple, and corporate filters interpret the same record the same way — which is what makes DMARC actually predictable as a deliverability tool.

What to do today: nothing breaking. Your existing DMARC record continues to work. Keep an eye on EasyDMARC and your other authentication tooling for DMARCbis-aware features — adding an nppolicy and using the testing tag for future ramps will be the two changes most marketers want to make first once their platform supports them.