SEM-FRESH: Why Every New Sending Domain Is Listed

Every domain bought for cold outbound is listed on SEM-FRESH within hours of registration, and there is nothing wrong with any of them. The list has one criterion, and that criterion is age. A domain registered on Monday is on it, and a domain registered five days earlier is not, whatever either of them has sent.

The panic this causes is entirely avoidable, and so is the opposite mistake of ignoring what the listing is actually telling receivers about a brand new sending domain.

What the list is, and who runs it

SEM-FRESH is one of a dozen or so reputation lists published by Spam Eating Monkey, an operator that runs a real-time IP and domain reputation service. Its services page publishes a specification for each list, and the entry for this one is short enough to quote in full. The description is "List includes domains first registered in the last 5 days". The expiration is "Domains are automatically removed after 5 days". The status is Active, the type is a URIBL covering domains and URIs only, and the query zone is fresh.spameatingmonkey.net.

Two facts in that specification settle most of the confusion around the list.

It does not list IP addresses. The type is a domain and URI list. A page promising to remove your IP from SEM-FRESH is describing something the list cannot do. The operator publishes separate IP lists, SEM-BLACK and SEM-BACKSCATTER among them, and MXToolbox files SEM BLACK next to SEM FRESH under similar names, which is where much of the mixing up starts.

It is a family, not a list. The operator publishes SEM-FRESHZERO for domains never seen before, typically registered in the last 24 hours, then FRESH at five days, and FRESH10, FRESH15 and FRESH30 at the windows their names imply. A receiver chooses how much age caution to apply by choosing a zone. That is a design decision on the receiving side that no sender can influence.

All of the above comes from Spam Eating Monkey's own services page, fetched on 2 September 2026. One detail differs between publishers: MXToolbox's page for the list adds a set of top-level domains that it says the zone covers, and no equivalent scope statement appears on the operator's own page. Where the two disagree the operator's page is the one quoted here.

1. Day 0The domain is registered

   It appears in the top level domain zone delegation and becomes visible to age-based lists

2. Hours laterFRESHZERO lists it

   The operator's tightest window covers domains never seen before, typically registered in the last day

3. Day 1 to 5FRESH lists it

   The five day window. Nothing about the domain other than its registration date is being evaluated

4. Day 5It expires automatically

   The operator publishes automatic removal after five days, with no request and no form

5. Day 5 onwardThe wider windows continue

   FRESH10, FRESH15 and FRESH30 hold the same domain for their own periods if a receiver queries them

Why this catches cold email programmes specifically

Outbound runs on domains bought for the purpose. A programme that separates sending domains from the corporate domain, which is the right architecture for every other reason, buys new domains by definition, and every new domain enters the world on the wrong side of an age heuristic.

The operator is not alone in reading registration age as a signal. SURBL publishes a comparable dataset, and the reasoning it gives is the same correlation stated plainly: not every new domain is abusive, but a great many abusive domains are young. The corpus already works through that argument and what it means for a sending estate in which of your domains got listed.

What follows from it is a scheduling fact rather than a remedy. A domain registered on Friday and pointed at a campaign on Monday is inside the window. A domain registered, authenticated and warmed for several weeks before its first campaign has left every FRESH window except the thirty day one long before a prospect sees it. Which is the same conclusion warmup arrives at from a different direction, and one more reason the gap between buying a domain and sending from it is not dead time.

Finding out whether you are actually listed

The operator runs a list query on its own site, which is the current answer and the one that names the specific zone. Aggregated checkers report the row without always saying which of the FRESH windows fired, and the distinction matters: a FRESHZERO row and a FRESH30 row on the same domain describe very different degrees of caution on the receiving side.

Two things about the operator's own site are worth knowing before you go looking. It is a single-page application, so a plain scripted fetch of any path returns the same small shell rather than the page. Anything automated that checks it needs to render the page rather than read the response. And the operator publishes its own zone-usage warning for anybody querying the lists under a .com hostname rather than the .net one: "Our services have never hosted the zones and lists under the .COM domain so this configuration has never worked." It adds that sample configurations in some third-party software carry the wrong domain.

