Email Domain Reputation Preflight: What Actually Gets Checked Before You Send

A domain reputation preflight check verifies four things before you send a cold campaign: that your domain is cryptographically authenticated (SPF, DKIM, DMARC), that your sending infrastructure matches what your DNS claims (reverse DNS, TLS), that your domain and IP haven't accumulated a history of complaints or blocklist hits, and that your sending pattern won't look like an abuse spike to the receiving mailbox provider. It matters because Google and Microsoft now enforce these checks mechanically — as of 2024 and 2025 respectively, both reject or junk-folder mail from domains that fail them, regardless of how good your copy is.

This isn't a vague "sender score." It's a specific, checkable set of technical conditions, most of them published directly by the two companies that receive the overwhelming majority of B2B cold email: Google (Gmail) and Microsoft (Outlook/Hotmail/Live).

Why this became mandatory, not optional

Direct answer: Starting February 1, 2024, Google began enforcing bulk sender requirements for any domain sending close to 5,000 messages or more in a 24-hour period to personal Gmail addresses. Microsoft followed on May 5, 2025, with its own high-volume sender rules for outlook.com, hotmail.com, and live.com, requiring SPF, DKIM, and at least a monitoring-level DMARC record. Enforcement has escalated since: Google ramped up rejection of non-compliant traffic in late 2025, and Microsoft moved from routing unauthenticated bulk mail to Junk toward outright rejecting it at the SMTP level.

Two details matter for anyone doing outbound:

• The threshold doesn't reset. Google's own FAQ confirms a domain that has ever crossed the ~5,000/day bulk-sender line to Gmail stays classified as a bulk sender even if volume later drops — a domain that sent one large campaign months ago is still held to bulk-sender rules today.
• It applies below the threshold too, in effect. The 5,000/day rule is a hard enforcement line, but the underlying reputation systems (spam-rate tracking, blocklists, authentication checks) evaluate every sending domain, not just bulk senders. A 200-email/day cold campaign from an unauthenticated new domain gets filtered by the same infrastructure — it just isn't subject to the formal bulk-sender rejection rule.

Two reputations, not one

The word "reputation" gets used loosely, but mailbox providers track two genuinely separate signals:

IP reputation is scored against the sending server itself — its historical volume, complaint rate, and authentication pass rate. It determines whether a connection is accepted at the perimeter. It's comparatively fast to rebuild (weeks) because it resets when you change infrastructure.

Domain reputation is scored against the domain name and follows it across IP changes, ESP migrations, and even provider switches. It's built from recipient-side signals — opens, replies, deletes-without-reading, spam reports — and is what increasingly determines inbox-versus-spam-folder placement, especially for B2B senders, because a domain is much harder to discard than an IP. (Twilio's technical breakdown of this distinction is a useful primer if you want the full mechanics.)

Google's own Postmaster Tools has historically scored domain and IP reputation on a four-tier scale — High, Medium, Low, Bad — based on spam-filter and user-report data. Notably, Google retired the original Postmaster Tools "IP Reputation" and "Domain Reputation" dashboards in its v2 interface transition, finalized in late 2025, replacing the abstract score with two concrete dashboards: Compliance Status (are you technically set up correctly) and Spam Rate (what fraction of recipients are reporting you). That shift is itself informative — Google is telling senders that the actionable data was never the vague score, it was the spam-complaint percentage.

What SPF, DKIM, and DMARC each actually check

Direct answer: These three protocols get bundled together in conversation but check different things, and a preflight has to verify all three independently.

SPF (Sender Policy Framework), defined in RFC 7208, is a DNS TXT record listing which IP addresses and hosts are authorized to send mail for a domain. The receiving server checks the connecting IP against that list. It only validates the "envelope from" (the SMTP-level sender), not the visible From address, and it's capped at 10 DNS lookups per RFC — a record with too many nested include: mechanisms can silently fail evaluation.

DKIM (DomainKeys Identified Mail), defined in RFC 6376, works differently: it attaches a cryptographic signature to the message body and headers, signed with a private key. The receiving server pulls the matching public key from a DNS TXT record and verifies the signature hasn't been altered in transit. It checks message integrity and sender identity, not the sending IP.

DMARC (Domain-based Message Authentication, Reporting, and Conformance), defined in RFC 7489 and explained in plainer terms by dmarc.org and Cloudflare, sits on top of both. It requires the domain in the visible From header to align with either the SPF or DKIM domain, and it tells receiving servers what to do when that alignment fails — do nothing (p=none), quarantine to spam, or reject outright. Critically, a message can pass SPF or DKIM individually and still fail DMARC if the From-header domain doesn't align with either — this is the exact gap Google's and Microsoft's 2024–2025 rules were written to close.

The preflight checklist

Running the preflight: the sequence

