The import added fewer people than the file

Every row of the file went somewhere, and the import records which of four places. Work down this list in order, because the biggest gap between a file’s row count and a list’s growth is nearly always the first item rather than anything being wrong.

The counts are on the import itself and in the email that follows it, and they update as the file is read rather than only at the end.

Does the total match your file?

The import’s total counts rows it read as people, so it is one lower than your file’s line count whenever the first line is a header.

The header tick on the mapping screen decides that, and it is on by default. If the total is lower than expected by one, this is why, and nothing else needs looking at. If it is lower by a lot, the file was probably cut short by the size limit rather than by the import: uploads take a CSV up to 20 MB, and the import flow covers splitting a larger one.

How many were skipped?

Skipped is usually the largest of the three counts, and it means the address was already accounted for rather than rejected.

Three things land here. An address already on your list, which is what makes running the same file twice safe. An address repeated inside the file itself, which exports from other platforms produce more often than people expect, particularly where the export has one row per subscription rather than one per person. And an address on the suppression list because it previously hard bounced or reported spam anywhere on Issue Mint, which is never revived by an import, however the file arrived.

What does invalid actually mean?

Invalid means the row could not become a subscriber, and it covers two different failures under one count.

The first is a value that is not an email address: a blank cell, a name in the wrong column, a stray line at the bottom of a spreadsheet. The second is an address on a domain with no way to receive email at all, meaning the domain answers with no mail records and no address records, so every address on it is a guaranteed hard bounce. Neither leaves a subscriber row behind, because a subscriber for somebody who can never be contacted is a permanent record of nothing. An import is also the cheapest moment in the whole system to drop one, since a bounce later costs the reputation of the address your issues come from.

Which addresses were refused, exactly?

The addresses trimmed for their domain are listed by name in a panel above your subscriber list, for 180 days from the last time each one was seen.

The panel leads with the count and the reason, and Show them expands the list. Each row carries the address, the route it arrived by, the name of the file it last arrived in and the date, with a count beside anything that has turned up more than once. Copy to clipboard gives you the lot as plain text for pasting into a spreadsheet against your original file. Up to 100 addresses are listed at a time with a count of any beyond that. The refused addresses panel covers what is recorded and why the window exists.

Why is there no list of the malformed rows?

Issue Mint counts them and does not keep them, and that is a real gap rather than something hidden somewhere else in the product.

The refused list exists because a domain that cannot receive mail is a fact worth answering for weeks later. A row that was never an address in the first place is answerable from your own file: sort the email column, and the blanks and the obvious mistakes are together at one end. If the arithmetic still does not close, the missing rows are in your spreadsheet rather than in ours.

Could the domain check have been switched off?

Two situations stop addresses being trimmed at all, and both make the invalid count smaller rather than larger.

Issue Mint proves DNS is answering before it calls any domain dead, so a resolver having a bad afternoon switches trimming off for that run instead of condemning a whole list. And a single file may look up around two thousand distinct domains before trimming stops for the rest of it, because a dead domain is slow to prove dead and a scraped list is mostly dead domains. Past that point the remaining rows import untrimmed, which costs some bounces rather than a failed import. The domain check covers what it tests and what it deliberately will not.

Did the import stop before the end?

A very large file occasionally stops partway, and when that happens the counts are what actually landed rather than an estimate.

Rows are written in batches as the file is read, so everybody before the stopping point is a live subscriber rather than a half-finished state to undo. The email says so and gives the figures. Re-uploading the same file adds the rest and skips the people already on the list, so there is nothing to reconcile by hand and nothing to delete first.

Still stuck

Write to us with the newsletter, the file name and roughly when you uploaded it.

Refusals are grouped by domain on our side, and that grouping usually answers the question in one line: five addresses on one company domain that has since folded is the whole of the shortfall. Nobody writes in about a single address, so the domain view is the one we look at, and the file name is what finds it. None of the refused addresses ever counted towards your plan or towards the cap on hosted sending, so whatever the answer turns out to be, it changes nothing you are paying for.