Removal, which is not a thing you do

There is no removal request for SEM-FRESH, because there is nothing to remove. The operator's specification says domains "are automatically removed after 5 days", and the criterion that put the domain there stops being true on its own.

That is worth saying flatly because the SERP does not. Several pages promising a delisting guide for this list describe submitting a request, fixing authentication records, or cleaning a list. None of those changes a registration date.

The operator does run a removal process for its other lists, and its FAQ publishes the turnaround: requests are "reviewed and processed within 24 hours of submitting the request", with the operator noting that denying a request still counts as processing it. Its FAQ also documents a policy-based listing class, which covers addresses that should never send mail directly, senders known to be attached to established spam operations, senders failing to honour unsubscribe requests, and senders building lists by scraping. That class is a real reputational judgement and it is the one worth avoiding. It has nothing to do with the age list.

Which SEM list is on your report

• ✓Yes: SEM-FRESH or another FRESH window: the domain is young, nothing is wrong, and it expires on schedule
• ✕No: SEM-BLACK: an IP list, a different object, and a real listing worth diagnosing
• ✕No: SEM-URI: a domain seen in mail sent to a trap, which is a reputational listing rather than an age one
• ✕No: A policy based listing: the operator's own judgement about scraping, unsubscribe handling or known operations
• ~Depends: A row that does not say which zone fired: go to the operator's own query rather than the aggregator

What it means for a cold outbound programme

The listing is not the finding. What the listing tells you is that a portion of the receiving world applies extra scrutiny to a domain for its first days of life, and that scrutiny does not end when the FRESH window does. It thins out.

Three things follow.

Do not treat the row as an incident. A brand new sending domain listed on an age list is the expected state. Escalating it, filing anything, or changing infrastructure in response is work spent on a clock that was going to run out anyway.

Do treat the window as a calendar constraint. Buy sending domains far enough ahead that the age lists have expired before the first campaign, and use the interval for the work that has to happen anyway: authentication records published and aligned, mailboxes created, volume ramped rather than stepped. The interval is not overhead if it is filled.

Do keep the distinction between age and reputation clear. A domain leaves an age list on a schedule. A domain does not leave a reputation problem on a schedule, because that is a private score rather than a published list and it responds to sending behaviour over weeks. The difference, and what actually moves the second one, is in email domain reputation and in how to improve domain reputation.

The architectural version is the one that makes all of this unremarkable. Sending domains are bought ahead of need and warmed before use, one purpose per domain so outbound cannot contaminate the mail that matters, and spare capacity exists so that a domain with a genuine problem is replaced rather than rescued. On that footing an age listing is a line in a monitoring log, and so is a Backscatterer row on the same report.

The short version

SEM-FRESH lists domains on registration age and nothing else. The operator's own specification says the list covers domains first registered in the last five days and that they are automatically removed after five days.

It is a domain and URI list rather than an IP list, so a page offering to remove your IP from it is describing something the zone cannot do. It is also one of five age windows the operator publishes, running from a single day up to thirty.

There is no delisting request, no form and no case to make. The criterion expires on its own. Advice to fix authentication or clean a list in response to this specific row is answering a different question.

For a cold email programme the useful response is a calendar change rather than a remediation. Register sending domains far enough ahead that the age windows have closed before the first campaign, and spend the interval publishing records and warming mailboxes.

If you would rather have sending domains bought, authenticated and warmed before a campaign needs them, we plan the first campaign for free.

The list specification, the expiry, the list type, the zone name, the FRESH family windows, the removal turnaround and the policy-listing class are taken from Spam Eating Monkey's own services and FAQ pages, rendered and fetched 2 September 2026. The top-level domain scope reported by MXToolbox is attributed to MXToolbox rather than to the operator. Verify current list behaviour with the operator before relying on it.