1. Pull the domain's current SPF, DKIM, and DMARC records from DNS and confirm DMARC alignment against at least one of SPF or DKIM — not just that all three records exist.
2. Confirm reverse DNS resolves for every sending IP back to a hostname consistent with the sending infrastructure.
3. Check blocklist status for the domain and sending IP against public lists.
4. Check the domain's sending history. A domain registered or first used for mail in the last few weeks carries no reputation signal either way — that's a risk factor by itself, independent of authentication passing.
5. Confirm recent spam-complaint and bounce data if any prior campaigns exist on the domain or IP.
6. Verify unsubscribe mechanics are present and functional if the campaign qualifies as bulk/marketing mail under Google's or Microsoft's definitions.
7. Check sending volume against domain age. If the domain is new, the preflight should flag that full-volume sending is premature rather than simply confirming DNS is correct.

What warm-up data actually shows — and its limits

Because a brand-new domain has no reputation signal, most deliverability guidance recommends a gradual ramp rather than sending at full volume immediately — commonly cited ranges across the industry run 2 to 8 weeks depending on target volume. One independent test series from deliverability vendor Warmy, which sent controlled volumes (15–200 emails/day) from new domains into Gmail and Microsoft 365 test mailboxes, found inbox placement climbing to over 90% by the second week, with a related recovery point tied to clearing blocklists like SEM FRESH within roughly 5 to 7 days of first sending. That's one vendor's test, not a universal constant — actual timelines depend on list quality, content, and the specific receiving provider — but it's consistent with the broader pattern every source agrees on: sudden volume from a domain with no history reads as an abuse signal, and gradual increase does not.

Limitations of a preflight check

Direct answer: A preflight is a point-in-time snapshot, not a guarantee. A few things it explicitly cannot do:

• It can't predict inbox placement with certainty. Passing SPF, DKIM, and DMARC and having a clean blocklist status makes delivery likely, not assured. Inbox-versus-spam routing also depends on recipient-side engagement signals accumulated after send, which a preflight can't see in advance.
• Spam filters are opaque by design. Google and Microsoft don't publish their full filtering logic, and for good reason — publishing it would let bad actors reverse-engineer around it. A preflight checks the requirements that are documented; it cannot check the parts of the filtering pipeline that aren't.
• Reputation is dynamic, not fixed. A domain that passes every check today can have its reputation degrade within a single bad campaign — a spike in complaints or bounces changes the picture immediately, and a check run last week says nothing about this week's send.
• Compliance status and content quality are different problems. Passing every authentication and infrastructure check does not mean the message content itself won't trigger spam-filtering on its own merits.

Where nqzai fits

nqzai runs a DNS-level check against a sending domain before a cold-email campaign goes out — confirming SPF, DKIM, and DMARC are present and correctly aligned, and flagging deliverability risk factors like a missing DMARC record, an unauthenticated sending path, or a domain with no prior sending history. It surfaces what's misconfigured in plain terms rather than a black-box score, so the fix is obvious before the campaign, not after open rates come back low. It does not claim to predict inbox placement — nothing honestly can, given how filtering actually works — and it doesn't replace an actual warm-up period for a new domain. What it does is catch the preflight-checkable failures (missing records, misalignment, obvious red flags) automatically, instead of leaving them to be discovered as bounces or a silent drop in replies three weeks into a campaign.

FAQ

What's the difference between a domain reputation check and a spam score checker?

A domain reputation preflight verifies the underlying technical and historical conditions — authentication records, sending history, blocklist status. A spam score tool (like sending a test message to a scoring inbox) evaluates a specific message's content and headers against known spam triggers. They check different things and both have a place; neither substitutes for the other.

Do I need to redo this preflight for every campaign?

The DNS-level checks (SPF/DKIM/DMARC/PTR) don't need re-verification every send unless you've changed sending infrastructure or providers. Spam-complaint rate and blocklist status should be checked more frequently, since those change based on recent sending behavior, not configuration.

Can I pass every check and still land in spam?

Yes. Authentication and infrastructure checks reduce risk; they don't eliminate it. Content, recipient engagement history, and the receiving provider's own filtering logic — none of which a preflight can fully see — still determine final placement.

How long does a new domain need to warm up before cold outreach at scale?

There's no universally agreed exact number — industry guidance clusters around 2 to 8 weeks depending on target volume and list quality, based on convergent recommendations from multiple deliverability vendors rather than a single fixed rule. The safer approach is to ramp gradually and watch bounce/complaint signals rather than sending on a fixed calendar.

Does Google Postmaster Tools still show a "reputation score"?

Not in the form it used to. Google retired the original v1 "IP Reputation" and "Domain Reputation" dashboards as it finalized its v2 interface in late 2025, replacing them with a Compliance Status view and a Spam Rate view — the concrete, actionable numbers rather than an abstracted score.

Is a spam complaint rate of 0.3% actually bad?

By Google's own published threshold, yes — 0.3% is the line at which bulk senders lose access to Gmail's delivery mitigation support until they maintain a rate below that for seven consecutive days. Google's stated target for a healthy sender is under 0.1%.