Email Marketing Database: What a Bought One Costs After the Invoice

Email Marketing Database: What a Bought One Costs After the Invoice

A growth lead buys a B2B email database. Fifty thousand rows, filtered to a job title and a company size band, delivered as a CSV within the hour, cheaper than a month of anybody's time. Two weeks later the campaign is running, the bounce rate is in double figures, the sending domain is in trouble, and the invoice has already cleared.

Nothing in the file predicted that. The rows were formatted correctly, the addresses were syntactically valid, and the company names were spelled right. What the file could not tell anybody is where the addresses came from, when they were last true, or whether the platform about to send them would accept the job at all.

The phrase email marketing database covers three quite different objects, and the search results for it sell all three at once. Separating them is the useful work.

The word database is doing something the word list is not

A list is a set of rows assembled for one campaign against one premise, and it stops being useful the day that campaign ends. The lead list entry sets out what makes a row in one usable, and the defining word there is "for": a list is built for something.

A database is the thing lists are drawn from. It persists, it is queried repeatedly, it accumulates history against each record, and its value is supposed to grow rather than expire. That is a genuinely different asset with a different failure mode, because a list that goes stale gets rebuilt and a database that goes stale gets queried anyway.

The distinction matters commercially because the two are sold by different companies to the same buyer using the same words. A subscription data provider sells access to a queryable database. A list broker sells an export. A marketing platform sells the place your own database lives. Some of them describe what they sell as a database and others describe the same thing as a list, so the word tells you nothing about which purchase is on the table.

A marketing database you ownPeople who gave you the address

• Records arrive through your own surfaces and carry a consent basis
• Engagement history accumulates against each record
• You control the schema, the fields and the retention
• Value grows with the relationship
• Cannot be bought, only built

Subscription access to somebody else'sA directory you query

• Coverage is the product, and coverage of your segment is the only part that matters
• Every competitor in your category queries it with similar filters
• Records are exported, not owned, and the terms say so
• Value is speed rather than exclusivity
• Priced by seats and by export volume

A purchased exportA file, sold once

• No provenance on any field, so a bad row cannot be traced
• No date on when anything was last verified
• Prohibited outright by the platforms most likely to send it
• Sold to whoever else asked for the same filters
• The cheapest of the three and the only one with no residual value

The platforms that rank for this query forbid what several of the results are selling

This is the part worth reading before the price, because it decides whether the file you bought can be sent at all on the tool you already pay for.

Mailchimp's acceptable use policy lists, among the things a customer may not do, "Upload or send email Campaigns to purchased, rented, third-party, co-reg, publicly available data, or partner lists of any kind". Read that clause slowly. It is broader than a ban on buying: co-registration and publicly available data are also named, which covers a large share of how B2B records are assembled in the first place.

Brevo's anti-spam policy is more specific still, under a heading it calls "Bought & scraped lists". It states that lists of contacts "scraped on the internet, acquired or purchased from a third-party" are likely to damage its reputation as well as your deliverability, and that use of such lists is "strictly prohibited on our Software". The same policy requires that you be able to produce proof of opt-in for every contact, which a purchased file cannot supply by construction.

So a buyer can arrive at a search for an email marketing database, find a guide published by one of those platforms explaining how to build one, find a broker two results below it selling a finished one, and buy something their platform's own terms refuse. That is not a trap anybody set. It is two businesses answering one query.

The architectural conclusion is the same one email marketing lead generation draws about the two motions generally. Permission-based marketing and cold outbound want different platforms, different domains and different lists, and the moment a purchased file is loaded into the tool that sends to subscribers, both halves are exposed to whatever that file turns out to contain.

What a bad database costs is charged to the domain, not to the campaign

The invoice is the smallest number in this decision.

Google publishes the constraint plainly. Its sender guidelines page tells bulk senders to "Keep spam rates reported in Postmaster Tools below 0.10%" and to "avoid ever reaching a spam rate of 0.30% or higher". The same Google page also says, in its section for all senders, to "Keep spam rates reported in Postmaster Tools below 0.3%", so two figures sit on one official page and they do not agree. Plan against the stricter of the two.

Google's bulk sender guidelines page sets the other boundary, defining a bulk sender as one that sends "close to 5,000 messages or more to personal Gmail accounts within a 24-hour period". Two further sentences on that Google page decide how much a bad send can cost: "Messages sent from the same primary domain count toward the 5,000 limit", and "Bulk sender status doesn't have an expiration date".

Put those together and the arithmetic of a purchased database becomes visible. Complaints are measured as a rate against the domain rather than against the campaign, Google's stricter figure is a tenth of one percent, and the label that crossing it attaches is permanent. A file whose recipients have no memory of asking for anything produces complaints at rates a subscriber list never approaches, and the reputation being spent belongs to whatever else that domain sends.

1. Step 1The file is bought

   One invoice, paid once, and the only cost that appears in a budget line

