Refused addresses
When Issue Mint refuses an address because its domain cannot receive email, it writes the address down rather than only mentioning it once. The record appears in a panel above your subscriber list, and it is kept for 180 days from the last time the address was seen.
Where to find it
The panel sits at the top of the subscriber list for the newsletter concerned, and only when there is something in it.
It leads with the count and the reason: this many addresses could not be added, because their domain has no way to receive email, so anything sent to them would have bounced. It is collapsed, because on a healthy list this is a footnote rather than a warning and a box that shouts permanently stops being read. Show them expands the list, Copy to clipboard gives you the addresses as plain text for pasting into a spreadsheet, and the retention window is printed beside both. On a list where every row of an import was refused, this panel is the only thing on the page that explains why nothing arrived.
What is recorded against each address
Seven things, all of them about the address rather than the person.
- The address itself, lower cased.
- Its domain, stored separately so refusals can be grouped by it.
- The reason. There is one reason today, a domain that cannot receive email, and the panel says it once at the top rather than repeating it down a hundred rows.
- The route it arrived by, either an import or the add-by-hand dialog.
- How many times the address has been seen.
- When it was first seen.
- When it was last seen, and the name of the file it last arrived in, where it arrived in one.
Up to 100 addresses are listed at a time, with a count of any beyond that. The total above is always the real number.
Which routes record a refusal, and which do not
Imports and the add-by-hand dialog record. The signup form on your website and the embedded form deliberately do not, and the asymmetry is the point rather than an oversight.
You may well ask us about an address you typed in, a week after the message in the dialog has gone, and the same is true of the five addresses missing from a file of 683. A reader mistyping their own address on a public form is a different case entirely: they are told in the field, they fix it in a keystroke, and there is no later question for anybody to answer. Recording every bad address a public form receives would mean collecting people who never asked anything of us, at whatever volume the bots are running that week.
The 180-day window
Refused addresses are swept nightly, and the window is measured from the last sighting rather than the first.
The window is what keeps storing them defensible. These addresses are personal data belonging to people who never became subscribers, so the only justification for holding them is answering a question about an import, and nobody needs a two year old typo to do that. Measuring from the last sighting rather than the first means an old address that a recent import hit again is not aged out from under the person asking about it. What Issue Mint holds about you and your readers covers the rest of the retention picture.
What a repeat sighting changes
Uploading the same file twice does not create a second row. It bumps the one that is there.
The seen count goes up, the last-seen date moves to now, and the pointer to the import moves to the most recent file that hit the address, because the support question is about the attempt you have this minute made rather than one from March. The first-seen date never moves, since first sighting is the more useful fact and an update that overwrote it would erase the only thing that cannot be recovered. Rows showing a count above one are the interesting ones: an address you have now tried to import three times is either a typo you keep repeating or a domain somebody needs to be told has gone.
The domain breakdown
Refusals are grouped by domain on our side, and that grouping is what usually answers the question.
A curator does not write in asking about one address. They ask why a number is short, and five addresses on one folded company domain is the whole answer. The panel on your subscriber list shows the addresses themselves, newest sighting first, with the domain stored against each one; the grouped view by domain is on the support side of the same data, which is what we look at when you write in. Quoting the file name and roughly when you uploaded it is enough for us to find it.
What these rows are not
They are not subscribers, and nothing about them touches your sending.
No subscriber row exists for a refused address, so it was never mailed, has no issue history, and cannot be exported with your list or counted in it. That is also why these rows are the one thing in Issue Mint that a timer really does delete: nothing here is anybody’s archive, and losing one loses a note we wrote about a typo. Your issues, your list and your published archive are never on a schedule like that.
Questions
Can I put these addresses back on my list from the panel?
No. Nothing in the panel writes to your list. Copy the addresses out, work out what is wrong with the part after the at sign, and add them again or include the corrected version in another import.
Do refused addresses count towards my plan?
No. A refused address never became a subscriber, so it is in no count anywhere: not your plan limit, not the cap on hosted sending, not the total on your subscriber list, and not your growth chart.
Can I delete them before the window is up?
There is no per-address delete in the product. Deleting the newsletter removes its refused addresses along with it, and otherwise they age out on their own once nothing has seen them for the length of the window.
Try it on your own list.
14 days, every feature, no card. Sending works from the moment you sign up.
Start your trial