2. Step 2The send goes out

   Bounces on addresses nobody typed in, complaints from people with no memory of subscribing

3. Step 3The rate is attributed to the domain

   Google measures spam rate per sending domain, so the campaign's worst day is charged to everything that domain sends

4. Step 4The status attaches

   Bulk sender obligations follow the primary domain and Google states they do not expire

5. Step 5Recovery is bought in weeks

   Reputation accrues at the pace receivers allow, which is not the pace a pipeline target requires

The consent basis belongs in a field, not in a memory

The one structural fix that costs nothing is recording, per record, how you came to hold it.

A database that stores a source and a date beside every address can answer the only two questions that ever matter afterwards. Which supplier produced the rows that behaved badly, and when was this address last confirmed. A database without those fields cannot be repaired, because there is no way to remove the bad batch without removing everything acquired around it, and the honest response to any problem becomes throwing the whole thing away.

The same field decides what you are allowed to send. Jurisdiction is a property of the record rather than of the campaign, and treating one global table under one policy is the common way this goes wrong. Storing the basis makes the segmentation possible; not storing it makes the question unanswerable at exactly the moment somebody asks it in writing.

Suppression is the other field, and it should be generous rather than scoped. A person who opted out of the newsletter should not appear in a cold campaign built from the same table, because from their side there is one company sending them mail.

Every database is a depreciating asset

A database looks like an appreciating asset and behaves like a depreciating one. People change jobs, companies restructure, domains are retired and mailboxes are closed, and every one of those events happens without telling you. The mechanism is set out under data decay, and the practical version is that the file you bought was already older than its invoice.

Two habits follow, and they are cheap.

Verify close to send time rather than at build time. Verification is a snapshot of one moment, and a snapshot taken in March says nothing useful about a send in June. What verification costs per thousand, and what it is worth against the cost of a bad send, is worked through in email list cleaning; the vendors and their catch-all handling are compared in email verification tools.

Keep the gap between acquiring a record and using it short. A database held for a quarter while copy is agreed is not the database that was acquired, and re-verification passes that are planned rather than scheduled tend not to run.

What the query is usually really asking

Most people searching for an email marketing database are trying to solve one of two problems, and the answer differs.

If the problem is that a permission-based programme needs somewhere to keep its subscribers, the answer is the platform you already send from, plus the discipline of syncing a defined segment rather than a whole CRM. A marketing database is people who opted in; a CRM contains those people plus prospects, plus lapsed contacts, plus everyone a sourcing tool ever created. Pushing the second into the first is how a compliance question and a billing surprise arrive on the same day.

If the problem is that outbound needs people to contact, the answer is a build rather than a purchase, and the reason is not principle. A subscription database is queried by everyone in your category using broadly similar filters, so a segment defined by three common conditions has been pulled repeatedly by companies selling adjacent things. The rows are correct and the audience is tired. Building against a criterion chosen for a reason specific to your own product does two jobs at once: it makes the message more true, and it reaches people who are not already saturated. The mechanics of building rather than buying sit in the custom scraping approach, and the domain architecture that has to exist underneath either route is in gmail bulk email sender.

Before the first send

• ✓Yes: Every record carries a source and a date the address was last confirmed
• ✓Yes: The consent or lawful basis is a stored field rather than an assumption about the batch
• ✓Yes: Addresses are verified close to send time, not at the time the file was delivered
• ✓Yes: Sending happens on domains that carry no corporate or marketing mail
• ✓Yes: Suppression is shared across every motion, so one opt-out removes the person everywhere
• ✓Yes: The platform's own terms permit the list you are about to upload
• ✕No: The whole CRM is synced in, because filtering it seemed like extra work
• ✕No: Row count is the number quoted when anybody asks how the database is doing

Where we stand

RevenueFlow runs cold email and LinkedIn outbound and does not run marketing email for clients, so nothing here is a recommendation between platforms. We build lists per campaign rather than maintaining a purchased database, we send from generic domains that are never the client's own, and every campaign carries exactly one message with no bumps and no thread replies. A second approach to the same company is a separate campaign with its own reason to exist.

That last position is not decoration on this subject. One message per campaign is what keeps complaint rates low enough that the thresholds above stay theoretical, and it is only affordable when the list is tight enough that the single message is true for everybody receiving it. A large purchased database and a one-message discipline pull against each other, which is the practical reason we do not hold one.

If the real question is whether a properly built list against your own market outperforms a file you can buy this afternoon, see what a first campaign produces and compare the two on replies rather than on row count.

Google's sender requirements and bulk sender guidelines, Mailchimp's acceptable use policy and Brevo's anti-spam policy were read from those companies' own pages on 28 August 2026, with dated snapshots retained. Policies change; confirm the current terms before relying on them. Nothing here is legal advice.

Sources: Google email sender guidelines, Google bulk sender guidelines, Mailchimp acceptable use policy, Brevo anti-spam policy