DEV Community: Sam

MX Records Explained: How Email Actually Finds You

Sam — Tue, 03 Nov 2026 14:00:00 +0000

The plain-English guide to mail routing. What MX records are, the ports that matter, SMTP versus ESMTP, hosted versus self-hosted servers, transport security, and a ready-to-paste Claude prompt that builds your server config for you.

Quick answer, in case that is all you came for:

An MX record is a DNS entry that names the mail server responsible for accepting email for your domain, along with a priority number. When someone emails you@yourcompany.com, the sending server looks up the MX records for yourcompany.com and connects to the host with the lowest priority number first. A typical record looks like 10 mx.yourprovider.com. Lower priority wins. No MX record usually means mail bounces. An MX record proves the domain can receive mail, but it does not prove a specific mailbox exists.

MX is about inbound mail. SPF, DKIM and DMARC are about outbound mail. Those are four different records doing four different jobs, and mixing them up is why people spend afternoons fixing the wrong thing.

The bounce that makes no sense

A customer tells you they emailed and got no reply. You check. Nothing arrived.

They forward you the bounce. It says something like Recipient address rejected: Domain not found, or it just sat in a queue for four days and gave up.

You check your website. It loads fine. Your domain clearly exists. So what happened?

Your domain has an A record pointing at your website and no MX record pointing at your mail. To a browser, everything is perfect. To a mail server, your domain has nowhere to put a letter.

This happens constantly during DNS migrations, after a hosting change, and on any domain where somebody set up the website and assumed email came along for free. It does not.

What is an MX record, in plain English?

MX stands for Mail Exchanger. It is defined in RFC 1035, with its role in mail routing spelled out in RFC 5321.

Think about a physical mailroom.

Your domain name is the company name on the front of the building. The MX record is the sign in the lobby that says "all deliveries to the loading dock around the back, and if that dock is closed, use the side entrance."

When a courier arrives with a package addressed to your company, they read that sign and go where it tells them. Without the sign, they stand in the lobby, then eventually take the package back to the depot.

That is an MX record. It is the delivery instruction for everything addressed to the part after the @.

Why the priority number exists

Every MX record has a number in front of the hostname:

10  mx1.provider.com
20  mx2.provider.com

Lower is preferred. The sender tries mx1 first because 10 is lower than 20. If mx1 does not answer, it falls back to mx2.

The numbers themselves are meaningless in isolation. 10 and 20 are conventional, but 1 and 2 work identically, as do 0 and 5. All that matters is the ordering.

Hosts sharing the same number are load balanced, used in random order. That is why Google Workspace tenants historically published five hosts at various priorities: redundancy plus spread.

How email actually gets delivered, step by step

This is the whole journey, from your keyboard to someone else's inbox.

Step 1. You hit send. Your mail client (the MUA, more on that terminology below) connects to your outgoing mail server, usually on port 587, and hands over the message with your username and password.

Step 2. Your server takes ownership. It queues the message and reads the recipient address, say sarah@example.com.

Step 3. It looks up the MX records for example.com. One DNS query. It gets back a list of hostnames with priority numbers.

Step 4. It resolves the lowest priority host to an IP address. Another DNS query, this time for the A or AAAA record of that hostname.

Step 5. It opens an SMTP connection on port 25. Server to server delivery always uses port 25. There is no alternative.

Step 6. The two servers negotiate. They greet each other, agree on extensions, and almost always upgrade the connection to encryption using STARTTLS.

Step 7. The message transfers. Sender address, recipient address, then the message itself.

Step 8. The receiving server runs its checks. SPF, DKIM, DMARC, reputation, content filtering, all of it.

Step 9. It accepts or rejects. If it accepts, the message is handed to a delivery agent that files it in Sarah's mailbox. If it rejects, your server generates a bounce back to you.

Step 10. Sarah reads it. Her mail client connects over IMAP and pulls it down.

Every one of those steps has a name, a port, and a protocol. Here they are.

Every term you need, decoded

This is the reference section. Nothing here is complicated once somebody writes it in plain English.

The three agents

Term	Stands for	What it actually is
MUA	Mail User Agent	The thing you look at. Outlook, Gmail's web interface, Apple Mail, Thunderbird.
MTA	Mail Transfer Agent	The server software that moves mail between servers. Postfix, Exim, Exchange, Sendmail. This is the piece MX records point at.
MDA	Mail Delivery Agent	Takes the message from the MTA and files it in the right mailbox. Dovecot, Courier, procmail.

A single machine often runs all three. In modern setups they are frequently separate services or separate providers entirely.

The protocols

Term	What it does	Direction
SMTP	Simple Mail Transfer Protocol. The language servers speak to hand mail to each other.	Sending
ESMTP	Extended SMTP. The modern version, which added extensions like STARTTLS, authentication, size limits and 8-bit characters. When a server greets you with EHLO instead of HELO, you are speaking ESMTP. Almost everything today is ESMTP.	Sending
IMAP	Internet Message Access Protocol. Your client reads mail that stays on the server, synced across devices.	Receiving
POP3	Post Office Protocol v3. Your client downloads mail and typically deletes it from the server. Largely obsolete.	Receiving
Submission	The specific act of a mail client handing a message to its own server, as opposed to server-to-server transfer. Uses port 587 with authentication.	Sending

The distinction that trips people up: SMTP moves mail, IMAP and POP3 read mail. They are not alternatives to each other. You use SMTP to send and IMAP to receive, both, always.

The security layers

Term	Spec	What it does
TLS	Transport Layer Security	Encrypts the connection. Replaced SSL, though people still say SSL out of habit.
STARTTLS	Part of ESMTP	Starts a connection unencrypted, then upgrades it to TLS. This is how nearly all server-to-server mail is encrypted. Its weakness is that an attacker in the middle can strip the upgrade offer.
Implicit TLS	Port 465	The connection is encrypted from the first byte. No upgrade step to strip.
MTA-STS	RFC 8461	Lets your domain declare that senders must use validated TLS and must never fall back to plaintext. Closes the STARTTLS stripping hole.
TLS-RPT	RFC 8460	Asks sending providers to send you daily reports on TLS delivery failures. Pure reporting. Cannot break anything.
DANE / TLSA	RFC 6698, RFC 7672	Pins your mail server's certificate in DNS. Requires DNSSEC. Common in the Netherlands, Germany and public sector, rare elsewhere.
DNSSEC	RFC 4033 to 4035	Cryptographically signs DNS answers so tampering is detectable. Without it, an attacker who can forge DNS can redirect your MX lookup entirely.

The reputation signals

Term	What it means
PTR / reverse DNS	Maps an IP address back to a hostname, published by whoever owns the IP block.
FCrDNS	Forward-Confirmed reverse DNS. The PTR name resolves back to the same IP it came from. Receivers strongly prefer this. Missing or generic reverse DNS is one of the oldest spam signals there is, and a frequent reason self-hosted mail gets rejected.
Greylisting	The receiver temporarily rejects a first delivery attempt from an unknown sender. Real servers retry. Most spam software does not.
Smarthost / relay	An external SMTP server your machine hands all outbound mail to, instead of delivering it itself. How you send mail when port 25 is blocked.
Catch-all	A domain that accepts mail for every possible address. Makes mailbox verification impossible.
Null MX	RFC 7505. A record of `0 .` (priority zero, a single dot) declaring the domain accepts no mail at all, so senders fail instantly instead of retrying for days.
Implicit MX	RFC 5321 behaviour where a sender finding no MX record may fall back to the domain's A record. Unreliable. Many senders do not try.

Email ports: which one, and when

This table answers more support tickets than any other single thing in this article.

Port	Protocol	Encryption	What it is for	Use it?
25	SMTP	STARTTLS	Server to server delivery. The only port MX delivery uses.	Yes, for MTAs. Never for mail clients.
587	SMTP submission	STARTTLS	Mail client to your own server, with authentication.	Yes. This is the default for sending from an app or client.
465	SMTPS	Implicit TLS	Client submission, encrypted from the first byte. Deprecated in 1998, then formally reinstated in 2018.	Yes, fine. Slightly safer than 587 in hostile networks.
2525	SMTP	STARTTLS	Not a standard. An unofficial alternative many providers offer when 587 is blocked.	Only as a fallback.
143	IMAP	STARTTLS	Reading mail.	Prefer 993.
993	IMAPS	Implicit TLS	Reading mail, encrypted.	Yes. Default for IMAP.
110	POP3	STARTTLS	Downloading mail.	Only if you have a reason.
995	POP3S	Implicit TLS	Downloading mail, encrypted.	Only if you have a reason.

The rule to remember: port 25 is for servers talking to servers. Port 587 is for you talking to your server. If a setup guide tells you to configure your email app on port 25, that guide is at least fifteen years out of date.

Port 25 and your cloud provider: the thing nobody warns you about

If you plan to run your own mail server, read this before you pick a host.

Almost every cloud provider blocks outbound port 25 by default. They do it because freshly created VPS instances are a favourite spam vector: a spammer spins one up, blasts a million messages, and abandons it. Blocking the port at the network layer kills that business model.

The consequence for you is that your mail server can receive mail perfectly and cannot send a single message. Your logs fill with connection timeouts and nothing explains why.

Here is roughly where the major providers sit:

Provider	Outbound port 25	Getting it opened
OVHcloud	Blocked by default at the network level	Unblock available through the Manager or a support request. Widely reported as granted on first request for accounts in good standing.
Hetzner	Blocked on new accounts	Opened on request, generally straightforward
DigitalOcean, Vultr	Blocked	Support ticket, usually granted with a stated use case
AWS EC2, Google Cloud	Blocked	Effectively a dead end. AWS largely stopped granting these years ago

A note on OVH specifically, since it comes up constantly in self-hosting discussions. OVH is one of the more permissive mainstream hosts here, and its unblock path is documented rather than discretionary. But "permissive" is not the same as "open by default." OVHcloud's own documentation states that outgoing port 25 is blocked by default across dedicated servers, VPS and Public Cloud instances to prevent abuse, and directs you to use port 587 or request an unblock.

Two things worth knowing before you rely on it:

The unblock is revocable. OVH runs anti-spam monitoring on its network. If mail from your IP gets flagged, port 25 is re-blocked, and repeated incidents extend the cooldown or make it permanent.
Behaviour can vary by data centre and account age. Test it the moment you provision, not the day before launch.

And the honest advice, whatever your host: just because you can deliver directly on port 25 does not mean you should. A brand new IP address has no sending reputation, and building one takes months of consistent, low-complaint volume. For most people the right architecture is to run your own server for receiving and for control, and relay outbound mail through an established provider as a smarthost. You keep ownership of your data and skip the reputation problem entirely.

Who actually runs the world's email

There is a useful distinction here between who hosts the mailboxes and what software runs the server. Both matter, for different reasons.

The hosted providers

As of August 2026, the picture is dominated by exactly who you would guess. Google Workspace sits at 17.4% of surveyed sites and Microsoft 365 at 13.5%. Together that is roughly 31% of domains. The concentration is far higher among large organisations.

The middle of that list is the interesting part. Hostinger, IONOS, GoDaddy, Namecheap, Zoho and OVH together represent an enormous number of small business domains where nobody has ever looked at the authentication setup.

Reading the provider from the MX hostname

This is a genuinely useful skill. MX hostnames are a fingerprint.

Provider	MX hostname pattern
Google Workspace	`smtp.google.com`, or the older `aspmx.l.google.com` set
Microsoft 365	`<tenant>.mail.protection.outlook.com`
Zoho Mail	`mx.zoho.com`, `mx2.zoho.com`, plus regional variants
Proton Mail	`mail.protonmail.ch`, `mailsec.protonmail.ch`
Fastmail	`in1-smtp.messagingengine.com`
Amazon WorkMail / SES	`inbound-smtp.<region>.amazonaws.com`
Mimecast	hostnames ending `mimecast.com`
Proofpoint	hostnames ending `pphosted.com`
Barracuda	hostnames ending `barracudanetworks.com`
Registrar or shared hosting	`mx1.registrar-servers.com`, `...secureserver.net`

The last three security vendors are worth calling out. Mimecast, Proofpoint and Barracuda are gateways. They sit in front of the real mailbox provider and filter everything. If you see one in an MX record, the actual mailbox host is hidden behind it, and the organisation is almost certainly an enterprise with a security budget.

The open source mail servers

If you self-host, this is the software that does the work.

The established MTAs:

Postfix. Written by Wietse Venema in 1997 as a secure alternative to Sendmail. Modular, well documented, sane defaults. The default choice for most new deployments.
Exim. Written at the University of Cambridge in 1995. Enormously flexible with a configuration language that can do almost anything. The default MTA on Debian and the standard in the cPanel shared-hosting world.
Sendmail. The original, dating to 1983. Still running in places. Its configuration format is legendary in the way that a difficult mountain is legendary.
qmail. Dan Bernstein's 1997 security-focused MTA. Development stalled for years. notqmail is the community continuation.
OpenSMTPD. From the OpenBSD project. Deliberately minimal configuration, security-first design.

The modern generation:

Stalwart. Combines MTA, delivery agent and IMAP access in one binary. Written in Rust.
Mox. All-in-one server with automatic TLS via Let's Encrypt, built-in DMARC analysis and webmail.
Chasquid. Lightweight, simple, with enforced TLS as a design principle.
KumoMTA. Built for high-volume outbound sending rather than general mailbox hosting.
Haraka. Node.js based, plugin-driven, popular where you need custom logic in the mail path.

The all-in-one stacks:

Mailcow, iRedMail, Mailu, Mail-in-a-Box, Modoboa, docker-mailserver, Poste.io.

Hosted versus self-hosted, honestly

I am going to be blunt, because a lot of writing on this topic is not.

The software is free. The operation is not. You are signing up for TLS certificate renewal, spam filtering that keeps working, blocklist monitoring, backups you have actually tested, security patching on an internet-facing service, and reputation management on an IP address that starts with none. The realistic cost is not the server, it is engineering hours forever.

Self-host when: you have a specific data residency or sovereignty requirement, you want to actually understand the stack, you are running a lab, or you have compliance rules that make third-party hosting difficult.

Use a provider when: email needs to work reliably and nobody on your team wants to be paged about it. Which is most people, most of the time. There is no shame in this.

The middle path is underrated: self-host for receiving and mailbox control, relay outbound through a reputable smarthost. You get the control without inheriting the deliverability problem.

MX versus SPF versus DKIM versus DMARC

These four get confused constantly, and fixing the wrong record is the usual outcome.

Record	Direction	Answers	Published at	Spec
MX	Inbound	Which server accepts mail for this domain, and in what order	example.com, type MX	RFC 1035, RFC 5321
SPF	Outbound	Which servers may send mail using this domain	example.com, TXT starting `v=spf1`	RFC 7208
DKIM	Outbound	Was this message signed by a key the domain published, and unaltered since	`selector._domainkey.example.com`	RFC 6376
DMARC	Outbound	What receivers should do when SPF or DKIM alignment fails, and where to report	`_dmarc.example.com`, TXT	RFC 7489

A domain can receive mail perfectly and still fail every outbound authentication check. These are separate systems. Getting your MX right does nothing for your deliverability when sending, and vice versa.

Full tutorial: publishing MX records

Step 1: Decide where mail should land

Pick your provider first. Changing MX records later is easy, but migrating mailboxes is not.

Step 2: Get the values

Google Workspace, newer tenants:

1   smtp.google.com

Older tenants using the five ASPMX hosts do not need to migrate. Both are supported. Do not mix the two sets.

Microsoft 365:

0   yourdomain-com.mail.protection.outlook.com

One host per tenant. The label is your tenant's onmicrosoft.com prefix with dots replaced by hyphens. Microsoft publishes the exact value in the admin centre. Never guess it.

Zoho Mail:

10  mx.zoho.com
20  mx2.zoho.com
50  mx3.zoho.com

Regional suffixes such as .eu and .in exist. Use the ones your Zoho console shows.

Your own server:

10  mail.yourdomain.com

Then create an A record for mail.yourdomain.com pointing at your server's IP, and set the PTR record for that IP to mail.yourdomain.com in your host's control panel. All three must agree. This is forward-confirmed reverse DNS, and skipping it is the most common reason self-hosted mail gets rejected.

A domain that sends and receives nothing:

MX     0 .
TXT    v=spf1 -all
TXT    _dmarc    v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com; fo=1

That 0 . is a null MX. It tells senders to fail immediately and cleanly rather than retrying for four days. Combined with an empty SPF and a reject policy, it closes a domain attackers would otherwise like precisely because nobody is watching it.

Publish this on every parked domain, defensive registration and web-only hostname you own.

Step 3: Add them in DNS

Field	What to enter
Type	MX
Name / Host	`@` or blank, meaning the root domain
Priority	The number, entered in its own field on most panels
Value / Points to	The mail server hostname, usually with a trailing dot
TTL	3600 normally. Lower it to 300 before a planned migration.

Three things that break setups:

Never point an MX record at an IP address. It must be a hostname. Point the hostname at the IP with a separate A record.
Never point an MX at a CNAME. It is explicitly not allowed and some senders will refuse it.
Remove the old records when you migrate. Leaving the previous provider's MX in place at a higher priority means some mail keeps landing in a mailbox nobody reads.

Step 4: Add transport security, in this order

Do these one at a time. The order matters because the first one cannot break anything and the last one can.

Step 4a: TLS-RPT. Reporting only. Completely safe.

TXT   _smtp._tls   v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com

You now get daily reports on TLS delivery to your domain, including expired certificates and stripped connections. This is how you find out about problems before your users do.

Step 4b: MTA-STS in testing mode.

Two parts. The DNS record:

TXT   _mta-sts   v=STSv1; id=20260817T000000

And a policy file served over HTTPS with a valid certificate at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: smtp.google.com
max_age: 604800

In testing mode, failures are reported through TLS-RPT rather than enforced. Nothing breaks.

Step 4c: Enforce. Change one word and update the id:

mode: enforce

Two things that catch people out. Every MX host you accept mail on must be listed in the policy file, or mail to the missing one fails. And you must change the id value whenever you edit the file, otherwise senders keep serving the cached policy until max_age expires.

Step 4d: DANE, only if your zone is DNSSEC-signed. Publish a TLSA record at _25._tcp.<your MX host>. DANE is meaningful only with DNSSEC, because the certificate pin is only trustworthy if the DNS answer itself is signed. It is widely deployed in the Netherlands, Germany and parts of the public sector, and rare elsewhere. MTA-STS is the more common route. Either beats neither.

Step 5: Test everything at once

Use the free MX Record Checker from EmailVerifyerAPI. It runs nine records in one query and explains each result in plain English.

One lookup returns:

MX hosts with priorities and TTLs
The mail provider, matched from the hostname patterns
SPF and DMARC, so you see the outbound half in the same view
MTA-STS, TLS-RPT and DANE, the transport security layer almost no free checker shows
Reverse DNS, resolving the primary MX to its IP and reporting the PTR
DNSSEC, reported through the authenticated-data flag on the MX answer
A verdict: configured, fallback only, or nothing at all

No account, nothing stored, and only the domain is sent to a public resolver.

What a real result looks like. Run github.com through it and you get one MX record at priority 0 pointing at github-com.mail.protection.outlook.com, immediately identifying Microsoft 365. SPF is published with a long list of includes covering Outlook, Google netblocks, Zendesk, Salesforce, Mailchimp, Marketo and SendGrid. DMARC is at p=quarantine with sp=reject and reporting enabled. MTA-STS, TLS-RPT and DANE are all absent. Reverse DNS resolves correctly. DNSSEC is unsigned.

That is a well-run domain that has done the authentication work and not yet done the transport work, which describes the large majority of the internet. Absence of MTA-STS and DANE is graded as amber rather than red for exactly that reason: it is an available hardening step, not a fault.

One documented limitation: MTA-STS has a DNS half and an HTTPS half. A browser-based tool can report the DNS half but cannot fetch the policy file from another origin. A domain with the TXT record but no reachable policy file is not actually enforcing anything, so verify the file loads yourself.

Pair it with the dedicated SPF, DKIM and DMARC checkers when you need to go deep on one record.

Step 6: Send a real test

Send a message to an address on the domain. Then send one from it. Both directions, because they exercise completely different records.

Why MX matters for your email list

There is a commercial angle here that is easy to miss.

Roughly 22% of marketing email addresses go invalid every year as people change jobs and companies fold, according to HubSpot's research. A domain-level MX lookup catches an entire category of those failures in a single query: dead domains, parked domains, and domains never configured for mail at all.

It is the cheapest possible bounce check. It costs one DNS query and it runs in milliseconds.

What it cannot tell you is whether a specific mailbox exists. Only an SMTP handshake can attempt that, and catch-all domains accept every address anyway, so even then the answer can be inconclusive. MX proves the door exists. It says nothing about who lives there.

The seven mistakes I see most often

No MX record on a domain that receives mail. The A record fallback is unreliable and many senders never try it.
MX pointing at an IP address. Not allowed. Use a hostname with its own A record.
MX pointing at a CNAME. Also not allowed, and some senders will hard fail.
Old provider's MX left in place after a migration. Mail quietly splits between two mailboxes.
No PTR record on a self-hosted sender. One of the oldest spam signals in existence.
Nothing on parked domains. Publish the null MX.
Confusing MX with SPF. Adding your sending platform to your MX records does absolutely nothing. MX is inbound only.

A ready-to-paste Claude prompt for building your mail server

If you are going to self-host, this is where an LLM genuinely earns its keep. Mail server configuration is a large amount of interlocking, well-documented, unforgiving detail, which is exactly the shape of problem Claude is good at.

Copy the prompt below, fill in the bracketed values, and paste it into Claude. Ask follow-up questions as you work through it rather than trying to execute the whole thing blind.

You are an experienced mail server administrator. I want to deploy a
production-grade mail server and I need a complete, ordered configuration
plan I can follow step by step.

MY SETUP

Domain: [yourdomain.com]
Hosting provider: [OVHcloud / Hetzner / DigitalOcean / other]
Server type and specs: [VPS, 4 vCPU, 8 GB RAM, Ubuntu 24.04]
Static IPv4: [x.x.x.x] IPv6: [yes / no]
Expected volume: [e.g. 200 messages/day outbound, 20 mailboxes]
Outbound port 25 status: [open / blocked / unblock requested]
Preferred stack: [Postfix + Dovecot / Mailcow / Stalwart / recommend one]
Outbound delivery: [direct on port 25 / relay through a smarthost]
My Linux comfort level: [beginner / intermediate / advanced]

WHAT I NEED FROM YOU

STACK RECOMMENDATION
Given my volume, comfort level and provider, recommend a stack and
explain the tradeoff in two or three sentences. If self-hosting is a
bad idea for my situation, say so plainly and tell me why.
PRE-FLIGHT CHECKS
Exact commands to verify before I install anything: is outbound port 25
actually open, is my IP on any major blocklist, can I set a PTR record
with this provider, is my IP range already burned.
DNS RECORDS
Give me every record as a table I can work through: MX with priority,
the A record for the mail hostname, PTR, SPF, DKIM, DMARC starting at
p=none, TLS-RPT, and MTA-STS in testing mode. Show the literal values
with my domain substituted in. Flag which ones I must get from the
software after installation rather than write in advance.
INSTALLATION
Ordered commands for my exact OS version. After each block, tell me
what to check to confirm it worked before moving on.
TLS
Certificate issuance and automatic renewal. Which ports listen with
implicit TLS and which use STARTTLS, and why.
SECURITY BASELINE
Firewall rules with the specific ports. SASL authentication so I am
not an open relay, and the exact command to verify I am not. Rate
limiting. fail2ban. Disable anything I do not need.
ANTI-SPAM
Inbound filtering (rspamd or SpamAssassin), and the outbound hygiene
that keeps my IP clean.
DELIVERABILITY WARM-UP
A realistic schedule for a brand new IP with no sending history, and
the specific signals that tell me it is going badly.
VERIFICATION CHECKLIST
Every test to run before I trust this with real mail: authentication
headers on a delivered message, open relay test, TLS check, blocklist
check, MX and reverse DNS confirmation.
OPERATIONS
What to monitor, what to back up, what breaks silently, and what to
check monthly. Include the specific log lines that indicate trouble.

RULES

Ask me clarifying questions before generating the plan if any of my answers above are ambiguous or contradictory.
Explain the reasoning behind each significant choice in one line. I want to understand the system, not just paste commands.
Flag every step that is destructive or hard to reverse.
Where a hosted service would be the better engineering decision, say so.
Assume I will get something wrong, and tell me how I will know.

Two caveats worth stating. Verify every command against the official documentation for your distribution and your software version before running it on a production box, because syntax drifts between releases. And check the output against your provider's own docs on port 25 and PTR records, since those policies change and are provider-specific.

Used well, this turns a multi-day research project into an afternoon. Used carelessly, it turns into an open relay. The difference is whether you read what you are pasting.

Frequently asked questions

What is an MX record?

A DNS record naming the mail server responsible for accepting email for a domain, along with a priority number. Sending servers look up the MX records for the part after the @ and connect to the host with the lowest priority value first.

What does the MX priority number mean?

It sets the order senders try the listed hosts. Lower numbers are tried first, so priority 10 is preferred over 20. Hosts sharing the same value are used in random order to spread load. Higher-numbered hosts act as backups.

What happens if a domain has no MX record?

RFC 5321 allows a sender to fall back to the domain's A or AAAA record, known as the implicit MX rule. In practice this is unreliable, since many providers do not attempt it, so mail is likely delayed or rejected. A domain with neither MX nor A records cannot receive mail at all.

Does a valid MX record mean the email address exists?

No. It only proves the domain has somewhere to deliver. Confirming a specific mailbox requires an SMTP handshake, and catch-all domains accept every address, so even that can be inconclusive.

What is the difference between port 25 and port 587?

Port 25 is for server-to-server delivery between mail transfer agents. Port 587 is for a mail client submitting a message to its own server, with authentication. Configure your apps and clients on 587. Never on 25.

What is the difference between SMTP and ESMTP?

ESMTP is the extended, modern version of SMTP. It added STARTTLS encryption, authentication, message size limits and 8-bit character support. A server greeting with EHLO rather than HELO is speaking ESMTP, which today is essentially all of them.

What is the difference between IMAP and POP3?

IMAP leaves mail on the server and syncs it across devices. POP3 downloads mail to one device and typically deletes the server copy. Use IMAP unless you have a specific reason not to.

Why is my cloud provider blocking port 25?

To prevent spam from compromised or disposable instances, which are a major source of abuse. Most providers will unblock it on request with a stated legitimate use case. AWS and Google Cloud are the notable exceptions where it is effectively permanent.

Can I use OVH for a mail server?

Yes, and it is one of the friendlier mainstream hosts for it. Outbound port 25 is blocked by default at the network level, but OVH provides a documented unblock path through the Manager or a support request, generally granted for accounts in good standing. Be aware the unblock is revocable if the IP is later flagged for spam.

What is MTA-STS and do I need it?

MTA-STS lets your domain declare that senders must use validated TLS and must never fall back to plaintext, closing the hole where an attacker strips the STARTTLS offer. It is not required, but it is a meaningful hardening step. Deploy TLS-RPT first, then MTA-STS in testing mode, then enforce.

What is a null MX record?

A record of 0 . declaring that a domain accepts no mail. Senders fail immediately and cleanly instead of retrying for days. Publish it on every parked and brand-defensive domain you own, alongside v=spf1 -all and a DMARC reject policy.

Can an MX record point to an IP address or a CNAME?

No to both. An MX record must name a hostname, and that hostname must resolve through an A or AAAA record, not a CNAME. Pointing an MX at a CNAME is explicitly disallowed and some senders will reject it.

Which open source mail server should I use?

Postfix paired with Dovecot is the conventional answer and the best documented. Mailcow or iRedMail if you want a full stack with a control panel rather than assembling one. Stalwart or Mox if you want a modern single-binary approach. Exim if you are already in the cPanel world.

Why do my MX changes not show up yet?

DNS answers are cached for the length of each record's TTL. Until it elapses, resolvers may keep serving the old answer. Lower the TTL before a planned migration and raise it afterwards.

Your action plan

Right now, 5 minutes:

Run your domain through the free MX checker.
Confirm you have MX records, that they point at hostnames rather than IPs, and that no old provider is still listed.
Note whether SPF and DMARC came back found.

This week, 30 minutes:

Publish the null MX set on every parked domain you own.
Add TLS-RPT. It is one record and it cannot break anything.
If you self-host, confirm your PTR record resolves forward and back.

This month:

Deploy MTA-STS in testing mode, read the TLS-RPT reports, then enforce.
Finish the outbound side: SPF, then DKIM, then DMARC to enforcement.
Set a quarterly reminder to re-run all four checkers.

MX is the record that decides whether mail reaches you at all. Everything else in email authentication decides whether your mail reaches other people. You need both, and they are entirely separate jobs.

If you only do one thing today, run your domain through a checker and see what nine records say about a setup you probably have not looked at in years.

Cybersecurity in 2026: What 2025 Broke and What You Need to Do About It

Sam — Wed, 28 Oct 2026 13:00:00 +0000

Let me give you the short version first.

2025 was the year attackers stopped breaking down doors and started walking in with stolen keys. 2026 is the year they handed those keys to an AI agent. And 2027 is the year the cryptography under all of it starts to change for real, driven by post-quantum standards like ML-KEM.

If you only do three things this year: kill reused passwords, inventory your encryption, and treat every AI agent in your stack as a privileged user.

I have been writing about growth and technology for a long time. I have never seen a security cycle move this fast. So I am going to walk you through it the way I would explain it to a friend over coffee. No jargon walls. No fear selling. Just what happened, what it means for you, and what to do about it.

Let's get into it.

What Actually Changed in 2025

For years, the story of a breach was simple. Someone clicked a bad link, malware landed, and defenders hunted the malware. In 2025 that story fell apart.

Credentials and tokens became the main event.

The clearest example was the Salesloft Drift incident. Attackers tracked as UNC6395 compromised the Drift chatbot integration and stole the OAuth tokens that connected it to customer Salesforce environments. Between August 8 and 18, 2025, they used those tokens to query and export data from hundreds of organizations. The tokens were trusted, so nothing looked wrong.

Coverage from SOCRadar lists an affected roster that reads like a who's who of the security industry itself: Cloudflare, Zscaler, Palo Alto Networks, Tenable, CyberArk, Proofpoint, and many more.

Read that again. Security vendors got hit through a chatbot integration. Not because their firewalls failed, but because a trusted connector held a long-lived token.

Supply chains became the fastest way in. The Shai-Hulud campaign turned npm into a self-propagating attack surface. Unit 42 documented the second wave, which executed during pre-install rather than post-install and exposed secrets across more than 25,000 repositories tied to roughly 350 users. IBM's X-Force team later reported that major supply chain and third-party breach incidents quadrupled over five years.

And then AI stopped being a helper and became an operator.

In November 2025, Anthropic disclosed that it had detected and disrupted a campaign it attributed to a Chinese state-sponsored group tracked as GTG-1002. The group used Claude Code, orchestrated through the Model Context Protocol, to run reconnaissance, vulnerability discovery, exploitation, credential harvesting, lateral movement, and exfiltration against roughly 30 high-value targets.

The detail that matters: the AI executed an estimated 80 to 90 percent of the tactical work, with humans mostly approving phase transitions. The threat actor got past model safeguards by convincing the system it was doing authorized defensive testing.

That is the moment the industry now points to as the dividing line.

What 2026 Looks Like Right Now

Here is the current picture, backed by numbers rather than vibes.

Phishing is not dying. It is specializing. Microsoft telemetry cited by Convergence Networks shows roughly 7.6 billion phishing threats detected in a single three-month window this year, with credential phishing accounting for 94 to 96 percent of malicious payload attacks each month in the second quarter of 2026. Traditional malware made up only 4 to 6 percent. QR code phishing peaked at 18.7 million attacks in March 2026.

Attackers do not want to infect your laptop anymore. They want your login, because a valid login does not trigger anything.

AI risk moved to the top of the executive worry list. The World Economic Forum's Global Cybersecurity Outlook 2026 found that 87 percent of respondents identified AI-related vulnerabilities as the fastest-growing cyber risk. The FBI's IC3 recorded more than 22,000 AI-related complaints and over $893 million in adjusted losses for 2025.

Defenders are still slow where it counts. The 2026 Verizon Data Breach Investigations Report found a median of 43 days to fully resolve known vulnerabilities, with only 26 percent of CISA-listed critical vulnerabilities fully remediated across the 13,000 organizations surveyed.

Operational technology is being mapped, not just probed. Dragos now tracks 26 OT threat groups. Its year in review describes adversaries actively mapping control loops to manipulate physical processes with precision, including wiper deployments against Ukrainian ISPs and Polish combined heat and power facilities in December 2025.

And the internet's cryptography is half-migrated. A 2026 measurement study of post-quantum readiness found that 50.7 percent of analyzed domains remain fully reliant on classical key exchange, while 49.3 percent already negotiate hybrid post-quantum key exchange. That second number would have been near zero three years ago.

Which brings us to the part everyone finds intimidating and nobody should.

Post-Quantum Cryptography in Plain English

Let me strip this down.

Most of the encryption protecting your traffic today does two different jobs with two different kinds of math.

Symmetric encryption (AES-256) scrambles the actual data. A quantum computer weakens it somewhat, but doubling key length handles that. AES-256 is fine.

Public-key cryptography (RSA, elliptic curve) handles key exchange and signatures. This is the part that lets your browser agree on a secret with a server it has never met. A sufficiently large quantum computer running Shor's algorithm breaks it completely.

So the migration is not about replacing all encryption. It is about replacing the handshake and the signatures.

What ML-KEM Actually Is

ML-KEM stands for Module-Lattice-Based Key-Encapsulation Mechanism. It was standardized by NIST as FIPS 203 in August 2024, based on the CRYSTALS-Kyber submission. Two companions shipped alongside it: ML-DSA (FIPS 204, signatures, from Dilithium) and SLH-DSA (FIPS 205, hash-based signatures, from SPHINCS+).

A KEM is simpler than it sounds. Instead of encrypting a secret and sending it, the sender generates a shared secret and a ciphertext at the same time, sends the ciphertext, and the receiver uses their private key to recover the same shared secret. Same outcome as a key exchange, different mechanics, and the underlying math (module lattices) has no known efficient quantum attack.

ML-KEM comes in three sizes: 512, 768, and 1024. Higher numbers mean bigger keys and higher security levels. ML-KEM-768 has become the practical default on the open internet. ML-KEM-1024 targets NIST Security Level 5, which is what you use when the data has to stay secret for decades.

Why Everything Is Hybrid

Nearly every real deployment pairs a classical algorithm with a post-quantum one. You will see X25519 + ML-KEM-768 in TLS, or X448 + ML-KEM-1024 in higher-assurance systems. Both key exchanges run, and the results are combined. If the lattice math turns out to have a flaw, the classical half still protects you. If a quantum computer arrives, the post-quantum half still protects you.

Research on hybrid key exchange has consistently shown minimal performance overhead, which is why adoption moved as fast as it did.

Harvest Now, Decrypt Later

This is the reason you cannot wait for Q-Day to act.

An adversary records your encrypted traffic today. They cannot read it today. They store it. When a cryptographically relevant quantum computer exists, they decrypt the archive. Diplomatic cables, health records, source code, legal discovery, and financial archives all have shelf lives measured in decades.

Mosca's Theorem puts it simply: if the time your data must stay secret, plus the time your migration takes, exceeds the time until a cryptographically relevant quantum computer arrives, you are already late.

So When Is Q-Day?

Nobody knows, and anyone selling you a date is selling something.

The most respected longitudinal source is the Global Risk Institute Quantum Threat Timeline, run by Michele Mosca and Marco Piani. Their 2025 edition surveyed 26 experts and put the averaged probability of a cryptographically relevant quantum computer within ten years at 28 to 49 percent, the highest estimate in the report's seven-year history. Most agency planning centers on the 2030 to 2035 window. Some vendor roadmaps are far more aggressive.

What moved those numbers is not qubit counts. It is resource estimates falling. Estimates for breaking RSA-2048 dropped from roughly 20 million physical qubits in 2019 to under one million in 2025 analyses. The bar is being lowered from the software side while hardware climbs from below.

The Deadlines That Already Exist

NIST IR 8547 (draft transition framework): RSA-2048 and ECC-256 deprecated by 2030, disallowed after 2035.
NSA CNSA 2.0: quantum-resistant algorithms required for National Security Systems on a timeline anchored to 2030 to 2035.
AWS: ML-KEM support live in KMS, ACM, and Secrets Manager, with legacy Kyber support removed across endpoints in 2026.
Cloudflare: post-quantum authentication to origins by mid-2026, visitor-facing by mid-2027.
Google: 2029 target. Microsoft: full transition by 2033, per The Quantum Insider's roadmap comparison.

One More Thing Worth Knowing

In July 2026, NIST noted that Anthropic had used an AI model to discover a vulnerability in HAWK, a lattice-based signature scheme that was under consideration for standardization. The HAWK team withdrew it. The finalized standards, ML-KEM and ML-DSA, rest on different foundations and were unaffected.

I love this story because it captures the whole moment. AI is now fast enough to break cryptography candidates before they ship. That is terrifying and reassuring at the same time, and both feelings are correct.

Passwords Are Still the Front Door

Here is the uncomfortable truth: while everyone debates quantum timelines, the overwhelming majority of real intrusions still start with a credential.

Credential phishing is 94 to 96 percent of malicious payloads. Infostealer logs feed criminal marketplaces daily. Password reuse turns one forgotten forum breach into access to your email, and your email is the master key to everything else.

So what should a password manager actually do in 2026? My criteria:

Zero knowledge by architecture, not by policy. The vendor should not be able to see your data even if compelled.
Modern key derivation. Argon2id with a serious memory cost, not fast hashing that GPUs chew through.
Offline breach checking. Checking your passwords should not require sending anything anywhere.
Hardware key support. FIDO2 and WebAuthn, ideally bound into key derivation, not bolted on as a login gate.
Post-quantum key wrapping. Mostly relevant for exports and long-lived wrapped keys, but relevant.
Open source with reproducible builds. If you cannot read it, you are trusting marketing.

Most mainstream managers hit two or three of these. Which is why a newer project caught my attention.

A Close Look at PWDnow

PWDnow is an open-source, local-first password manager built by a small team in Montreal. The source lives at github.com/PWDnow/PWDnow-password-manager under an MIT license. I want to explain how it works, because the design is genuinely different from what most people are used to, and because understanding it teaches you what zero knowledge is supposed to mean.

The Core Idea: A Hard Process Boundary

Most password managers run their cryptography inside the same application that renders the interface. PWDnow splits them.

A Rust daemon does every cryptographic operation: key derivation, encryption, decryption, storage, memory locking, wiping.

A React and Express web layer renders the interface and never receives a key of any kind.

They talk over a Unix domain socket using MessagePack frames. Every request carries a session token, and the daemon verifies the identity of the connecting process at the OS level using SO_PEERCRED, so only the trusted proxy running as the correct system user can reach it.

The practical consequence: a cross-site scripting bug in the interface cannot leak your vault, because the interface never had it. It only ever held opaque ciphertext.

The Key Hierarchy, Step by Step

This is the part worth understanding, because it is how modern vaults should be built.

You type your master password. It goes to the daemon and nowhere else.
Argon2id derives a Key Encryption Key. The memory cost is set to 1 GiB. That number is deliberate. GPU brute-force farms scale on parallelism, and parallelism gets expensive fast when every guess needs a gigabyte of RAM.
The Key Encryption Key unwraps the Vault Master Key. The Vault Master Key lives in memory locked with mlock so it cannot be swapped to disk, sealed with mprotect(PROT_NONE) while idle so other processes cannot read the page, and zeroized the moment it is no longer needed.
The Vault Master Key unwraps per-credential Data Encryption Keys. Every credential gets its own key. Compromising one does not compromise the vault.
The whole database sits inside a SQLCipher envelope. That is three independent layers before anything touches disk.
If a hardware security key is registered, the token's HMAC-SHA256 response is folded directly into the derivation, which cryptographically ties the vault to physical possession of the key rather than merely gating the login screen.

The Post-Quantum Part

PWDnow runs hybrid key encapsulation by default, not as an opt-in flag. The repository documents hybrid X25519 with ML-KEM-768/1024, and the project site describes an X448 with ML-KEM-1024 configuration targeting NIST Security Level 5 and CNSA 2.0 readiness. Signatures use ML-DSA-87, including nightly root-signing of the audit log chain, where each event is linked by BLAKE3 or SHA-384 hashes.

There is also a CNSA 2.0 strict mode that restricts the daemon to the NSA's approved suite, removing BLAKE3, SHA3, XChaCha20, Ed25519, and X25519 from active code paths. That is an unusual feature for a consumer-facing tool and a genuinely useful one for anyone with federal or defense obligations.

Let me be straight with you about what this buys you. Your stored passwords are protected by AES-256-GCM, which is already quantum-resistant enough. The post-quantum layer matters for wrapped keys, exports, and any material that moves between machines or gets backed up somewhere an adversary might be quietly archiving. That is real, but it is not the reason to switch on its own.

Offline Breach Detection

This is my favorite feature, and it solves a problem most people do not know they have.

When a typical manager checks whether your password appeared in a breach, it sends a partial hash to an online service. That is designed carefully (k-anonymity), but it is still a network call tied to your vault activity.

PWDnow builds a Cuckoo filter from the Have I Been Pwned password corpus, over 900 million hashes, compressed into a structure small enough to sit on your disk. A Cuckoo filter answers "is this item probably in the set" in constant time with a small, tunable false-positive rate and no false negatives. Lookups happen entirely locally. Zero network calls per password.

Duress Mode and Travel Mode

Two features aimed at situations most software pretends do not exist.

Travel mode hides a chosen subset of credentials behind a separate password. You hand over a device at a border, and the vault that opens is real, complete, and boring.

Duress mode arms an alternate password that, when entered, triggers a forensic wipe instead of granting access. The project describes this as a NIST SP 800-88 Rev. 2 compliant cryptographic erase using a 32-byte wipe ticket, destroying the SQLCipher key material so the database becomes unrecoverable.

Handle duress mode with respect. It does exactly what it says.

Exports, Imports, and Moving Between Machines

The native format is .p2w: a double-AEAD encrypted file with an inner AES-256-GCM layer and an outer XChaCha20-Poly1305 layer, padded and metadata-obfuscated to resist traffic analysis, with the header bound into both authentication tags. It also imports from Bitwarden, 1Password (CSV and 1PUX), NordPass, and KeePass-compatible XML.

There is no automatic cloud sync. Moving a vault between devices means exporting the encrypted file and importing it yourself. That is a deliberate trade, and you should decide whether you want it.

Installing It

git clone https://github.com/PWDnow/PWDnow-password-manager.git
cd PWDnow
./install.sh

The installer detects your distribution, checks dependencies, audits your SSH configuration, builds daemon and frontend from source, and installs both as systemd services under dedicated unprivileged users. The deployment hardening is thorough: MemorySwapMax=0, NoNewPrivileges, PrivateTmp, only the CAP_IPC_LOCK capability the daemon actually needs, plus an AppArmor profile confining filesystem and capability access at the kernel level.

Building from source needs Node.js 24+, Rust 1.94+, protoc, and development headers for libsodium, sqlcipher, and libfido2.

The Honest Limitations

I am not going to sell you a fantasy.

Linux only. Primary testing is on Ubuntu 26.04 LTS, with Debian and RHEL family support in the installer. There is no macOS or Windows build.
No cloud sync and no mobile app. If you live across five devices including a phone, this is not a drop-in replacement for a commercial manager.
It is young. The repository is early, the star count is low, and CI includes mutation and chaos testing but the project has not published a third-party audit. Open source means you can verify it. It does not mean someone else already did.
Duress mode is irreversible. That is the point, and it is also a foot gun. Keep an encrypted backup somewhere safe.

Who should use it: Linux users, developers, journalists, researchers, and anyone whose threat model includes device seizure or who simply does not want a vendor holding their vault at all. Who should not: someone who needs seamless phone sync today.

What I like most is that it is a working reference implementation of how a vault should be built. Even if you never install it, read the architecture doc. It will change what you expect from whatever you use.

The New Attack Shapes Nobody Has a Playbook For

Indirect Prompt Injection

This is the big one, and most teams still underestimate it.

Direct prompt injection is a user typing malicious instructions into a model. Annoying, mostly contained. Indirect prompt injection is malicious text planted in something an AI agent later reads on its own: a web page, a calendar invite, a support ticket, a PDF, a log line, an issue comment.

The root cause is architectural. As Sysdig puts it, models cannot reliably distinguish instructions from data, because both arrive as natural language text. OWASP ranked it LLM01, the top risk for LLM applications, and it remains the highest-ranked risk in the 2026 update.

The pattern behind nearly every real finding: an agent with access to private data, exposure to untrusted content, and the ability to communicate externally. Any two of those is manageable. All three is exploitable.

It is no longer theoretical. Unit 42 documented the first real-world malicious indirect prompt injection in December 2025. Critical CVEs have landed against Microsoft Copilot (CVSS 9.3), GitHub Copilot (9.6), and Cursor IDE (9.8). Brave's security team demonstrated injections against an AI browser using instructions hidden in white-on-white text and HTML comments, causing it to fetch one-time passcodes from email when the user simply asked it to summarize a page.

Agent Hijack Chains

The useful way to think about this is as a sequence, not a category. Influence the agent, let the agent's existing credentials authorize the action, let the agent's tool access execute it. Old techniques, new privilege boundary.

The uncomfortable part: you deployed an agent to improve productivity, and it quietly became a privileged execution surface with no audit trail that captures what it did, why, and with what authority.

Token and Connector Abuse

Salesloft Drift was the template. Long-lived OAuth tokens bypass MFA entirely, because MFA already happened when the token was issued. Attackers stayed inside API rate limits and deleted bulk query jobs after execution to avoid detection. Now extend that to MCP connectors wiring AI agents into your email, CRM, and code hosts.

Self-Propagating Supply Chain Worms

Shai-Hulud infected a package, harvested the maintainer's credentials, found their other packages, injected itself, and published. No human in the loop. Moving execution to pre-install widened the blast radius across developer machines and CI/CD pipelines.

AI-Assisted Social Engineering

The Microsoft Digital Defense Report 2025 found AI-crafted phishing achieving roughly three times the click-through rate of traditionally written lures. Add voice cloning, and "verify by calling them back" stops being reliable advice unless the callback number came from somewhere you trust.

Ransomware That Does Not Want Your Money

One shift I did not expect: some campaigns now aim at destruction rather than extortion. As PKWARE noted, fewer victims are paying because recovery has improved, so some operators pivoted to wiping devices outright. Your backup strategy is now your primary defense, not your fallback.

AI in Security: Who Is Actually Winning?

Everyone asks whether AI helps attackers or defenders more. The honest answer is that it helps whoever iterates faster, and right now that advantage is unevenly distributed.

The Offensive Column

GTG-1002 ran 80 to 90 percent of an espionage campaign autonomously against roughly 30 targets.
XBOW, an autonomous offensive security company, reached number one on HackerOne's global leaderboard with over 1,060 validated submissions.
Attack timelines compressed brutally. Some groups now move from initial access to lateral movement in well under a minute.
Open-source autonomous pentesting tooling now spans 39 or more active projects, most less than 18 months old. The capability is not gated behind nation-state budgets.

The Defensive Column

Google's Big Sleep found the first AI-discovered zero-day in production software, a SQLite buffer underflow that fuzzing had missed for years.
DARPA's AIxCC finals had systems analyze 54 million lines of code, identify 86 percent of synthetic vulnerabilities, and patch 68 percent. The best-performing team patched 43 of the 54 vulnerabilities their system found. Several finalist systems were open-sourced.
In February 2026, Anthropic reported more than 500 high-severity vulnerabilities in open source software found with Claude Opus 4.6. AISLE reported 12 OpenSSL zero-days, including a CVSS 9.8 issue dating back to 1998.
Agentic SOC models are moving from pitch decks to production, with AI handling triage, enrichment, detection rule generation, and first-line investigation.

My Read

Three observations.

One: AI is strongest at exactly the tasks that used to slow attackers down. Reconnaissance, reading unfamiliar code, writing exploit variants, and sorting through exfiltrated data are all expensive human work. They are now cheap.

Two: Defense has a structural advantage nobody talks about. Defenders have source code, build systems, and telemetry. Attackers usually have a binary and a login page. Big Sleep works because it reads the source. If you run the agents on your own code before shipping, you get to find bugs first.

Three: The bottleneck is organizational, not technical. A 43-day median remediation time and 26 percent completion on known-exploited vulnerabilities is not a model capability problem. AI that finds 500 bugs is a burden if your process can only fix five per sprint.

Whoever fixes the throughput problem wins the next two years.

What to Expect in 2027

Predictions with my confidence level attached, because unqualified predictions are just marketing.

Post-quantum goes visitor-facing. (High confidence) Hybrid key exchange is already near half of measured domains. Cloudflare's roadmap targets post-quantum authentication for visitor connections by mid-2027. Expect PQ certificates and signature migration, which is harder than key exchange, to become the active problem.
Crypto-agility becomes a procurement requirement. (High confidence) The lesson of HAWK's withdrawal is that algorithms can fail on short notice. Expect contracts to start asking how fast you can rotate an algorithm, not just which one you use. Hard-coded crypto in IoT, SCADA, and firmware becomes the visible laggard.
Agent identity becomes a real product category. (High confidence) Every agent needs an identity, scoped permissions, an audit trail, and a revocation path. Most organizations currently give agents a human's credentials and hope. That will not survive the first large agent-driven breach with a regulator attached.
The first major breach attributed primarily to prompt injection. (Medium-high confidence) The ingredients are all present. The only reason it has not been a headline incident yet is disclosure lag and attribution difficulty.
Regulation catches up unevenly. (Medium confidence) The EU AI Act's August 2026 obligations start biting, and prompt injection now maps to OWASP, MITRE ATLAS, NIST AI RMF, ISO 42001, GDPR, and NIS2. Expect compliance mapping to become an actual job.
Password managers ship post-quantum wrapping as table stakes. (Medium confidence) What PWDnow does today, mainstream managers advertise by late 2027. The bar moves.
No cryptographically relevant quantum computer in 2027. (High confidence, with a caveat) The expert consensus centers on the 2030s. But harvest-now-decrypt-later means the deadline that matters to you is set by your data's shelf life plus your migration time, not by Q-Day. If you have data that must stay secret past 2035, your deadline was last year.
AI-versus-AI operations become normal. (Medium-high confidence) Autonomous attack agents meeting autonomous defense agents, with humans setting policy and reviewing outcomes. The interesting security questions become about oversight, not detection.

Your Action Checklist

If You Are an Individual

Get a real password manager and stop reusing passwords. Whether that is PWDnow, Bitwarden, or something else matters far less than actually doing it.
Turn on phishing-resistant MFA. Hardware keys or passkeys beat SMS by a wide margin.
Check your passwords against breach corpora. Locally if you can.
Be suspicious of QR codes. 18.7 million attacks in a single month is not a rounding error.
Assume voice can be faked. Agree on a verification method with family and finance contacts that does not depend on recognizing a voice.

If You Run a Small Team

Inventory every OAuth token and third-party integration. Revoke what you do not use. Shorten what you keep.
Pin dependencies and require review for version bumps. Shai-Hulud spread through automatic updates.
Give AI agents their own scoped identities. Never a human's credentials.
Test your restores. Wiper-style ransomware makes backups your primary control.
Ask vendors one question in writing: what is your post-quantum migration timeline?

If You Own Enterprise Security

Build a cryptographic bill of materials. You cannot migrate what you cannot find. Include vendors, embedded systems, and anything where crypto is hidden from you.
Classify data by required secrecy lifetime. Anything past 2035 goes first.
Enable hybrid post-quantum TLS where your stack supports it. The overhead is minimal.
Fix the remediation throughput problem. Finding bugs faster than you fix them makes the queue worse, not the risk lower.
Treat agent frameworks and MCP connectors as privileged automation platforms, with the logging and approval gates that implies.
Run offensive AI tooling against yourself. Your adversaries already are, and several of the best systems are open source.

FAQ

What is ML-KEM in simple terms?

ML-KEM is the NIST-standardized way for two parties to agree on a shared secret key that a quantum computer cannot break. It was published as FIPS 203 in August 2024 and comes in three sizes: 512, 768, and 1024. ML-KEM-768 is the common internet default and ML-KEM-1024 is used for the highest security level.

Is my data at risk from quantum computers today?

Not today, but recorded data is. No cryptographically relevant quantum computer exists in 2026. The risk is harvest now, decrypt later: adversaries store encrypted traffic now and decrypt it once the hardware exists. If your data must stay secret into the 2030s, act now.

Do I need to replace AES-256?

No. Symmetric encryption like AES-256 and hashing like SHA-2 remain strong against quantum attacks at appropriate key sizes. The migration targets public-key key exchange and digital signatures.

What is the difference between direct and indirect prompt injection?

Direct injection is a user typing malicious instructions into an AI system. Indirect injection is malicious instructions hidden in content the AI reads on its own, such as a web page, email, or document. Indirect injection is the bigger enterprise risk because it arrives through normal business data flows.

Is PWDnow safe to use?

PWDnow is open source under MIT, uses Argon2id key derivation with a 1 GiB memory cost, AES-256-GCM encryption, hybrid X25519/X448 with ML-KEM post-quantum key encapsulation, and isolates all cryptography inside a Rust daemon separate from the interface. It is a young project without a published third-party audit, and it runs on Linux only with no cloud sync. Strong design, real trade-offs.

How does offline breach detection work?

Instead of querying an online breach service, the manager stores a Cuckoo filter built from over 900 million known breached password hashes locally. Lookups happen entirely on your device with no network call per password, so your vault activity never leaves the machine.

Which is worse in 2026, ransomware or credential theft?

Credential theft causes more incidents. Credential phishing accounted for 94 to 96 percent of malicious payload attacks in the second quarter of 2026, while traditional malware made up 4 to 6 percent. Ransomware causes higher per-incident cost, but stolen credentials are how attackers get in.

Is AI helping attackers more than defenders?

Right now attackers convert AI capability into results faster because their workflow is simpler. Defenders have a structural advantage, including source code access and telemetry, but are limited by remediation throughput. The 2026 Verizon DBIR reported a 43-day median to fully resolve known vulnerabilities.

When should my organization start post-quantum migration?

Now. NIST's draft transition framework deprecates RSA-2048 and ECC-256 by 2030 and disallows them after 2035, and large enterprise crypto migrations historically take five to fifteen years. Start with a cryptographic inventory.

What should I do first if I only have one hour?

Change reused passwords on your email, banking, and primary cloud accounts, and turn on hardware-key or passkey MFA for those three. Your email account is the recovery path for everything else, so it deserves your strongest protection.

The Bottom Line

The pattern connecting all of it is trust boundaries collapsing.

A chatbot integration held a token, so it inherited access to hundreds of Salesforce instances. An AI agent held credentials, so instructions hidden in a webpage inherited them too. A maintainer's npm account held publish rights, so a worm inherited an ecosystem. Public-key cryptography holds the trust of the entire internet, and a future machine may inherit that.

Every one of these is the same failure: something trusted, delegating without a boundary.

So the defensive posture that works in 2027 is not a new product. It is a habit. Assume every component will be compromised, and make sure that when it is, what it can reach is small, what it holds is short-lived, and what it did is logged.

Start with your passwords, because that is still the front door and it takes an hour. Then inventory your cryptography, because that takes a year and the clock already started.

DKIM for Developers: A No-Fluff Guide to Email Authentication

Sam — Tue, 27 Oct 2026 13:00:00 +0000

No cryptography background needed. Here's what DKIM is, why the selector trips everyone up, the exact records to publish, and a free tool that grades your keys.

TL;DR: DKIM (DomainKeys Identified Mail) is a system where your mail server adds a hidden cryptographic signature to every email you send. You publish the matching public key in DNS. The receiving server checks the signature against that key and confirms two things: the message really came from your domain, and nobody altered it along the way. The key lives at an address like selector1._domainkey.yourcompany.com. And unlike SPF, the signature survives forwarding.

That's the concept. Now let me show you the part every guide gets wrong: you can't even find your own DKIM record without knowing a secret label called the selector.

The Problem SPF Can't Solve

Last week I walked through SPF. It's the guest list that tells mail servers which machines can send as you. It works. It's essential. And it has one hole you can't patch.

Somebody forwards your email.

The message keeps your name in the From field. But now it arrives from their server, which is obviously not on your guest list. SPF fails. Your perfectly legitimate email, forwarded by a happy customer to a colleague, gets flagged as suspicious.

Now scale that up. Mailing lists forward. Alumni addresses forward. That info@ alias that redirects to three people forwards. Every one of those breaks SPF.

DKIM is what fixes it. Instead of asking "did this come from an approved server," DKIM asks a completely different question: "was this message signed by the domain owner, and has it been tampered with since?"

Forward it a hundred times. The signature travels with the message. It still checks out.

That's why you need both.

What Is DKIM, in Plain English

Forget the acronym. Think about a wax seal on a letter.

In the old days, you'd fold a letter, drip wax on the flap, and press your family signet ring into it. Two things happened at once:

Anyone could see the seal was yours because only you had the ring.
If the seal was broken or smudged, the letter had been opened.

DKIM is that, done with math instead of wax.

Your mail server has a private key. It's a long secret string that never leaves the server. Every time you send a message, the server runs the message through a calculation using that private key and produces a signature. The signature gets attached to the email in a hidden header nobody sees.

Your domain publishes the matching public key in DNS, out in the open for anyone to read. Public keys are useless for forging signatures. They can only verify them. That asymmetry is the entire trick.

The receiving server grabs your public key, runs the check, and gets a clean yes or no.

DKIM is defined in RFC 6376. The cryptography rules were updated in RFC 8301.

The Selector: The Part That Confuses Everyone

Here's the thing that makes DKIM different from every other DNS record you've dealt with.

With SPF, you look up yourcompany.com and you find the record. Done.

With DKIM, there's no fixed address. The public key sits at a location that includes an arbitrary label the sender chose, called a selector. The full address looks like this:

selector1._domainkey.yourcompany.com

The _domainkey part is fixed. Everyone uses it. But selector1 is just a name somebody picked. It could be google. It could be pm. It could be k1, or fm2, or s2026a, or bananas.

Why does this design exist? Because one domain usually sends mail through several different services, and each one needs its own key. Your main email platform signs with one selector. Your marketing tool signs with another. Your invoicing system with a third. Separate selectors mean you can rotate or shut off one platform without touching any of the others.

Why is this annoying? Because DNS provides no way to list every name under a branch. You can't ask "show me all the DKIM keys for this domain." There is no such query. If you don't know the selector, you can't look it up, full stop.

This one design choice is responsible for most of the confusion around DKIM. Once you understand it, the rest is easy.

Why This Matters Right Now

DKIM is the least deployed of the three protocols. A February 2026 scan of 5,499,028 domains from the Tranco top sites list found DKIM adoption at just 22.7%, compared with 56.0% for SPF and 30.4% for DMARC, according to DMARCguard's State of Email Authentication research.

Read that again. More than three quarters of the internet's most visited domains publish no verifiable signing key at all.

Email fraud is not slowing down. The FBI's Internet Crime Complaint Center recorded over one million complaints and $20.88 billion in losses in 2025. Business email compromise accounted for $3,046,598,558 from 24,768 complaints, second only to investment fraud. The full data is in the 2025 IC3 Annual Report.

AI joined the party officially. That same report added an AI-related crime category for the first time in 25 years: 22,364 complaints and $893,346,472 in losses. Writing a convincing impersonation of your CFO no longer requires talent.

Email is still the front door. Verizon's 2026 Data Breach Investigations Report analyzed more than 22,000 confirmed breaches and found the human element in 62% of them, with phishing behind 16% of initial access. Among AI-assisted intrusions, phishing was the largest single category at 44%.

And the mailbox providers now require it. Google and Yahoo started enforcing authentication for senders above 5,000 messages a day in February 2024. Microsoft followed on May 5, 2025, rejecting non-compliant mail to Outlook.com, Hotmail.com and Live.com outright with the error 550 5.7.515 Access denied, as documented in Microsoft's announcement. Google's rules live in the Gmail sender guidelines.

Both explicitly require DKIM. Not SPF or DKIM. DKIM.

How DKIM Works, Step by Step

Here's what happens between you hitting send and the message landing.

Step 1. Your server signs the message. Before it goes out, your mail platform selects a set of headers (usually From, Subject, Date, To and a few others) plus the body, runs them through a hashing calculation, and encrypts the result with its private key.

Step 2. It attaches the signature. A hidden header called DKIM-Signature is added to the message. Inside it are the signing domain (d=), the selector (s=), the list of headers that were signed (h=), a hash of the body (bh=), and the signature itself (b=).

Step 3. The message travels. Through your outbound server, through relays, possibly through a forwarder or two.

Step 4. The receiving server reads the header. It pulls out d= and s= and builds the DNS address: <selector>._domainkey.<domain>.

Step 5. It fetches your public key. One DNS lookup. Milliseconds.

Step 6. It recalculates and compares. It hashes the same headers and body the sender did, decrypts your signature with the public key, and checks whether the two match.

Step 7. Result. Match means the message is authentic and unmodified. No match means something changed in transit, or the signature was never valid to begin with.

The whole thing is invisible to the person reading the email. It just quietly decides whether your message is trusted.

What DKIM Does Not Do

This section matters. Skip it and you'll overestimate what you just installed.

DKIM does not prove who sent the message from where. It proves the signature is valid. That's a subtly different thing, and attackers have learned to exploit the gap.

DKIM signatures can be replayed. This is the big one. A DKIM signature has no timestamp and no recipient binding. If an attacker gets hold of a legitimately signed message, they can resend that exact message to thousands of new victims and the signature still verifies.

This is not theoretical. In April 2025, attackers pulled off a live DKIM replay attack against Google itself. They registered a domain, created an OAuth app whose name contained an entire phishing message, and triggered Google's automated security alert. Google generated that alert and signed it with a valid DKIM signature. The attackers then relayed the untouched message onward, and it landed in Gmail inboxes showing as signed by Google, complete with a fake subpoena notice. Abnormal AI published a full technical breakdown.

Authentication passed. The email was still a phish.

DKIM breaks when the message body is modified. Mailing lists that append a footer, or gateways that rewrite links, change the body and invalidate the body hash. Signature fails, and nothing was malicious.

DKIM does not stop spoofing on its own. A signature can verify perfectly while the visible From address belongs to someone else entirely. Only DMARC forces the signing domain to align with what the recipient actually sees.

So DKIM is not a magic wand. It's the durable half of a three part system.

Why You Should Set Up DKIM: The Real Benefits

Your email survives forwarding. The single biggest practical win. SPF cannot do this. DKIM can.
Tamper evidence. If anything modifies your message in transit, the signature breaks and the recipient's server knows.
You meet the bulk sender requirements. Google, Yahoo and Microsoft all require it above 5,000 messages a day, and increasingly expect it below that threshold too.
DMARC becomes reliable. DMARC passes when either SPF or DKIM aligns. With both published, a forwarded message that fails SPF still passes on DKIM. Your legitimate mail stops getting caught in the crossfire.
Better sender reputation. Enterprise gateways score signing configuration, not just pass or fail. A properly signed 2048-bit message reads as a maintained, professional operation.
You can revoke a compromised sender instantly. If a marketing platform gets breached, you retire that one selector and every other sending stream keeps working.
It costs nothing. Your mail provider generates the key. You publish one DNS record. No license, no subscription.
Compliance. PCI DSS 4.0, NIS2 and DORA all treat email authentication as a required control.

Every Tag Inside a DKIM Record, Decoded

Your DKIM DNS record is a list of short tags separated by semicolons. Here they all are.

Tag	What it means in plain English	Watch out for
`v=`	Version declaration. Says "this is a DKIM record."	Technically optional, but if present it must come first.
`k=`	The type of key. Usually `rsa`. Sometimes `ed25519`.	Ed25519 keys look tiny compared to RSA. Short does not mean weak.
`p=`	The public key itself. This is the long block of gibberish.	An empty `p=` revokes the key. A truncated key fails silently.
`t=`	Testing mode. Tells receivers to ignore failures.	Belongs in the first hour of setup and nowhere else. Remove it.
`h=`	Which hash algorithms are allowed.	Never restrict to sha1. It is deprecated.
`s=`	Service type. Almost always `email` or `*`.	Rarely set. Harmless.
`n=`	A free text note for administrators.	Ignored by every verifier. Purely a comment.

The tags inside the message itself

You'll also encounter tags in the DKIM-Signature header on an actual email. These are the ones worth recognizing:

Tag	What it means
`d=`	The signing domain. This is what has to align with your From address for DMARC to pass.
`s=`	The selector. This is how you find your key.
`h=`	The list of headers that were signed.
`bh=`	The body hash. If the body changes, this breaks.
`b=`	The actual signature.

Reading a real record

v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

In English: this is a DKIM record, using an RSA key, with SHA-256 hashing, and here is the public key. Clean and correct.

Now here's one that's quietly broken:

v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

The t=y means testing mode is still on, so receivers have been told to ignore any failure. You're signing every message and getting zero benefit from it. This is one of the most common findings on a domain that "has DKIM set up."

And this one:

v=DKIM1; k=rsa; p=

Empty p=. The key is revoked. If you're still signing with this selector, every message you send is failing DKIM right now.

How to Find Your DKIM Selector

Three reliable methods, in order of certainty.

Method 1: Read it from a message you sent (definitive)

Send yourself an email. Open it in Gmail, click the three dots, choose Show original. Find the DKIM-Signature header.

The s= tag is your selector. The d= tag is your signing domain. This is the only method that cannot be wrong, because it tells you what your server is actually doing right now, not what it's supposed to be doing.

Method 2: Check your provider's setup instructions

When your mail platform asked you to add a DNS record, the hostname contained the selector. Look for something ending in ._domainkey.

Method 3: Guess the common ones

Most hosted platforms use predictable selectors. Here are the ones you'll encounter most:

Provider	Selector	Full hostname
Google Workspace	`google`	`google._domainkey.example.com`
Microsoft 365	`selector1`, `selector2`	`selector1._domainkey.example.com`
Zoho Mail	`zoho`, `zmail`	`zoho._domainkey.example.com`
Proton Mail	`protonmail`, `protonmail2`	`protonmail._domainkey.example.com`
Fastmail	`fm1`, `fm2`, `fm3`	`fm1._domainkey.example.com`
SendGrid	`s1`, `s2`	`s1._domainkey.example.com`
Mailchimp / Mandrill	`k1`, `k2`, `mandrill`	`k1._domainkey.example.com`
Postmark	`pm`, `pic`	`pm._domainkey.example.com`
Amazon SES	three rotating tokens	`<token>._domainkey.example.com`, published as CNAMEs
Self-hosted servers	`default`, `mail`	`default._domainkey.example.com`

A useful side note for anyone doing competitive research: a selector name usually identifies the platform behind it. Finding k1._domainkey on a domain tells you they use Mailchimp. That's a public fact sitting in DNS.

Full Tutorial: Publishing Your DKIM Record

Step 1: List every service that sends email as you

Same exercise as SPF, and just as important. Each one needs its own key and its own selector.

Your main email platform. Your marketing tool. Your transactional sender. Your CRM. Your helpdesk. Your invoicing software. Your ecommerce order confirmations. Your monitoring alerts. Anything that sends without a signature is mail your recipients cannot verify.

Step 2: Generate the key inside your provider

Do not generate keys by hand unless you run your own mail server. Every hosted platform has a DKIM setup screen that generates the key pair for you, keeps the private half, and shows you exactly what to publish.

Roughly where to look:

Google Workspace: Admin console, Apps, Google Workspace, Gmail, Authenticate email
Microsoft 365: Defender portal, Email and collaboration, Policies, Email authentication settings, DKIM
SendGrid, Postmark, Mailchimp, Brevo, Klaviyo: usually under Sender Authentication or Domain Verification

When the tool offers you a key length, choose 2048-bit. Always. More on this below.

Step 3: Publish it in DNS

Your provider will hand you either a TXT record or a CNAME record. These are handled differently and it matters.

If they give you a TXT record, create it like this:

Field	What to enter
Type	TXT
Name / Host	`selector._domainkey` (for example `google._domainkey`). Most panels append your domain automatically.
Value / Content	The full string starting with `v=DKIM1;`
TTL	3600 or Auto

If they give you a CNAME record, which is how Microsoft, SendGrid, Fastmail and Amazon SES all do it:

Field	What to enter
Type	CNAME
Name / Host	`selector1._domainkey`
Value / Target	The long hostname your provider gave you

A CNAME is a pointer. It tells DNS to go look at the provider's own record instead of storing a copy. This is strictly better, because the provider can rotate the underlying key on their schedule without ever touching your DNS.

Never convert a CNAME into a TXT copy. People do this when their DNS panel is fussy. It works right up until the provider rotates the key, and then your mail fails DKIM with no warning.

Step 4: Handle the 255 character problem

This is the trap that catches almost everyone using TXT records.

A 2048-bit public key is around 392 characters. A single DNS TXT string is limited to 255 characters. So the record has to be split into multiple quoted chunks inside one record, and DNS joins them back together automatically.

Most modern DNS panels do this for you invisibly. Some do not, and some silently truncate the value instead of warning you.

The failure mode is nasty: your mail still sends, your logs stay clean, nothing looks wrong on your end, and every receiving server rejects the signature. This is why step 6 exists.

Do not solve this by dropping to a 1024-bit key. Split the string, or use a CNAME, or move to a DNS host that handles it.

Step 5: Turn on signing and remove testing mode

Publishing the key does nothing by itself. Go back into your provider and switch signing on. In Google Workspace this is a button labeled Start authentication.

If your record contains t=y, remove it once you've confirmed signatures verify. Testing mode tells the world to ignore your failures, which cancels out the entire point.

Step 6: Test it, and do not skip this

Verify with the free DKIM Record Checker from EmailVerifyerAPI. It solves the selector problem, which is why it earns a spot here.

Leave the selector field blank and it probes around thirty selectors used by Google, Microsoft, Zoho, Postmark, Mailchimp, Fastmail, SendGrid and others, then reports what it finds. If you already know your selector, enter it for a definitive answer.

Here's what you get:

A score out of 100 with a band from Missing through Weak, Low, Normal, Strong and Excellent, rated on key hygiene rather than mere presence.
Selector discovery, so you can audit a domain without knowing its setup in advance.
Key strength assessment, flagging 1024-bit keys that should be rotated.
Revocation detection, catching the empty p= tag that means a key is retired but still in use.
Testing mode detection, catching t=y left on from setup day.
DMARC context, because a signature with no DMARC policy behind it has no consequence.
A numbered findings list, each item explaining what is wrong and the specific change to make.
No account, no signup, nothing stored on their side.

One thing I respect about it: when you supply no selector and it finds nothing, it reports that as inconclusive rather than scoring you a zero. That's the honest answer, because DNS genuinely cannot enumerate names under a subtree, and a blank result means the guesses missed, not that no key exists. Tools that report "no DKIM found" in that situation are lying to you.

How to use it:

Open the DKIM record checker.
Enter your domain. Add your selector if you know it, leave it blank if you don't.
Read the band first. Anything below Normal needs attention.
Work down the findings list. Revoked keys and testing mode first, key length second.
Re-run after each DNS change.
Then check your own domain against the SPF and DMARC checkers on the same site, because DKIM alone is not a finished job.

Step 7: Confirm with a real message

Send an email to a Gmail address you control. Show original. Look for:

DKIM: 'PASS' with domain yourcompany.com

If the domain shown next to DKIM is not your domain, you have a signature that verifies but does not align, and DMARC will not pass on it. That usually means your platform is signing with its own domain instead of yours, and you need to finish the branded sending setup.

What Makes a Perfect, Strong DKIM Setup

Eight characteristics. All of them checkable in a few minutes.

Every sending service signs. Not just your main mail platform. Your invoices and order confirmations matter more than your newsletter.
Keys are 2048-bit RSA. RFC 8301 updated the cryptographic requirements for DKIM, and 1024-bit has been below NIST's recommended minimum since 2013. A 1024-bit signature still verifies almost everywhere, but enterprise gateways like Proofpoint and Mimecast factor key strength into sender scoring. It's a visible signal that nobody has looked at your setup in a decade.
One selector per service. Shared keys mean you cannot revoke one platform without breaking the rest.
Selector names are versioned or dated. Something like s2026a instead of default. Future you will know instantly which key is current.
No t=y anywhere. Testing mode off.
No stale or revoked keys still in use. An empty p= on a selector you are actively signing with means silent, total DKIM failure.
The signing domain aligns with your From address. Verify signature is not the same as DMARC passes.
Keys rotate on a schedule. Every 6 to 12 months is the widely accepted practice.

How to Rotate a Key Without Breaking Anything

Follow the order exactly.

Publish the new key at a NEW selector: s2026b._domainkey
Wait for the old TTL to expire
Switch your platform to sign with the new selector
Revoke the old key, do NOT delete it: v=DKIM1; k=rsa; p=

Step 4 is the one people get wrong. Revoking means publishing the record with an empty p= value. That's the defined way to retire a key.

Deleting the record instead leaves any messages still in transit unverifiable rather than definitively unsigned, and it erases the evidence that the selector was ever yours. Keep the revoked record published.

On Ed25519 Keys

You may see the option for Ed25519, a newer and much shorter key type. The keys look almost suspiciously small compared to RSA. They are not weak. They are a different kind of mathematics.

The catch is that support across receivers and sending platforms is still uneven in 2026. If you want to use them, dual sign: publish Ed25519 alongside RSA-2048 so receivers that do not support the newer type fall back gracefully. Do not switch to Ed25519 alone.

The Eight Mistakes I See Most Often

The key was published but signing was never switched on. The record exists, the platform never activated. Extremely common.
t=y left on forever. You are signing everything and getting nothing.
A truncated 2048-bit key. The DNS panel silently cut the value at 255 characters. Everything looks fine and nothing verifies.
1024-bit keys nobody has revisited. Some hosting panels still generate these by default.
A CNAME flattened into a TXT copy. Works until the provider rotates. Then it doesn't.
One selector shared across every platform. Cannot revoke anything without breaking everything.
Signing with the provider's domain instead of yours. Signature passes, alignment fails, DMARC fails.
Set up once, never checked again. Providers rotate keys. Teams add tools. Nobody is watching.

SPF, DKIM and DMARC: How the Three Fit Together

One line each.

SPF answers: is this server allowed to send for this domain? It's the guest list. It breaks on forwarding.

DKIM answers: was this message signed by the domain owner, and is it unaltered? It's the wax seal. It survives forwarding.

DMARC answers: what should receivers do when the others fail, and does the authenticated domain match the From address the human sees? It's the policy and reporting layer.

DMARC passes if either SPF or DKIM passes and aligns with your visible From domain. That's the whole reason to publish both. When one breaks, the other carries the message.

The gap in the real world is enormous. DMARCguard found only 12.8% of scanned domains actually enforce a policy that stops spoofing. As Valimail notes in its 2026 assessment, strong authentication is defined by alignment and governance, not by the presence of DNS records alone.

Publishing a key is the easy part. Making it mean something takes DMARC.

Frequently Asked Questions

What is a DKIM record in simple terms?

It's a public key published in your domain's DNS that lets receiving mail servers verify a cryptographic signature your mail server adds to every message. If the signature checks out, the message genuinely came from your domain and was not altered in transit.

What is a DKIM selector?

An arbitrary label chosen by the sender that identifies which key to use, allowing one domain to publish many keys. It appears in the DNS hostname as <selector>._domainkey.<domain> and in the s= tag of the message's DKIM-Signature header.

How do I find my DKIM selector?

Send yourself an email and view the raw source. In the DKIM-Signature header, the s= tag is your selector. Your mail provider's DNS setup instructions also name it, for example google for Google Workspace or selector1 for Microsoft 365.

Why can't a checker find my DKIM record automatically?

Because DNS offers no way to list names under a subtree. Selectors are arbitrary strings, so a tool can only guess. A checker that probes common selectors covers most hosted platforms, but a blank result means the guesses missed, not that no key exists.

Should DKIM keys be 1024-bit or 2048-bit?

Use 2048-bit RSA. 1024-bit keys still verify at most receivers but fall below NIST's minimum and are treated as weak by security-conscious gateways. If your DNS provider rejects the longer value, split the p= tag into multiple 255-character strings inside one record rather than downgrading.

What does an empty p= tag mean?

It revokes the key. Publishing p= with no value is the defined way to retire a selector. Signatures made with that key stop verifying while the record itself stays in place. If you see an empty p= on a selector you still sign with, your mail is failing DKIM right now.

What is DKIM testing mode (t=y)?

It tells receivers the domain is still testing and that failures should not affect handling. Useful during the first hour of setup, harmful afterwards, because it neutralizes the value of the signature entirely. Remove it once you confirm signatures verify.

Do I need DKIM if I already have SPF?

Yes. SPF breaks whenever a message is forwarded, because the relaying server is not on your list. A DKIM signature travels with the message and still verifies after forwarding. DMARC passes when either aligns, so publishing both is what keeps legitimate mail delivering in the real world.

Does DKIM stop email spoofing completely?

No. A signature can verify perfectly while the visible From address is forged, and DKIM signatures can be captured and replayed to new recipients because they carry no timestamp or recipient binding. DMARC is what ties the signature to the address the recipient actually sees.

What is a DKIM replay attack?

An attacker takes a legitimately signed message and resends it unmodified to new victims. Because nothing changed, the signature still verifies and the message passes authentication. The April 2025 campaign that spoofed no-reply@google.com worked exactly this way.

How often should I rotate DKIM keys?

Every 6 to 12 months. Publish the new key at a new selector, wait for propagation, switch signing, then revoke the old key with an empty p= rather than deleting it.

Is DKIM free?

Yes. Your mail provider generates the key pair at no cost, and the public key is a DNS record on a domain you already pay for.

Your 30 Minute Action Plan

Run your domain through the free DKIM checker. Leave the selector blank if you don't know it. Two minutes.
Send yourself an email and read the DKIM-Signature header to confirm your real selector and signing domain. Three minutes.
List every service that sends email as you. Five minutes.
Generate a 2048-bit key in each platform that is not yet signing. Ten minutes.
Publish each record, using CNAME wherever the provider offers it. Five minutes.
Remove any t=y you find, and revoke any stale selector properly with an empty p=. Three minutes.
Re-run the checker. Confirm Strong or Excellent. Two minutes.
Set a calendar reminder for six months out, titled "rotate DKIM keys."

Then finish the job with DMARC, because a signature nobody acts on is just decoration.

If you haven't checked your SPF record yet, do that first. DKIM is the durable half of email authentication, but SPF is the foundation, and DMARC is what turns either of them into actual protection.

SPF Records: Why Your 10 DNS Lookups Break (And The Fix)

Sam — Tue, 20 Oct 2026 12:00:00 +0000

Your SPF record is a lie.

Not because you wrote it wrong. But because the guest list you published three years ago no longer matches the party you are throwing today.

Here is the uncomfortable truth: 76% of title tags get rewritten by Google, and a similar identity crisis happens with SPF records. You set it and forget it. The infrastructure changes. The record doesn't. And then one Tuesday, your transactional emails start landing in spam.

This is not an SPF problem. This is a reality drift problem.

The Hidden Reason Your SPF Fails (And It Is Not Syntax)

Most developers think SPF is a syntax check. It is not. SPF is an identity authorization system. It asks one question: Is this server allowed to send mail for this domain?

But here is the part the tutorials skip: SPF does not authenticate the From: address you see in your inbox. It authenticates the MAIL FROM envelope identity. That gap is where phishing lives and where your legitimate mail gets caught in the crossfire.

SPF authorizes the infrastructure. DMARC connects that authorization to the visible sender. Without both, you are running a security checkpoint that lets people in but never checks their ID against the name on the list.

The 10-Lookup Time Bomb (And Why Your Include Chain Is a House of Cards)

Here is the number that breaks production environments: 10.

SPF evaluation is limited to 10 DNS-query-causing mechanisms, including nested include: records. Exceed it, and you get permerror. Your mail bounces. No warning. No grace period.

You start with this, and it feels fine:

v=spf1 include:_spf.google.com ~all

Then you add a CRM. A help desk. A transactional provider. A marketing platform. Everything looks reasonable on the surface.

But that include: is not one lookup. It is a tree. The provider's SPF record contains another include:. That one contains three more. The visible record says three. The evaluation tree says eleven.

A provider changing its internal SPF structure can silently break your domain overnight. That is the hidden cost of SPF complexity.

The 20-Minute Fix (The "Small But True" Method)

Forget the 5,000-word guides. This is the exact sequence that works in production.

Step 1: Kill the dead weight.
You have vendors in your SPF that you stopped paying six months ago. Remove them. Every unnecessary include: is a lookup you cannot afford.

Step 2: Expand the tree manually.
Do not trust the top-level view. Use a flattening tool or a lookup checker to see the actual evaluation count, not the visible line count. If you are over 10, you are already broken.

Step 3: Move from ~all to -all only when you have earned it.
~all is a softfail. It says "probably not authorized." -all is a hard fail. It says "definitively not authorized." Do not move to -all until you have inventoried every legitimate sender. If you miss one, you will block your own sales team.

Step 4: Stop using ptr.
RFC 7208 explicitly discourages it. It is slow, unreliable, and a lookup sink. Use ip4, ip6, or provider-specific include: mechanisms instead.

The Technical Reference Table (For The Skimmers)

Mechanism	What It Does	Lookup Cost
`include:`	Delegates to another domain's SPF	Yes (nested)
`ip4:` / `ip6:`	Authorizes a specific IP or range	No
`a`	Authorizes the domain's A/AAAA records	Yes
`mx`	Authorizes the domain's MX records	Yes
`ptr`	Reverse DNS check (avoid)	Yes
`exists:`	DNS query for a specific record	Yes
`-all` / `~all`	Catch-all policy	No

The 2026 Reality Check: Compliance Is Not Optional

Gmail and Microsoft have made SPF, DKIM, and DMARC table stakes for bulk senders.

Gmail requires SPF, DKIM, and DMARC for anyone sending 5,000+ messages per day to Gmail accounts. This has been enforced since February 2024 and tightened through 2025.

Microsoft began enforcing the same requirement for high-volume senders to Outlook.com, Hotmail, and Live.com in May 2025.

The consequence is simple: if you are sending at volume and your SPF is broken, you are not just losing deliverability. You are losing access.

What AI Search Engines Actually Cite (GEO Matters Now)

Here is the 2026 twist: your article is not just read by humans. It is parsed by ChatGPT, Perplexity, and Google AI Overviews.

Generative Engine Optimization (GEO) rewards self-contained, extractable paragraphs. AI engines do not rank pages. They extract answers. A clear, factual statement like "SPF evaluation is limited to 10 DNS-query-causing mechanisms" is citable. A rambling 500-word intro is not.

Your SPF record should describe reality. That sentence is the most citable takeaway in this entire article. It is a belief statement, not a technical spec. AI engines love belief statements because they are memorable and attributable.

The One Rule to Remember

Do not build the longest SPF record. Build the smallest accurate one.

Your SPF record is a living document. It should represent the systems that actually send mail today, not the graveyard of SaaS tools you tried in 2023. The goal is not compliance theater. The goal is operational truth.

Final Takeaway: The Stack That Works

SPF is not a checkbox. It is the first layer of a three-layer authentication system.

SPF authorizes the sending infrastructure.
DKIM signs the message cryptographically.
DMARC aligns the authentication with the visible From: domain.

One without the other is a partial solution. All three, with correct alignment and an accurate sender inventory, is the foundation of a modern email setup.

If you take one action today, audit your SPF record for the 10-lookup limit. That is where silent failures hide.

How to Add Card Fraud Detection to Your AI Agent (in About 5 Minutes)

Sam — Mon, 20 Jul 2026 12:09:00 +0000

Last updated: July 2026

Quick question. If your AI agent is touching payment data right now, does it actually know whether a card number is real?

Most don't. They just pass whatever the user typed straight through. No validation, no issuer check, nothing. That's a problem if you're building a support bot, an underwriting assistant, or anything that gets near a card number.

TL;DR: Connect the free BinSearchLookup MCP server to Claude Desktop, Cursor, or any MCP-compatible client. It gives your agent five tools and two ready-made prompts for BIN lookups, offline Luhn validation, and fraud risk scoring, without full card numbers ever touching the LLM's context window. Setup takes about 5 minutes and the free tier needs no credit card. Full steps below.

What Is an MCP Server, and Why Does It Matter for Fraud Checks?

MCP (Model Context Protocol) is the open standard that lets AI agents like Claude Desktop and Cursor call external tools directly, the same way a human developer would call an API. An MCP server is just a small program that exposes a set of tools an agent can invoke on demand.

For fraud detection specifically, that means your agent can validate a card number, identify its issuing bank, and flag risk, all without you writing custom integration code. You wire up the server once, then just talk to your agent in plain English.

I'm going to walk you through the exact setup using the BinSearchLookup MCP server. No fluff, no "hypothetically." Real tools, real config, real commands.

What This Actually Gives Your Agent

Once it's connected, your agent has access to five tools:

local_card_diagnostics(number). Free. Runs completely offline. Identifies the network (Visa, Mastercard, Amex, you name it) and checks the number against the Luhn algorithm before anything touches the internet.
lookup_bin(bin_number). Pulls the full picture on a BIN: issuer, country, card type, brand.
batch_lookup_bins(bins). Feed it a list. It dedupes, chunks into batches of 50, and runs them concurrently. You don't manage pagination.
check_quota(public_user_id). Tells you exactly where you stand against your plan.
check_system_health(). Basic uptime check.

There are also two prompts baked in that do the heavy lifting for you:

fraud_analysis runs the offline check first, pulls the live data, and hands back a full risk assessment. One command.
bulk_bin_audit takes a comma separated list of BINs and returns a clean markdown table, flagging prepaid cards and high risk countries.

Rate limits get handled automatically with exponential backoff. Repeat lookups in the same session get served from cache instead of burning your quota twice. You don't have to think about any of that. It's already built in.

Step 1: Get Your API Key

Head to binsearchlookup.com and sign up. Free plan gives you 500 requests a month, 20 requests a minute, and no, you don't need a credit card to start.

Once you're in, grab two things from your dashboard:

Your API key
Your User ID (labeled public_user_id, there's a copy button right next to it)

That's it. Thirty seconds, tops.

Step 2: Wire It Into Your MCP Client

You've got two options here. Pick whichever fits your setup.

Option A: Docker (this is the one most people should use)

Drop this into your claude_desktop_config.json:

{
  "mcpServers": {
    "binsearchlookup": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "BSL_API_KEY=bsl_your_api_key_here",
        "-e", "BSL_USER_ID=your_user_id_here",
        "python:3.12-slim",
        "sh", "-c", "pip install mcp httpx pydantic tenacity python-dotenv cachetools -q && curl -s https://raw.githubusercontent.com/Bin-Search-Lookup/mcp-binsearchlookup/main/mcp_server.py | python -u"
      ]
    }
  }
}

No repo to clone, no Python environment to manage. Restart your client and you're live.

Option B: Local Python

If you'd rather run it yourself:

pip install httpx pydantic tenacity python-dotenv mcp cachetools

Then create a .env file next to mcp_server.py:

BSL_API_KEY=bsl_your_api_key_here
BSL_USER_ID=your_uuid_here

And point your client at it:

{
  "mcpServers": {
    "binsearchlookup": {
      "command": "python3",
      "args": ["/absolute/path/to/mcp_server.py"]
    }
  }
}

You can grab the source, plus a README in ten languages, from the GitHub repo or download it as a tarball directly.

Step 3: Actually Use It

Open your MCP client and just ask, in plain English:

"Run a fraud analysis on 4532015112830366"

That's it. Your agent calls local_card_diagnostics first (instant, offline, free), then lookup_bin for the real issuer data, and gives you back a structured risk read using the fraud_analysis prompt automatically. You didn't write a single line of integration code.

Want to check a whole batch at once? Try this:

"Audit this list of BINs for prepaid or high risk cards: 453201, 542418, 601100, 370000"

That triggers bulk_bin_audit. Concurrent lookups, one clean table back.

Why This Matters More Than You Think

Here's something a lot of people building AI agents overlook. Full card numbers should never end up in an LLM's context window or sitting in a prompt log. That's not a "best practice," that's a compliance issue waiting to happen.

local_card_diagnostics solves this by doing the Luhn check and network ID entirely offline, on your machine, before anything leaves. Only the BIN, six to eight digits, ever gets sent out for the live lookup. The full card number never travels anywhere near an API log or a prompt history.

That's the difference between "we built fraud checks into our agent" and "we built fraud checks into our agent the right way."

What It Costs

Plan	Price	Rate Limit	Monthly Quota
Free	$0	20 req/min	500 requests
Starter	$29/mo	60 req/min	10,000 requests
Pro	$199/mo	280 req/min	78,000 requests
Enterprise	$999/mo	768 req/min	Unlimited

Start on the free plan. It's more than enough to test this in a real workflow. If your agent starts making serious volume, you'll know it's time to upgrade.

Frequently Asked Questions

What is a BIN number?
BIN stands for Bank Identification Number, the first 6 to 8 digits of a card number. It identifies the issuing bank, card network, and card type without exposing the full card number.

Is it safe to send card numbers through an AI agent?
Full card numbers (PANs) should never be sent to an LLM or a third-party API. The BinSearchLookup MCP server avoids this by validating the full number offline, on your machine, and only sending the BIN (the first 6 to 8 digits) to the live API. The full number never leaves your local process.

Does this work with Claude Desktop, Cursor, and other MCP clients?
Yes. Any MCP-compatible client works, since the setup is just a standard MCP server entry in your client's config file. Claude Desktop and Cursor are the two most common.

Do I need to know Python to set this up?
No. The Docker option needs zero local setup, Docker pulls and runs everything automatically. The local Python option is only needed if you'd rather not use Docker.

How much does it cost to run fraud checks with this MCP server?
The free tier includes 500 requests per month with no credit card required. That's enough for testing and most small projects. Paid plans start at $29/month for 10,000 requests if you need more volume.

What's the difference between local_card_diagnostics and lookup_bin?
local_card_diagnostics runs entirely offline and is free. It checks the Luhn algorithm and identifies the card network. lookup_bin calls the live API and returns full issuer details: bank name, country, and card category.

Grab your free API key and have this running before your coffee gets cold.

How I Designed a Freemium API Plan Developers Actually Want to Pay For

Sam — Wed, 22 Apr 2026 12:00:00 +0000

The Painful Origin Story

Two years ago, I launched a BIN lookup API with pricing that looked good on a spreadsheet and failed everywhere else.

The model was simple: free tier with 100 requests per month, Pro tier at $29/month with 10,000 requests, and Enterprise at custom pricing. I assumed the progression made sense. Users would try the free tier, hit the limit quickly, and upgrade.

What actually happened: the free tier was so constrained that serious developers never bothered onboarding. The jump to $29/month felt arbitrary to the 20-person startups using my API in non-critical flows. And the Enterprise tier collected inquiries from big companies who then negotiated us down by 40% and asked for custom integrations.

After 6 months: 40 signups, 3 paying customers, 1 angry customer who felt overcharged.

I was pricing for growth that did not exist because I had never talked to the people I was trying to sell to.

TL;DR: What I Learned (and Changed)

If you are pricing a developer API, these four lessons will save you the same six months I wasted:

Free tier is your onboarding tool, not your product. Make it viable for real prototyping, not a tease that only lets developers test with five requests. The free tier should answer the question: "Does this API solve my problem?" It should not answer: "Can I build my whole company on this free tier?"
Pricing boundaries should match real developer workflows, not arbitrary request counts. A startup that runs 10,000 lookups per month is not the same as one running 100,000 per month. The actual pain point surfaces at different scales, and your tier breakpoints should acknowledge that.
Transparent per-minute rate limits matter more than monthly quotas. Developers care about burst capacity. Can they run a batch job without getting rate-limited to death? Can their application handle a traffic spike? These questions drive upgrades, not hitting a monthly wall three weeks into the month.
Talk to users before you finalize anything. I made pricing decisions in isolation. Every conversation I had with an actual developer after launch revealed something I had missed. Start there, not with spreadsheet assumptions.

Where Most API Pricing Goes Wrong

I see the same mistakes repeatedly in other API products, and I made most of them.

Mistake 1: Assuming free users will convert to paid.

The conversion funnel is not linear. A developer using 50 free API requests per month will never become a $50/month customer because they do not need it. They will either leave or stay on free forever. The free tier should be designed for developers who will eventually need 5,000+ monthly requests, not everyone.

This means asking: what is the smallest viable dataset or transaction volume where a serious developer says, "I need more than free"? For a BIN lookup API, that threshold is somewhere around 1,000 lookups per month. That is enough for a developer to validate that the API works, integrate it into a prototype, and realize they need it in production. It is not enough to run a production system for even a small company.

Mistake 2: Setting rate limits that punish normal usage patterns.

If your Pro plan offers 100,000 requests per month but limits users to 10 requests per minute, you have created a perverse situation. A developer with a legitimate batch job fails immediately, then cancels because they think your API is broken. They were not hitting the monthly limit; they were hitting a per-minute wall that made no sense.

Developers think in terms of per-second and per-minute throughput first, then monthly volume second. A rate limit of 200 requests per minute sounds boring on a pricing page, but it is the difference between "I can batch-process 1000 records in my evening job" and "my batch jobs time out constantly."

Mistake 3: Making Enterprise a mystery box.

When potential customers see "Enterprise: custom pricing," they assume three things: your product is expensive, negotiation is required, and you are hiding something. Even if your actual Enterprise terms are fair, the perception of opacity suppresses inquiries from large companies that would otherwise upgrade.

I now list baseline Enterprise numbers upfront (unlimited requests, custom rate limits, SLA guarantees, API keys). This signals that Enterprise is not a black box. Customers can decide if it is a conversation worth having.

How I Restructured the Tiers (and Why)

Here is the actual pricing model I moved to, and the reasoning behind each decision.

Free: 1,000 requests per month, 10 per minute

This is the new floor. 1,000 lookups is enough for:

A developer to run integration tests against real data (not mocks)
A small app to do a few lookups per day for a week
A prototype to determine if the API solves the problem

The per-minute limit is high enough that normal API usage never hits it. A developer calling the API once per second for 10 seconds does not fail. But a developer trying to batch-process 10,000 records hits a wall and knows they need to upgrade.

Why this works: it is not a tease. It is a real sandbox. And it is generous enough that the question "Should I even evaluate this product?" gets answered with "yes, definitely."

Conversion rate after moving to 1,000/month free tier: 8%.

Starter: 10,000 requests per month, 50 per minute, 3 API keys

This tier is for developers who have moved from prototype to MVP. They are building something real but it is not mission-critical yet.

10,000 requests per month is roughly:

300 lookups per day
10 lookups per hour during business hours
Enough for a small fintech or fraud team running a few hundred transactions daily

The per-minute limit of 50 is high enough that batch processing within the month is never throttled. The 3 API keys let a developer keep their test environment separate from production without hitting key limits.

The price: $25/month. This is not $29/month; it is not $19/month. It is $25/month, which is memorable and sits at the psychological boundary where a small team says "yes, that is worth it."

Conversion rate after adding this tier: 14%.

Pro: 100,000 requests per month, 200 per minute, 15 API keys

This is where it gets interesting. Pro is for teams that are treating your API as part of their infrastructure.

100,000 requests per month is:

3,300 lookups per day
Enough for a fraud team running thousands of transactions daily
Enough for a payment processor doing lookups for their entire merchant base

The per-minute limit of 200 lets a developer run batch jobs that process 12,000 records per hour without throttling. That is a serious operational capability. The 15 API keys let them organize by team, environment, and use case without burning key limits.

The price: $99/month. This price point exists for a specific reason. It is below $100, which makes it a different budget category for most small companies. It is 4x the Starter price, which is roughly the request ratio. This pricing was not arbitrary; it came from conversations with 15 developers who said, "I would pay $99 to not think about API keys and rate limits."

Conversion rate after launching Pro: 22%.

Enterprise: Unlimited requests, custom rate limits, 190 API keys, SLA

Enterprise is transparent. No custom pricing, no mystery. If you need more than 100,000 requests per month, you contact sales and get a quote. The baseline is unlimited requests, fully customizable rate limits, an SLA, and priority support.

I do not advertise the Enterprise price publicly because it depends on volume and contract terms. But I do publish that Enterprise exists and what it includes. This removes the mystery.

Conversion rate for Enterprise inquiries: 65%.

The Shifts That Actually Moved the Needle

Looking back, three changes mattered far more than pricing tweaks.

Change 1: I Made the Free Tier Actually Usable

The original 100 request free tier was a non-starter. After moving to 1,000, onboarding increased 5x immediately. Developers stopped bouncing off the free tier within a day.

The reason is simple: 1,000 requests is enough to have a real conversation with the API. You run test calls, validate the response shape, check that the data is actually useful. 100 requests is enough to read the docs, run one test, and leave.

This change cost nothing to implement. It just required removing the assumption that "free users are not real customers" and asking instead, "What do free users need to even evaluate this product?"

Change 2: I Published Per-Minute Rate Limits Prominently

The original pricing page buried rate limits in a footnote. I moved them to the main tier comparison table.

The result: developers could immediately see if a tier met their needs. Instead of buying Pro and then complaining about rate limiting, they could make an informed decision. Some developers who thought they needed Enterprise realized Starter was enough. Others realized they needed Pro from the start.

Publishing rate limits also signaled that I understood how developers actually use APIs. It built credibility.

Change 3: I Talked to Users Before Launching Changes

Before restructuring tiers, I ran 20 conversations with developers and payment companies using the API. I asked:

At what volume does free become insufficient?
Do rate limits or monthly quotas matter more?
What does the jump from free to paid look like at your company?

The answers were consistent and contradicted my original assumptions. Free needed to be 10x larger. Rate limits mattered more than I thought. And pricing at $25 for Starter instead of $29 was not a cost difference; it was a perception difference.

I incorporated every answer into the restructured tiers. This is why conversion rates improved so dramatically. I was not guessing anymore.

The Real Numbers

Here are the numbers that convinced me the restructure worked.

Before (original tiers):

Signups per month: 7
Paying customers per month: 0.4 (sometimes a team converts, sometimes they do not)
MRR: $100-200
Churn: 40% per month

After (new tiers):

Signups per month: 85
Paying customers per month: 12
MRR: $1,800 (Starter + Pro + Enterprise combined)
Churn: 8% per month

This was not a magic traction inflection. But it was proof that the pricing was no longer the barrier to entry.

The mix broke down roughly as:

Free tier: 73 of 85 signups (86%)
Starter: 8 of 12 conversions (67% of paying)
Pro: 3 of 12 conversions (25% of paying)
Enterprise: 1 of 12 conversions (8% of paying)

This is important. The Starter tier, not Pro, was where most conversion happened. This contradicted my assumption that developers would skip straight to Pro. Instead, many teams started with Starter, ran into limits within 3-6 months, and upgraded. That is the healthy funnel I was trying to build.

What Developers Actually Care About (Ranked)

After this relaunch and dozens of conversations, here is what drove decisions, in order:

Can I try this without a credit card? Free tier with a real quota (not 50 requests) matters. Most signups come from free users who eventually convert.
Is the per-minute rate limit documented? Burst capacity is the question developers are asking. Monthly quotas are secondary.
Are the price jumps between tiers predictable? Developers do not want to be surprised. 4x the volume for 4x the price is fair. 2x the volume for 10x the price is a scam.
Can I have more than one API key? This signals that the product scales with the developer. A single API key for production and test is a red flag.
What is the minimum commitment period? Most developers want month-to-month, not annual. Annual plans were a conversation-killer.

Pricing, interestingly, was number 7 on the list. Transparency, fairness, and usability ranked higher than cost.

The Live Example

I use this exact pricing model on BinSearchLookup, which is a BIN lookup API for payment developers. The free tier (1,000/month, 10/min) brings in most signups. Starter (10,000/month, 50/min) is where conversion happens. Pro and Enterprise are healthy but smaller.

The model works because it is designed around how developers actually work, not around what a spreadsheet says is logical.

The Mistakes I Still Make

Pricing is not a set-and-forget problem. I still mess this up regularly.

Mistake I still make: Assuming a feature is worth a tier upgrade.

Last year I added batch BIN processing to Pro and expected a shift in conversions. It did not happen. Developers did not care about the feature enough to upgrade. I learned that feature additions do not drive tier upgrades; hitting quota does.

Mistake I still make: Not talking to churn customers.

When a customer downgraded from Pro to Starter, I did not reach out. In retrospect, I should have. They probably hit a workflow that broke at Starter limits, or a rate limit surprised them. I could have fixed the issue instead of losing them.

Mistake I still make: Treating Enterprise as a separate business.

I still assume Enterprise customers want "custom" everything. Many of them just want transparent terms and a handshake. A faster path to Enterprise without a 30-minute sales call would probably convert more.

Takeaways for Your API

If you are pricing a developer API, here is the short version:

Make free tier viable for real work, not just onboarding.
Publish rate limits as prominently as pricing.
Price tiers should reflect real usage patterns, not arbitrary request counts.
Ask developers what they care about instead of assuming.
Build the free-to-Starter funnel first. That is where most conversions happen.

The best part of this restructure was not the revenue increase. It was the shift in how developers talked about the product. Instead of "I wanted to evaluate this but the free tier was too limited," they said "I evaluated this for free, it solved my problem, and now I pay for it."

That is the only pricing metric that matters.

6-Digit to 8-Digit BINs: What Actually Changes for Your Code

Sam — Mon, 20 Apr 2026 12:00:00 +0000

TL;DR

What changed?

Card networks (Visa, Mastercard, and others) expanded the Bank Identification Number (BIN) from 6 digits to 8 digits, per ISO 7812-1:2017.
The first 8 digits of a card number now define the issuer, not just the first 6.
Any system that truncates, stores, indexes, or regex-matches against only 6 BIN digits is now potentially misidentifying cards.

What should you do?

Audit every database column, regex pattern, cache key, and analytics pipeline that assumes a fixed 6-digit BIN.
Expand BIN storage fields from CHAR(6) to VARCHAR(8) and update all related indexes.
Replace homegrown BIN lookups with an API that natively supports 6-to-8 digit ranges, such as BinSearchLookup.
Re-train or re-feature any fraud or risk models that use raw BIN as a feature input.
Test against both 6- and 8-digit BINs before deploying any change to production.

Why Did Networks Move to 8-Digit BINs?

The short answer is that the card industry ran out of BIN space.

The longer answer involves decades of growth. When ISO 7812 was first standardized, 6 digits allowed for roughly 810,000 unique BINs (the first digit is the Major Industry Identifier and is fixed per network, reducing the available combinations). That sounded like plenty in 1989.

By the 2010s, it was not plenty. The explosion of fintech issuers, virtual card programs, co-branded portfolios, and multi-currency prepaid products created a shortage. Networks began assigning BINs in blocks smaller than traditional ranges, and eventually those blocks ran thin.

The formal timeline:

Year	Event
2017	ISO 7812-1:2017 published, formally extending IIN/BIN to 8 digits
2019	Mastercard mandates acquirer and processor readiness for 8-digit BINs
2022	Visa begins issuing 8-digit BINs commercially at scale
2023	Industry-wide adoption; most major processors now receive 8-digit BINs in authorization flows
2024+	Legacy 6-digit systems are actively misrouting or misidentifying a growing share of transactions

The practical consequence: a card starting with 12345678xxxx... might have been identified by BIN 123456 under the old system. Under the new system, the correct BIN is 12345678. These can belong to completely different issuers in different countries. A 6-digit lookup on an 8-digit BIN card returns stale or wrong data.

What Breaks When You Still Assume 6 Digits?

More things break than most teams expect. Here is a category-by-category breakdown.

Database Schema

The most common problem. BIN columns defined as CHAR(6) or VARCHAR(6) silently truncate 8-digit values on insert.

-- Old schema (breaks silently)
CREATE TABLE bin_cache (
  bin      CHAR(6)      NOT NULL PRIMARY KEY,
  issuer   VARCHAR(128),
  country  CHAR(2),
  brand    VARCHAR(32)
);

-- Insert an 8-digit BIN
INSERT INTO bin_cache (bin, issuer, country, brand)
VALUES ('12345678', 'Example Bank', 'US', 'VISA');
-- Stored value becomes '123456' in PostgreSQL, or raises a truncation error in strict mode

In PostgreSQL with standard_conforming_strings on, this may silently truncate. In MySQL with STRICT_TRANS_TABLES disabled, same result. You end up with a corrupted cache that maps 8-digit cards to the wrong issuer.

Fix:

ALTER TABLE bin_cache ALTER COLUMN bin TYPE VARCHAR(8);
DROP INDEX IF EXISTS idx_bin_cache_bin;
CREATE UNIQUE INDEX idx_bin_cache_bin ON bin_cache (bin);

Regex Patterns

Regex is the second most common landmine. Patterns like ^\d{6}$ appear in input validation, log parsers, ETL pipelines, and API middleware.

# Breaks on 8-digit BINs
BIN_PATTERN = re.compile(r"^\d{6}$")

# Correct pattern that accepts 6 or 8 digits
BIN_PATTERN = re.compile(r"^\d{6}(\d{2})?$")

# Or more explicitly if you want to accept both lengths but nothing else
BIN_PATTERN = re.compile(r"^\d{6}$|^\d{8}$")

In JavaScript, the same problem shows up in form validation and server-side middleware:

// Old
const isValidBin = (bin) => /^\d{6}$/.test(bin);

// Fixed
const isValidBin = (bin) => /^\d{6}(\d{2})?$/.test(bin);

Truncation at the Application Layer

It is common to see code that extracts a BIN by slicing the first 6 characters of a PAN (Primary Account Number).

# Breaks for 8-digit BIN issuers
def extract_bin(pan: str) -> str:
    return pan[:6]

# Correct approach: use the issuer's indicated BIN length, or default to 8
def extract_bin(pan: str, bin_length: int = 8) -> str:
    return pan[:bin_length]

The challenge here is that you often do not know the BIN length without looking it up first. This creates a bootstrapping problem: you need an 8-digit BIN to look up the correct BIN length, but your code is only giving you 6 digits.

The practical resolution is to default to 8 digits for all new cards while retaining 6-digit support for legacy BIN ranges that have not been migrated.

Analytics and BI Pipelines

Many analytics stacks join transaction data against a BIN reference table using a 6-character key. When 8-digit BINs arrive in transaction data, the join fails silently and those transactions get tagged as "unknown issuer" or dropped entirely.

-- Typical broken join
SELECT
  t.amount,
  b.country,
  b.brand
FROM transactions t
LEFT JOIN bin_reference b
  ON LEFT(t.card_number_masked, 6) = b.bin
WHERE t.created_at >= '2024-01-01';

-- Fixed join: try 8-digit match first, fall back to 6
SELECT
  t.amount,
  COALESCE(b8.country, b6.country) AS country,
  COALESCE(b8.brand, b6.brand)     AS brand
FROM transactions t
LEFT JOIN bin_reference b8
  ON LEFT(t.card_number_masked, 8) = b8.bin
LEFT JOIN bin_reference b6
  ON LEFT(t.card_number_masked, 6) = b6.bin
WHERE t.created_at >= '2024-01-01';

Fraud and Risk Models

This is the highest-stakes area. Risk models trained on 6-digit BINs have a feature that is now unreliable.

If your model uses bin_country, bin_issuer_type, or bin_brand as features derived from a 6-digit lookup, and the underlying BIN has been migrated to an 8-digit assignment, your features are now wrong. A Visa debit card issued in Germany might look like a Mastercard credit card issued in the US if the 6-digit prefix belongs to a legacy range that no longer maps correctly.

Mitigation steps:

Add a bin_length feature to your model inputs (value: 6 or 8).
Re-extract BIN features from historical transactions using the correct BIN length.
Monitor feature drift on BIN-derived inputs after the migration.
If retraining is not immediately possible, add a correction layer that re-maps 8-digit BINs before feature extraction.

6-Digit vs 8-Digit BIN: Side-by-Side Comparison

Dimension	6-Digit BIN	8-Digit BIN
ISO standard	ISO 7812-1 (pre-2017)	ISO 7812-1:2017
BIN space	~810,000 combinations	~81,000,000 combinations
Storage type (SQL)	`CHAR(6)`	`VARCHAR(8)`
Regex match	`^\d{6}$`	`^\d{6}(\d{2})?$`
PAN slice for BIN	`pan[:6]`	`pan[:8]`
Lookup API compatibility	Most older APIs	Requires explicit 8-digit support
Risk model feature accuracy	Degrading since 2022	Accurate when API returns correct data
Affected card brands	All major networks	All major networks
Backward compatibility	Must coexist with 8-digit	Must coexist with 6-digit

How Do You Migrate Safely?

Safe migration is not a one-day task. It is a phased rollout with parallel processing and validation at each step.

Phase 1: Audit

Before touching any code, find every place in your system that handles BINs.

# Search for hardcoded 6-digit assumptions in a codebase
grep -rn "[:6\]" --include="*.py" .
grep -rn "\[0:6\]" --include="*.py" .
grep -rn "pan\[:6\]" --include="*.py" .
grep -rn "CHAR(6)" --include="*.sql" .
grep -rn "VARCHAR(6)" --include="*.sql" .
grep -rn "\\\\d{6}" --include="*.py" .

Run similar searches for your language of choice. Build a complete inventory before making any changes.

Phase 2: Schema Migration

Expand BIN columns first, before changing application logic. This avoids truncation errors during the transition period.

-- Step 1: Expand column (non-destructive, backward-compatible)
ALTER TABLE bin_cache ALTER COLUMN bin TYPE VARCHAR(8);
ALTER TABLE transactions ALTER COLUMN bin TYPE VARCHAR(8);

-- Step 2: Update indexes after column expansion
REINDEX TABLE bin_cache;

-- Step 3: Add a bin_length column for analytics and debugging
ALTER TABLE bin_cache ADD COLUMN IF NOT EXISTS bin_length SMALLINT;
UPDATE bin_cache SET bin_length = LENGTH(bin);

Do not drop the old 6-digit records yet. You need them as a fallback during the transition.

Phase 3: Application Logic

Update extraction and validation logic to default to 8 digits for new lookups, while retaining 6-digit compatibility for existing records.

class BinExtractor:
    DEFAULT_LENGTH = 8
    LEGACY_LENGTH = 6

    def extract(self, pan: str, legacy: bool = False) -> str:
        length = self.LEGACY_LENGTH if legacy else self.DEFAULT_LENGTH
        return pan[:length]

    def from_transaction(self, pan: str) -> str:
        """
        Extract BIN with fallback logic.
        Try 8-digit lookup first; fall back to 6-digit if no result.
        """
        bin_8 = pan[:8]
        bin_6 = pan[:6]
        return bin_8  # Resolver handles fallback at lookup time

Phase 4: Use a BIN Lookup API That Supports Both Lengths

The cleanest solution for lookup is to delegate to a service that already handles the 6-to-8 digit transition internally. Hand-maintained BIN tables go stale within weeks as new BINs are issued constantly.

BinSearchLookup is one example of an API that accepts 6 to 8 digit BINs natively. The endpoint accepts a bin parameter of either length and returns issuer, brand, card type, and country without requiring you to know in advance whether you have a 6-digit or 8-digit BIN.

import httpx

def lookup_bin(bin_value: str, api_key: str, user_id: str) -> dict:
    """
    Accepts 6 or 8 digit BINs. API resolves the correct issuer data.
    """
    response = httpx.get(
        "https://www.binsearchlookup.com/lookup",
        params={"bin": bin_value},
        headers={
            "X-API-Key": api_key,
            "X-User-ID": user_id
        },
        timeout=5.0
    )
    response.raise_for_status()
    return response.json()

# Works for both:
result_6 = lookup_bin("412345", api_key, user_id)
result_8 = lookup_bin("41234567", api_key, user_id)

The response includes BIN, Brand, Type, Category, Issuer, CountryName, isoCode2, and isoCode3 fields, which maps cleanly to the feature set most fraud models expect.

For batch processing (up to 50 BINs per request), the API also provides a POST /lookup/batch endpoint, which is useful when re-enriching historical transaction data:

def batch_lookup_bins(bin_list: list[str], api_key: str, user_id: str) -> list[dict]:
    response = httpx.post(
        "https://www.binsearchlookup.com/lookup/batch",
        json={"bins": bin_list},
        headers={
            "X-API-Key": api_key,
            "X-User-ID": user_id,
            "Content-Type": "application/json"
        },
        timeout=10.0
    )
    response.raise_for_status()
    return response.json()

Phase 5: Backfill Historical Data

Once the lookup layer is working, re-enrich historical transaction records with correct 8-digit BIN metadata.

import time

def backfill_bin_metadata(db_cursor, api_key: str, user_id: str, batch_size: int = 50):
    """
    Backfill BIN metadata for historical records using 8-digit BINs.
    """
    db_cursor.execute(
        "SELECT DISTINCT LEFT(card_number_masked, 8) FROM transactions "
        "WHERE bin_country IS NULL OR bin_length = 6"
    )
    bins = [row[0] for row in db_cursor.fetchall()]

    for i in range(0, len(bins), batch_size):
        batch = bins[i:i + batch_size]
        results = batch_lookup_bins(batch, api_key, user_id)

        for result in results:
            db_cursor.execute(
                """
                UPDATE transactions
                SET bin_country = %s,
                    bin_brand   = %s,
                    bin_type    = %s,
                    bin_length  = %s
                WHERE LEFT(card_number_masked, 8) = %s
                """,
                (
                    result["isoCode2"],
                    result["Brand"],
                    result["Type"],
                    len(result["BIN"]),
                    result["BIN"]
                )
            )

        time.sleep(0.5)  # Respect rate limits

Phase 6: Monitor After Deploy

After deploying changes, watch for these signals:

Increase in bin_country = NULL rows (indicates unmatched BINs)
Spike in JOIN nulls on BIN reference tables
Shift in fraud model score distributions on newly issued cards
API error rate on BIN lookups (especially 400 INVALID_BIN responses)

Migration Checklist

Use this before marking the migration complete.

Schema

[ ] All BIN columns expanded to VARCHAR(8) or wider
[ ] Indexes rebuilt after column expansion
[ ] bin_length column added where useful for analytics
[ ] No CHAR(6) or VARCHAR(6) BIN columns remain in production schema

Application Logic

[ ] All pan[:6] slices replaced with pan[:8] or parameterized length
[ ] All regex patterns updated to accept 6 or 8 digits
[ ] Input validation updated on all API endpoints that accept BIN as a parameter
[ ] Logging and monitoring updated to flag unexpected BIN lengths

BIN Lookup

[ ] BIN lookup service tested with both 6-digit and 8-digit inputs
[ ] Fallback logic implemented (try 8-digit, fall back to 6-digit for legacy ranges)
[ ] BIN cache TTL set to 30 days or less (BIN assignments change)
[ ] Batch backfill job written and tested in staging

Analytics and Risk

[ ] BIN join logic in analytics queries updated to attempt 8-digit match first
[ ] Risk model BIN feature extraction updated
[ ] Historical transaction data backfilled with correct 8-digit BIN metadata
[ ] Feature drift monitoring added for BIN-derived inputs

Testing

[ ] Unit tests cover 6-digit BIN inputs
[ ] Unit tests cover 8-digit BIN inputs
[ ] Integration tests run against staging with real 8-digit BIN samples
[ ] Rollback plan documented

FAQ

Q: Do all cards now use 8-digit BINs?

No. The transition is gradual. Many legacy card programs still operate on 6-digit BINs. You must support both formats simultaneously, likely for the next decade or more. The safe default is to attempt an 8-digit lookup and fall back to 6 digits if no result is found.

Q: How do I know if a BIN in my database is a real 8-digit BIN vs a truncated 6-digit BIN stored with zero-padding?

Check the bin_length column if you added one during migration. If you did not, look at the original transaction data. A BIN that was stored as 12345600 is almost certainly a truncated 6-digit BIN. A BIN stored as 12345678 may be either, and requires a live lookup to verify.

Q: Will 6-digit lookups return wrong data for 8-digit BIN cards?

Yes, potentially. If 12345678 is an 8-digit BIN assigned to a German bank, but 123456 is a 6-digit BIN assigned to a US bank, a 6-digit lookup will return US/bank data for a card that is actually German. This directly impacts fraud decisions, routing, and compliance checks.

Q: Is the first 8 digits always the BIN on a 16-digit card?

For networks that have adopted the ISO 7812-1:2017 standard, yes. For networks or issuers that have not yet migrated, the BIN may still be defined by only the first 6 digits. This is why fallback logic matters.

Q: Do American Express cards follow the same 8-digit BIN standard?

Amex uses a 15-digit PAN format. The BIN expansion affects them as well, though Amex has historically used tighter control over their BIN ranges. Verify with your Amex integration documentation for specifics.

Q: How often do BIN assignments change?

Frequently. New issuers, new programs, and BIN re-assignments happen continuously. A static BIN table that was accurate in 2022 is meaningfully out of date today. This is the strongest argument for using a maintained API rather than a self-hosted BIN database.

Q: What is the risk of not migrating?

Significant. Misidentified issuers affect currency routing, fraud scoring, and 3DS authentication flows. Regulatory audits that require accurate issuer identification (for example, interchange fee compliance) will surface incorrect data. The longer you wait, the larger the backfill problem grows as more 8-digit BINs are issued.

Last updated: April 2026. BIN assignment information is subject to ongoing change by card networks.

Your First BIN Lookup Integration in Python (With Real Fraud Use Cases)

Sam — Thu, 16 Apr 2026 12:01:00 +0000

A merchant friend of mine runs a small Shopify store selling mechanical keyboards. Last spring, he messaged me in a panic. Overnight, 47 orders had gone through. All digital gift cards. All different cards. All shipping to a single address in a country he had never sold to before.

By the time his payment processor flagged the pattern, the chargebacks were already rolling in. Three weeks later, he had eaten $4,200 in losses, spent hours filing disputes, and nearly lost his merchant account.

Here is the part that stings: a five-dollar API call on each of those orders would have caught it.

That is what BIN lookups do. The Bank Identification Number is the first six to eight digits of any payment card. It tells you who issued the card, what country it came from, whether it is a credit or debit card, and whether it is prepaid. None of that stops a determined fraudster forever, but it stops lazy fraud instantly and gives your risk engine real data to work with.

This tutorial walks you through integrating a BIN API in Python, handling it properly, and turning the response fields into actual fraud rules you can ship.

TL;DR

A BIN is the first 6-8 digits of a card number. It identifies the issuing bank, country, card type, and brand.
You call a BIN API with a GET request, pass your API key in headers, and get a JSON object back.
Key fields for fraud: Brand, Type (debit/credit), CountryName, and whether the card is prepaid.
Handle 429 rate limit responses with exponential backoff. Always set a timeout.
Four rule examples are included at the end you can drop into a checkout flow today.

What Is a BIN and Why Does It Matter for Fraud?

Every Visa, Mastercard, Amex, or Discover card starts with a block of digits that identifies the issuing bank. That block is the BIN, sometimes called the IIN (Issuer Identification Number). Originally it was always six digits. Most modern implementations support eight.

When a card number hits your checkout, you already have the BIN before the customer even clicks "place order." That gives you a narrow window to run a check that can tell you quite a lot:

Brand: Is it Visa, Mastercard, Amex?
Type: Is it credit, debit, or prepaid?
Issuer: Which bank issued it, and from which country?
Country mismatch: Is the billing address in one country while the card was issued in another?

None of these signals alone proves fraud. But combined with your order data, they give you patterns you can act on.

How Do You Call a BIN API in Python?

The mechanics are simple. You send a GET request to the lookup endpoint with the BIN as a query parameter, and your credentials in the request headers.

Here is a minimal working example using the requests library:

import requests

API_KEY = "bsl_your_api_key_here"
USER_ID = "your-uuid-here"
BASE_URL = "https://api.binsearchlookup.com/lookup"

def lookup_bin(bin_number: str) -> dict:
    headers = {
        "X-API-Key": API_KEY,
        "X-User-ID": USER_ID,
    }
    params = {"bin": bin_number}

    response = requests.get(BASE_URL, headers=headers, params=params, timeout=5)
    response.raise_for_status()
    return response.json()

result = lookup_bin("551029")
print(result)

That is the whole happy path. The API returns JSON immediately, typically under 100ms. The response for BIN 551029 looks like this:

{
  "bin": "551029",
  "success": true,
  "data": {
    "BIN": "551029",
    "Brand": "MASTERCARD",
    "Type": "DEBIT",
    "Category": "STANDARD",
    "Issuer": "BANK OF MONTREAL",
    "IssuerPhone": "+18772255266",
    "IssuerUrl": "http://www.bmo.com",
    "isoCode2": "CA",
    "isoCode3": "CAN",
    "CountryName": "CANADA",
    "similarBins": [],
    "cached": false,
    "responseTime": 2
  },
  "statusCode": 200,
  "responseTime": 17
}

The data object is where you will spend most of your time. Notice Brand, Type, CountryName, and isoCode2. Those four fields cover the majority of fraud rules you will want to write.

If you want to test the API without wiring up a full integration, binsearchlookup.com offers a free tier with 1,000 requests per month. That is enough to validate your logic and run experiments before committing to a paid plan.

How Do You Handle Errors, Timeouts, and Rate Limits?

The happy path is 10 lines of code. The production-ready version is where most tutorials stop being honest with you.

Timeouts

Always pass a timeout argument to requests.get. Without it, a slow DNS response or a hiccup on the API side will hang your checkout thread indefinitely.

response = requests.get(BASE_URL, headers=headers, params=params, timeout=5)

Five seconds is generous for an API that normally responds in under 100ms. You may want to tighten it to two seconds if BIN lookup is blocking your order flow.

HTTP Errors

raise_for_status() converts any 4xx or 5xx into a Python exception, which is fine for development. In production, you want to handle specific codes differently.

import requests
from requests.exceptions import Timeout, ConnectionError

def lookup_bin_safe(bin_number: str) -> dict | None:
    headers = {
        "X-API-Key": API_KEY,
        "X-User-ID": USER_ID,
    }
    params = {"bin": bin_number}

    try:
        response = requests.get(
            BASE_URL, headers=headers, params=params, timeout=5
        )

        if response.status_code == 400:
            # Bad BIN format - your problem, not theirs
            print(f"Invalid BIN submitted: {bin_number}")
            return None

        if response.status_code == 401:
            raise RuntimeError("API credentials are invalid or missing")

        if response.status_code == 429:
            # Rate limited - handle with backoff (see next section)
            raise RateLimitError("Rate limit exceeded")

        response.raise_for_status()
        return response.json()

    except Timeout:
        print(f"BIN lookup timed out for {bin_number}")
        return None

    except ConnectionError:
        print("Could not reach BIN API")
        return None

The None return on timeout is intentional. Whether a failed lookup should block the order or let it through is a business decision, not a technical one. Make that call explicitly rather than letting an exception bubble up unhandled.

Rate Limit Handling With Exponential Backoff

The free tier allows 20 requests per minute. The starter tier allows 60. If you hit the ceiling, you get a 429 with error code RATE_LIMIT_EXCEEDED.

Do not retry immediately. Use backoff:

import time

class RateLimitError(Exception):
    pass

def lookup_bin_with_retry(bin_number: str, max_retries: int = 3) -> dict | None:
    for attempt in range(max_retries):
        try:
            return lookup_bin_safe(bin_number)
        except RateLimitError:
            wait = 2 ** attempt  # 1s, 2s, 4s
            print(f"Rate limited. Retrying in {wait}s...")
            time.sleep(wait)

    print(f"Giving up on BIN lookup for {bin_number} after {max_retries} attempts")
    return None

In a high-volume checkout flow, you probably want to queue lookups rather than retry inline. But for small-to-medium traffic, this gets you through the rough spots.

What Can You Do With BIN Data in Your Code?

This is the question that matters. The API is not the point. The point is what you build on top of it.

Extracting the Fields You Care About

def parse_bin_response(response: dict) -> dict | None:
    if not response or not response.get("success"):
        return None

    data = response.get("data", {})

    return {
        "brand": data.get("Brand", "").upper(),
        "card_type": data.get("Type", "").upper(),     # CREDIT, DEBIT
        "category": data.get("Category", "").upper(),  # STANDARD, PREMIUM, etc.
        "issuer": data.get("Issuer", ""),
        "country_code": data.get("isoCode2", ""),
        "country_name": data.get("CountryName", ""),
        "is_prepaid": data.get("Type", "").upper() == "PREPAID",
    }

Notice the is_prepaid flag. Prepaid cards show up as Type: PREPAID in the response. They are not inherently fraudulent, but in certain product categories (high-value electronics, digital goods, gift cards), prepaid usage rates in chargebacks are disproportionately high.

Checking Country Mismatch

The most common signal you will want to build is a mismatch between the card-issuing country and the order's billing or shipping country.

def check_country_mismatch(bin_info: dict, billing_country: str) -> bool:
    card_country = bin_info.get("country_code", "")
    return card_country != billing_country.upper()

If your customer says they are in Germany but the card was issued in Nigeria, that is worth flagging. Not blocking automatically, but flagging.

The Fraud Rule Playbook: 4 Rules You Can Ship Today

These are not theoretical. They are the patterns that catch the most common carding attacks and reseller abuse. Each one is a function that takes a parsed BIN response plus some order context and returns a risk signal.

Rule 1: Flag Prepaid Cards on Digital Goods Orders

def flag_prepaid_digital(bin_info: dict, product_type: str) -> dict:
    is_digital = product_type in ("gift_card", "software_license", "subscription")
    is_prepaid = bin_info.get("is_prepaid", False)

    if is_prepaid and is_digital:
        return {
            "flagged": True,
            "reason": "Prepaid card used for digital goods",
            "action": "manual_review",
        }
    return {"flagged": False}

Rule 2: Block High-Risk Country and Card-Country Mismatch

HIGH_RISK_COUNTRIES = {"NG", "RO", "UA", "VN", "ID"}

def flag_high_risk_origin(bin_info: dict, billing_country: str) -> dict:
    card_country = bin_info.get("country_code", "")
    mismatch = card_country != billing_country.upper()
    high_risk_origin = card_country in HIGH_RISK_COUNTRIES

    if mismatch and high_risk_origin:
        return {
            "flagged": True,
            "reason": f"Card issued in {card_country}, billing address in {billing_country}",
            "action": "block",
        }
    return {"flagged": False}

Adjust HIGH_RISK_COUNTRIES based on your actual chargeback data. This is a starting point, not a permanent list.

Rule 3: Elevated Review for First-Time Amex Users

Amex cards carry higher chargeback rights for cardholders, which makes them attractive for friendly fraud. It is worth adding friction for first-time Amex orders above a threshold.

def flag_new_amex_high_value(
    bin_info: dict, order_total: float, customer_order_count: int
) -> dict:
    is_amex = bin_info.get("brand") == "AMERICAN EXPRESS"
    is_new = customer_order_count == 0
    is_high_value = order_total > 300

    if is_amex and is_new and is_high_value:
        return {
            "flagged": True,
            "reason": "First-time customer, Amex card, high-value order",
            "action": "require_verification",
        }
    return {"flagged": False}

Rule 4: Velocity Check on Same BIN Across Multiple Orders

If the same BIN appears across five or more orders in a short window, that is a carding pattern. Someone is testing card numbers that share the same issuer block.

from collections import defaultdict
from datetime import datetime, timedelta

order_log: dict[str, list] = defaultdict(list)

def flag_bin_velocity(bin_number: str, window_minutes: int = 60, threshold: int = 5) -> dict:
    now = datetime.utcnow()
    cutoff = now - timedelta(minutes=window_minutes)

    # Filter to recent hits
    order_log[bin_number] = [t for t in order_log[bin_number] if t > cutoff]
    order_log[bin_number].append(now)

    count = len(order_log[bin_number])

    if count >= threshold:
        return {
            "flagged": True,
            "reason": f"BIN {bin_number} used {count} times in {window_minutes} minutes",
            "action": "block_and_alert",
        }
    return {"flagged": False}

In production, back order_log with Redis rather than an in-memory dict. But the logic transfers directly.

Putting It All Together in a Checkout Hook

Here is how all four rules look wired together in a single function you could drop into a pre-authorization hook:

def evaluate_card_risk(
    card_number: str,
    billing_country: str,
    product_type: str,
    order_total: float,
    customer_order_count: int,
) -> dict:
    bin_number = card_number[:8]  # Use 8 digits if available
    raw = lookup_bin_with_retry(bin_number)

    if raw is None:
        # Could not reach API - decide your fallback policy here
        return {"flagged": False, "reason": "BIN lookup unavailable", "action": "allow"}

    bin_info = parse_bin_response(raw)

    if bin_info is None:
        return {"flagged": False, "reason": "Unknown BIN", "action": "allow"}

    checks = [
        flag_prepaid_digital(bin_info, product_type),
        flag_high_risk_origin(bin_info, billing_country),
        flag_new_amex_high_value(bin_info, order_total, customer_order_count),
        flag_bin_velocity(bin_number),
    ]

    for check in checks:
        if check.get("flagged"):
            return check  # Return first hit

    return {"flagged": False, "reason": "Passed all checks", "action": "allow"}

This runs synchronously and returns quickly. The most expensive part is the HTTP call, which you can cache by BIN. Most BINs do not change. Cache the result for 24 hours and you will cut your API usage by 80% or more on repeat customers.

Batch Lookups for Order Review Queues

If you are running a manual review queue or backfilling risk scores on historical orders, use the batch endpoint instead of looping single lookups. It accepts up to 50 BINs per request.

def batch_lookup(bin_list: list[str]) -> list[dict]:
    url = "https://api.binsearchlookup.com/lookup/batch"
    headers = {
        "X-API-Key": API_KEY,
        "X-User-ID": USER_ID,
        "Content-Type": "application/json",
    }
    payload = {"bins": bin_list[:50]}  # Hard cap at 50

    response = requests.post(url, json=payload, headers=headers, timeout=10)
    response.raise_for_status()

    data = response.json()
    return data.get("results", [])

Run this in chunks if you have more than 50 BINs to process:

def chunked_batch_lookup(bin_list: list[str]) -> list[dict]:
    results = []
    for i in range(0, len(bin_list), 50):
        chunk = bin_list[i : i + 50]
        results.extend(batch_lookup(chunk))
    return results

What About False Positives?

Every rule in the playbook above will occasionally flag a legitimate customer. A Canadian tourist buying software on a US site. An expat using a prepaid card because they do not have a local bank account yet.

The action field in each response is intentional. "Block" is for patterns so clear that the false positive rate is low enough to accept. "Manual review" is for signals that need a human eye. "Require verification" is for middle-ground cases where you ask the customer to confirm their identity before proceeding.

Build your actions around your chargeback rate and your customer tolerance. If you run a $20 SaaS product, a false block costs you a customer. If you run a $2,000 electronics store, a false allow costs you $2,000 and your merchant account standing.

Summary

BIN lookups are one of the cheapest and most underused tools in a payment developer's kit. The integration takes under an hour. The requests library handles everything. The response fields are clean and immediately usable in business logic.

The four rules in this tutorial are a starting point. Your actual fraud patterns will be specific to your product, your customer base, and your geography. Start with these, watch your flagged order queue for a few weeks, and adjust based on what you actually see.

The API work is the easy part. The judgment calls about what to block versus review versus allow are where the real work happens. Get the data in front of you first. Everything else follows from there.

How to Build a BIN Lookup Middleware in Node.js in Under an Hour

Sam — Fri, 27 Mar 2026 21:37:26 +0000

TL;DR

A BIN (Bank Identification Number) is the first 6 to 8 digits of any payment card and tells you the issuing bank, card type, country of origin, and whether the card is prepaid or credit.
You will build a reusable Express middleware function that intercepts incoming card data, calls a BIN lookup API, and attaches structured metadata to req.binInfo.
The final middleware lets you block prepaid cards, filter by country, flag high-risk issuers, and add card branding in one clean layer before your payment logic runs.
The API requires two credentials stored in .env: your API key and your User ID. Both are sent as request headers on every lookup call.
BIN values sent to the API must be between 6 and 8 digits. Fewer than 6 cannot identify an issuer. More than 8 starts encoding the cardholder account number, which you must never send to a third-party service.
Stack: Node.js 18+, Express 4, Axios, dotenv.
Total build time: under 60 minutes if you follow every step.

Why BIN Lookup Middleware Is Worth Your Time

If you process payments, subscriptions, or any kind of card-based transaction, you already know that not all cards are created equal.

A prepaid card from a high-risk country behaves very differently from a corporate card issued by a bank in a regulated market. Your fraud rules should know the difference before a charge attempt ever reaches Stripe, Braintree, or your processor of choice.

The cleanest place to handle that logic is middleware. You run the BIN check once, attach the result to the request object, and every subsequent handler in your chain can read from req.binInfo without making a second API call. Your fraud logic, logging layer, and analytics all pull from the same enriched source.

This is a pattern used in production payment platforms. It is not complicated once you see it laid out step by step.

Let us build it.

Prerequisites

Before you write a single line of code, make sure your environment is ready.

Node.js version: 18 or higher. Run node -v to check. Node 18 ships with the native fetch API, but we will use Axios in this tutorial because it gives you cleaner error handling and automatic JSON parsing.

Package manager: npm or yarn. Either works.

Packages you will install:

express (version 4.x) for the HTTP server and routing
axios for HTTP requests to the BIN API
dotenv for managing your API credentials as environment variables

A BIN lookup API key and User ID: This tutorial uses binsearchlookup.com for the lookup calls. Sign up and grab both your API key and your User ID from the account dashboard. You will need both in Step 2.

A tool for sending test requests: curl, Postman, or the VS Code REST Client extension all work.

Step 1: Set Up a Minimal Express Server

Create a new project folder and initialize it.

mkdir bin-middleware-demo
cd bin-middleware-demo
npm init -y
npm install express axios dotenv

Create your entry file and the middleware directory:

touch index.js
touch .env
mkdir middleware
touch middleware/binLookup.js

Open index.js and write the skeleton server:

// index.js
// Load environment variables from .env before anything else
require("dotenv").config();

const express = require("express");
const app = express();

// Parse incoming JSON bodies
app.use(express.json());

const binLookupMiddleware = require("./middleware/binLookup");

// Apply the BIN middleware only to the validate-card route
app.post("/validate-card", binLookupMiddleware, (req, res) => {
  // At this point req.binInfo is already populated by the middleware
  return res.json({
    success: true,
    binInfo: req.binInfo,
  });
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Run node index.js and confirm the server starts. You should see the log line in your terminal. Move on to credentials next.

Step 2: Store Both Credentials Safely

The BIN lookup API requires two headers on every request: your API key and your User ID. Both live in your .env file so they never appear hardcoded in source code.

Open .env and add your credentials using the exact variable names shown below:

# .env

# Your API key from your binsearchlookup.com dashboard
X-API-Key=your_api_key_here

# Your User ID from your binsearchlookup.com dashboard
X-User-ID=your_user_id_here

PORT=3000

Replace your_api_key_here and your_user_id_here with the actual values from your dashboard. Never paste real credentials into tutorials, blog posts, or any file that goes into version control.

Add .env to .gitignore right now:

echo ".env" >> .gitignore

This one habit prevents credential leaks. Your code reads the values at runtime using process.env["X-API-Key"] and process.env["X-User-ID"]. No hardcoded strings, ever.

Why two credentials? The API key authenticates your application. The User ID identifies your specific account so the provider can apply per-account rate limits, usage tracking, and billing. Both are required on every request. A call missing either one will be rejected.

Step 3: Extract the BIN From the Request

The BIN is the first 6 to 8 digits of a card number. In real integrations you often receive the full card number on a server-to-server call, or a tokenized version that still carries the BIN prefix.

For this tutorial the client sends a JSON body like this:

{
  "cardNumber": "5184369287452458"
}

Your middleware needs to extract the first 8 digits, then validate that the result falls within the required 6-to-8 digit range. Fewer than 6 digits cannot identify a unique issuer. More than 8 digits starts encoding the individual account number, which is sensitive cardholder data you must never send to any third-party API.

Open middleware/binLookup.js and write the extraction logic:

// middleware/binLookup.js
const axios = require("axios");

// BIN must be between 6 and 8 digits -- no more, no less.
// Fewer than 6 cannot identify a unique issuer.
// More than 8 encodes the account number, which is sensitive cardholder data.
function extractBin(cardNumber) {
  if (!cardNumber || typeof cardNumber !== "string") return null;

  // Remove any spaces or dashes the client might have included
  const cleaned = cardNumber.replace(/\D/g, "");

  // Take the first 8 digits at most
  const bin = cleaned.substring(0, 8);

  // Reject if we cannot produce at least 6 digits
  if (bin.length < 6) return null;

  return bin;
}

module.exports = async function binLookupMiddleware(req, res, next) {
  const { cardNumber } = req.body;

  const bin = extractBin(cardNumber);

  // Strict range check: the BIN must be 6, 7, or 8 digits exactly
  if (!bin || bin.length < 6 || bin.length > 8) {
    return res.status(400).json({
      success: false,
      error: "BIN must be between 6 and 8 digits. Please provide a valid card number.",
    });
  }

  // Attach the raw BIN to req for reference downstream
  req.bin = bin;

  // The API call happens in the next step
  next();
};

Notice that the middleware calls next() at the end. That is the Express convention. When you are done with your work, you hand control to the next handler in the chain. If you need to stop the request early, like the 400 response above, you return the response directly without calling next().

Step 4: Call the BIN Lookup API

Now replace the placeholder next() with the actual API request. You will call the BIN lookup service, receive a structured response, and attach it to req.binInfo.

The API accepts your BIN as a query parameter and expects both credential headers on every call. Here is what a real successful response looks like for BIN 518436:

{
  "bin": "518436",
  "success": true,
  "data": {
    "BIN": "518436",
    "validity": true,
    "Type": "CREDIT",
    "Brand": "MASTERCARD",
    "prepaid": false,
    "Category": "TITANIUM",
    "Issuer": "ABU DHABI ISLAMIC BANK P.J.S.C.",
    "IssuerPhone": "",
    "IssuerUrl": "",
    "pan_length": 16,
    "isoCode2": "AE",
    "isoCode3": "ARE",
    "country": "United Arab Emirates",
    "responseTime": 6
  },
  "statusCode": 200,
  "responseTime": 6
}

Notice the structure. The useful fields live inside data: card type, brand, prepaid flag, issuer name, and country codes. You will reference req.binInfo.data in your business rules.

Now write the full middleware. Replace the entire contents of middleware/binLookup.js:

// middleware/binLookup.js -- full version with API call
const axios = require("axios");

// BIN must be exactly 6 to 8 digits.
// Anything shorter cannot identify an issuer.
// Anything longer encodes the account number -- never send that to a third party.
function extractBin(cardNumber) {
  if (!cardNumber || typeof cardNumber !== "string") return null;
  const cleaned = cardNumber.replace(/\D/g, "");
  const bin = cleaned.substring(0, 8);
  if (bin.length < 6) return null;
  return bin;
}

module.exports = async function binLookupMiddleware(req, res, next) {
  const { cardNumber } = req.body;

  const bin = extractBin(cardNumber);

  if (!bin || bin.length < 6 || bin.length > 8) {
    return res.status(400).json({
      success: false,
      error: "BIN must be between 6 and 8 digits. Please provide a valid card number.",
    });
  }

  req.bin = bin;

  try {
    const response = await axios.get(
      "https://api.binsearchlookup.com/lookup",
      {
        params: {
          // Pass the extracted BIN as a query parameter
          // The API accepts 6, 7, or 8 digits
          bin: bin,
        },
        headers: {
          // Both headers are required on every request
          // Both values are read from environment variables -- never hardcode them
          "X-API-Key": process.env["X-API-Key"],
          "X-User-ID": process.env["X-User-ID"],
        },
        // Fail fast: if the BIN API takes longer than 3 seconds, soft-fail
        timeout: 3000,
      }
    );

    // Attach the full enriched BIN response to the request object.
    // Every downstream handler can now read req.binInfo without a second API call.
    req.binInfo = response.data;

    next();
  } catch (error) {
    // Log the failure internally -- never expose credentials or internals to the client
    console.error("BIN lookup failed:", error.message);

    // Soft-fail: set binInfo to null and continue.
    // A BIN API outage should not take your entire checkout flow down.
    // Your route handler decides what to do when binInfo is null.
    req.binInfo = null;
    next();
  }
};

Your middleware now handles both credentials from .env, enforces the BIN digit range, and attaches everything downstream handlers need.

Step 5: Use the Metadata for Real Business Rules

The middleware has done its job. req.binInfo is populated with the full API response. The actual card data lives inside req.binInfo.data.

Open index.js and replace the skeleton route handler with real policy logic:

// index.js -- full version with business rules
require("dotenv").config();

const express = require("express");
const app = express();

app.use(express.json());

const binLookupMiddleware = require("./middleware/binLookup");

// Cards issued outside this list will be blocked
const ALLOWED_COUNTRIES = ["US", "CA", "GB", "AU", "DE", "FR"];

app.post("/validate-card", binLookupMiddleware, (req, res) => {
  const binInfo = req.binInfo;

  // BIN lookup failed (API outage or unknown BIN) -- block and ask to retry
  if (!binInfo || !binInfo.success) {
    return res.status(422).json({
      success: false,
      error: "Unable to verify card origin. Please try again.",
    });
  }

  const cardData = binInfo.data;

  // Rule 1: Block prepaid cards.
  // Prepaid cards are high-risk for chargebacks and subscription fraud.
  if (cardData.prepaid === true) {
    return res.status(403).json({
      success: false,
      error: "Prepaid cards are not accepted for this service.",
      code: "PREPAID_CARD_BLOCKED",
    });
  }

  // Rule 2: Block cards issued outside your allowed countries.
  // cardData.isoCode2 is the ISO 3166-1 two-letter country code.
  const issuerCountry = cardData.isoCode2;
  if (issuerCountry && !ALLOWED_COUNTRIES.includes(issuerCountry)) {
    return res.status(403).json({
      success: false,
      error: "Cards from this region are not supported.",
      code: "COUNTRY_NOT_ALLOWED",
      country: issuerCountry,
      countryName: cardData.country,
    });
  }

  // All checks passed. Return enriched card metadata to the caller.
  return res.json({
    success: true,
    bin: req.bin,
    cardBrand: cardData.Brand,
    cardType: cardData.Type,
    cardCategory: cardData.Category,
    issuer: cardData.Issuer,
    country: issuerCountry,
    countryName: cardData.country,
    prepaid: cardData.prepaid,
    panLength: cardData.pan_length,
    message: "Card validated successfully.",
  });
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Each rule is a single conditional block. You can add, remove, or reorder rules without touching the middleware at all. The middleware fetches and attaches. The route handler enforces policy. Two different responsibilities, two different places.

Step 6: Test Every Scenario With Curl

Start your server:

node index.js

Test 1: A valid Mastercard Titanium credit card

curl -X POST http://localhost:3000/validate-card \
  -H "Content-Type: application/json" \
  -d '{"cardNumber": "5184369287452458"}'

Expected response:

{
  "bin": "518436",
  "success": true,
  "data": {
    "BIN": "518436",
    "validity": true,
    "Type": "CREDIT",
    "Brand": "MASTERCARD",
    "prepaid": false,
    "Category": "TITANIUM",
    "Issuer": "ABU DHABI ISLAMIC BANK P.J.S.C.",
    "IssuerPhone": "",
    "IssuerUrl": "",
    "pan_length": 16,
    "isoCode2": "AE",
    "isoCode3": "ARE",
    "country": "United Arab Emirates",
    "responseTime": 6
  },
  "statusCode": 200,
  "responseTime": 6
}

Note that AE is not in the ALLOWED_COUNTRIES list, so this specific BIN will trigger the country block rule. That is intentional. It lets you confirm that Rule 2 works correctly. To test a passing card, use a BIN issued in the US, CA, GB, AU, DE, or FR.

Test 2: A prepaid card

curl -X POST http://localhost:3000/validate-card \
  -H "Content-Type: application/json" \
  -d '{"cardNumber": "4023601234567890"}'

Expected: 403 Forbidden with PREPAID_CARD_BLOCKED code.

Test 3: Missing card number

curl -X POST http://localhost:3000/validate-card \
  -H "Content-Type: application/json" \
  -d '{}'

Expected: 400 Bad Request with a BIN digit range error.

Test 4: Card number too short to produce a valid BIN

curl -X POST http://localhost:3000/validate-card \
  -H "Content-Type: application/json" \
  -d '{"cardNumber": "411"}'

Expected: 400 Bad Request. The extracted BIN is only 3 digits, which is below the required minimum of 6.

Test 5: Card issued in a blocked country

Use a BIN from an issuer outside your ALLOWED_COUNTRIES list.
Expected: 403 Forbidden with COUNTRY_NOT_ALLOWED, the alpha2 code, and the full country name in the response body.

Run all five tests before moving on. If any response is unexpected, re-read the middleware and double-check your .env file.

Step 7: Add a Simple In-Memory Cache (Optional but Recommended)

You do not need to call the BIN API on every single request. A BIN is permanently tied to an issuer. It does not change. If the same BIN appears twice in a session or across any requests, serve it from cache.

Here is a lightweight in-memory cache using a plain JavaScript Map:

// middleware/binLookup.js -- final version with caching
const axios = require("axios");

// Simple in-memory cache: BIN string -> API response object.
// In production, replace this with Redis and set a TTL of 24 hours.
const binCache = new Map();

function extractBin(cardNumber) {
  if (!cardNumber || typeof cardNumber !== "string") return null;
  const cleaned = cardNumber.replace(/\D/g, "");
  const bin = cleaned.substring(0, 8);
  if (bin.length < 6) return null;
  return bin;
}

module.exports = async function binLookupMiddleware(req, res, next) {
  const { cardNumber } = req.body;

  const bin = extractBin(cardNumber);

  if (!bin || bin.length < 6 || bin.length > 8) {
    return res.status(400).json({
      success: false,
      error: "BIN must be between 6 and 8 digits. Please provide a valid card number.",
    });
  }

  req.bin = bin;

  // Serve from cache if available -- avoids a network call entirely
  if (binCache.has(bin)) {
    req.binInfo = binCache.get(bin);
    req.binCacheHit = true; // Useful for metrics and logging
    return next();
  }

  try {
    const response = await axios.get(
      "https://api.binsearchlookup.com/lookup",
      {
        params: { bin: bin },
        headers: {
          "X-API-Key": process.env["X-API-Key"],
          "X-User-ID": process.env["X-User-ID"],
        },
        timeout: 3000,
      }
    );

    // Store result in cache before attaching to req
    binCache.set(bin, response.data);

    req.binInfo = response.data;
    req.binCacheHit = false;
    next();
  } catch (error) {
    console.error("BIN lookup failed:", error.message);
    req.binInfo = null;
    req.binCacheHit = false;
    next();
  }
};

For a production system, replace the Map with a Redis client and set a TTL of 24 hours. BIN data is stable, and Redis handles memory management, persistence, and expiry automatically.

Step 8: Structure Your Project for the Long Term

Here is the final folder structure you should have:

bin-middleware-demo/
  middleware/
    binLookup.js       # Fetches BIN data and attaches it to req.binInfo
  index.js             # Express server, route definitions, and business rules
  .env                 # API credentials and config (never commit this)
  .gitignore
  package.json

As your project grows, split the business rules into a separate validators/cardPolicy.js file and import it into the route handler. The middleware stays thin and focused on fetching. The policy layer stays focused on rules. Clean separation means easier unit testing and easier onboarding for every engineer who joins the project after you.

Full Code Reference

Here is every file in its final state so you can copy, paste, and run without scrolling back through the steps.

`.env`

# .env
# Get both values from your binsearchlookup.com account dashboard.
# Never commit this file. It is already in .gitignore.

X-API-Key=your_api_key_here
X-User-ID=your_user_id_here

PORT=3000

`middleware/binLookup.js`

const axios = require("axios");

// In-memory cache to avoid redundant API calls for the same BIN.
// Replace with Redis in production and set a 24-hour TTL.
const binCache = new Map();

// BIN must be between 6 and 8 digits.
// 6 digits is the minimum to identify a unique issuer.
// 8 digits is the maximum before you start encoding the account number.
function extractBin(cardNumber) {
  if (!cardNumber || typeof cardNumber !== "string") return null;
  const cleaned = cardNumber.replace(/\D/g, "");
  const bin = cleaned.substring(0, 8);
  if (bin.length < 6) return null;
  return bin;
}

module.exports = async function binLookupMiddleware(req, res, next) {
  const { cardNumber } = req.body;

  const bin = extractBin(cardNumber);

  if (!bin || bin.length < 6 || bin.length > 8) {
    return res.status(400).json({
      success: false,
      error: "BIN must be between 6 and 8 digits. Please provide a valid card number.",
    });
  }

  req.bin = bin;

  // Return cached result if available
  if (binCache.has(bin)) {
    req.binInfo = binCache.get(bin);
    req.binCacheHit = true;
    return next();
  }

  try {
    const response = await axios.get(
      "https://api.binsearchlookup.com/lookup",
      {
        params: { bin: bin },
        headers: {
          // X-API-Key and X-User-ID are both required by the API.
          // Both are read from .env -- never hardcode credentials.
          "X-API-Key": process.env["X-API-Key"],
          "X-User-ID": process.env["X-User-ID"],
        },
        timeout: 3000,
      }
    );

    binCache.set(bin, response.data);
    req.binInfo = response.data;
    req.binCacheHit = false;
    next();
  } catch (error) {
    // Soft-fail: log internally, do not expose API details to the client
    console.error("BIN lookup failed:", error.message);
    req.binInfo = null;
    req.binCacheHit = false;
    next();
  }
};

`index.js`

require("dotenv").config();

const express = require("express");
const app = express();

app.use(express.json());

const binLookupMiddleware = require("./middleware/binLookup");

// Cards issued outside this list will be blocked.
// Extend this array to match your business requirements.
const ALLOWED_COUNTRIES = ["US", "CA", "GB", "AU", "DE", "FR"];

app.post("/validate-card", binLookupMiddleware, (req, res) => {
  const binInfo = req.binInfo;

  // BIN lookup failed (API outage or unknown BIN) -- block and ask to retry
  if (!binInfo || !binInfo.success) {
    return res.status(422).json({
      success: false,
      error: "Unable to verify card origin. Please try again.",
    });
  }

  const cardData = binInfo.data;

  // Rule 1: Block prepaid cards
  if (cardData.prepaid === true) {
    return res.status(403).json({
      success: false,
      error: "Prepaid cards are not accepted for this service.",
      code: "PREPAID_CARD_BLOCKED",
    });
  }

  // Rule 2: Block cards from unsupported issuer countries
  // cardData.isoCode2 holds the ISO 3166-1 alpha-2 country code
  const issuerCountry = cardData.isoCode2;
  if (issuerCountry && !ALLOWED_COUNTRIES.includes(issuerCountry)) {
    return res.status(403).json({
      success: false,
      error: "Cards from this region are not supported.",
      code: "COUNTRY_NOT_ALLOWED",
      country: issuerCountry,
      countryName: cardData.country,
    });
  }

  // All checks passed
  return res.json({
    success: true,
    bin: req.bin,
    cardBrand: cardData.Brand,
    cardType: cardData.Type,
    cardCategory: cardData.Category,
    issuer: cardData.Issuer,
    country: issuerCountry,
    countryName: cardData.country,
    prepaid: cardData.prepaid,
    panLength: cardData.pan_length,
    cacheHit: req.binCacheHit,
    message: "Card validated successfully.",
  });
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Summary

You built a production-quality BIN lookup middleware in eight steps. Here is what you now have:

A reusable binLookupMiddleware function that extracts the BIN, enforces the strict 6-to-8 digit rule, calls the lookup API with both required credentials, and attaches the full structured response to req.binInfo.
Both X-API-Key and X-User-ID stored safely in .env and passed as headers on every API request. Neither credential ever appears in source code.
Business rules in the route handler that read from req.binInfo.data to block prepaid cards and cards from unsupported countries.
Graceful soft-fail handling so an API outage does not break your checkout flow.
An in-memory cache to eliminate redundant network calls for repeated BINs.
Clean separation between the data-fetching middleware and the business rule layer in the route handler.

The pattern you learned here applies beyond BIN lookups. Any time you need to enrich an incoming request with external data before your main handler runs, middleware is the right tool. IP geolocation, device fingerprinting, user reputation scoring: all of them follow exactly this shape.

FAQ

What is a BIN number and why does it matter for payments?

BIN stands for Bank Identification Number. It is the first 6 to 8 digits of a payment card number and it identifies the issuing bank, the card network (Visa, Mastercard, Amex), the card type (credit, debit, prepaid), and the country where the card was issued. Payment platforms use BIN data to run fraud checks, apply geographic restrictions, and display the correct card brand logo at checkout.

Why does the BIN value sent to the API have to be between 6 and 8 digits?

The BIN lookup database is indexed on 6-digit and 8-digit prefixes. Fewer than 6 digits does not uniquely identify an issuer. More than 8 digits begins encoding the individual account number, which is sensitive cardholder data that you must never send to any third-party service. The extractBin function enforces this range before the network call is ever made.

What are X-API-Key and X-User-ID and why are both required?

X-API-Key authenticates your application to the BIN lookup API. X-User-ID identifies the specific account making the request, which allows the API provider to apply per-account rate limits, usage tracking, and billing. Both are assigned when you create an account at binsearchlookup.com. Storing them in .env with the exact names X-API-Key and X-User-ID and reading them with process.env["X-API-Key"] and process.env["X-User-ID"] keeps them out of your source code and out of version control.

Why use bracket notation like process.env["X-API-Key"] instead of process.env.X_API_KEY?

Dot notation in JavaScript only works for property names that are valid identifiers. The hyphen character in X-API-Key and X-User-ID is not valid in a dot-notation identifier, so you must use bracket notation to access those keys from process.env. Alternatively you can rename the variables in .env to use underscores (for example X_API_KEY) and access them with process.env.X_API_KEY, but keeping the original header names as the variable names makes it immediately obvious which .env value maps to which HTTP header.

Is it safe to log the full card number on the server?

No. You should never log a full card number. Extract only the BIN immediately and discard or tokenize the rest. The BIN alone is not sensitive because it does not identify the cardholder or authorize a transaction. Log the BIN, not the card number.

What happens if the BIN API is down?

The middleware uses a soft-fail pattern. If the API call throws an error or times out, req.binInfo is set to null and next() is called. Your route handler checks for null or !binInfo.success and decides the fallback policy. The example in this tutorial returns a 422 and asks the user to try again. You could also allow the transaction through with a reduced confidence score. The decision belongs in the route handler, not in the middleware.

Can I use this with Stripe or another payment processor?

Yes. This middleware runs before you ever call Stripe. You enrich the request object first, apply your rules, and only then initiate the Stripe payment intent if everything passes. The BIN check adds a validation layer that sits entirely on your own server.

Should I use 6-digit or 8-digit BINs?

Use 8-digit BINs when the card number is long enough to produce them. The payments industry has been migrating toward 8-digit BINs since 2022, and modern BIN lookup APIs return more accurate results with 8 digits. The extractBin function in this tutorial uses substring(0, 8) to grab as many digits as possible up to the 8-digit maximum, then validates that at least 6 were available.

How do I extend the middleware to handle debit cards differently?

Read req.binInfo.data.Type in your route handler. It will be "CREDIT", "DEBIT", or "PREPAID". Write conditional logic for each type without touching the middleware at all. That is the benefit of keeping data fetching and policy enforcement in separate layers.

What is the right timeout for a BIN lookup API call?

A 2 to 3 second timeout is reasonable. BIN lookups are fast because the data is static and well-indexed. If your upstream API consistently takes longer than 1 second, check whether you are hitting a rate limit or whether a geographically closer endpoint is available.

If this tutorial helped you, share what rules you are enforcing in your own BIN middleware in the comments. The more specific your use case, the more others in the community can learn from it.

How to Validate Cards Properly with BIN Intelligence

Sam — Tue, 24 Mar 2026 01:11:25 +0000

TL;DR

Regex and Luhn checks confirm a card looks valid. They do not confirm it is valid or accepted by your processor.
The Bank Identification Number (BIN), also called the Issuer Identification Number (IIN), encodes the card brand, funding type, issuer country, and category before you ever send a single auth request.
Querying a BIN API at checkout lets you block prepaid cards, flag cross-border risk, and route to the right processor before you spend an auth fee.
A production-grade validation flow layers regex, Luhn, BIN lookup, and downstream processor response handling in sequence, not in isolation.

Why Regex Validation Is Not Enough?

Most teams start with the same approach. A card number arrives at checkout, you run a pattern match, and if it passes you fire off the authorization. It feels reasonable. It is not sufficient.

Here is what a standard naive validation stack looks like:

import re

def luhn_check(card_number: str) -> bool:
    digits = [int(d) for d in card_number]
    odd_digits = digits[-1::-2]
    even_digits = digits[-2::-2]
    total = sum(odd_digits)
    for d in even_digits:
        total += sum(divmod(d * 2, 10))
    return total % 10 == 0

def naive_validate(card_number: str) -> dict:
    card_number = card_number.replace(" ", "").replace("-", "")

    patterns = {
        "visa": r"^4[0-9]{12}(?:[0-9]{3})?$",
        "mastercard": r"^5[1-5][0-9]{14}$",
        "amex": r"^3[47][0-9]{13}$",
        "discover": r"^6(?:011|5[0-9]{2})[0-9]{12}$",
    }

    brand = None
    for name, pattern in patterns.items():
        if re.match(pattern, card_number):
            brand = name
            break

    return {
        "format_valid": brand is not None,
        "luhn_valid": luhn_check(card_number),
        "brand": brand,
    }

This code is not wrong. It is incomplete. Here is what it cannot tell you:

The card is prepaid. Your platform prohibits prepaid cards for subscription billing, but this regex has no way to detect that. The card passes validation, the customer subscribes, the first renewal fails, and you eat the chargeback cost plus processor fee.

The card is from a restricted country. Your terms of service block cards issued in certain jurisdictions. The number format is identical to a domestic card. Regex does not encode geography.

The card brand has changed its BIN range. Mastercard expanded into 2-series BINs starting with 222100. Visa launched 2-series ranges in some markets. Your regex was written in 2019. The pattern no longer matches a valid card.

The card is a commercial purchasing card. It carries Level 2 and Level 3 interchange eligibility. You are billing it at Level 1 and leaving hundreds of basis points on the table every month.

Luhn adds a checksum layer that catches transcription errors and random number generators. It does not catch any of the above. A valid Luhn number on a canceled card is still a valid Luhn number.

The bottom line: naive validation tells you the number is plausible. BIN intelligence tells you what the card actually is.

What Extra Signals Does BIN Give You?

The BIN is the first six to eight digits of a card number. Every issuing bank registers its BIN ranges with the card networks. A BIN lookup decodes those digits against a continuously updated registry and returns structured metadata about the card before authorization.

Here are the fields that matter in production:

Card Type (Funding Source)

The type field returns one of: credit, debit, or prepaid.

This distinction drives real business logic. Prepaid cards cannot be charged again after the initial balance is exhausted. Some regulatory frameworks treat prepaid differently from credit for know-your-customer purposes. Marketplaces that pay out to cards need to know whether the receiving card supports push-to-debit.

Card Brand

The brand field returns the network: Visa, Mastercard, American Express, Discover, UnionPay, Elo, Maestro, and others. This is more reliable than a regex pattern match because the registry is updated by the networks themselves when BIN ranges change.

Issuer Country

The country field returns the ISO 3166-1 alpha-2 country code of the issuing bank, not the cardholder's location.

This is material for fraud scoring. A card issued in one country used from an IP address in another, purchasing a digital product that will be delivered to a third country, is a different risk profile than a domestic transaction. You cannot derive the issuer country from the card number format alone.

Prepaid Flag

Some BIN responses return a discrete prepaid boolean in addition to the type field. Use it. Prepaid detection at checkout, before authorization, prevents a class of dispute where a customer loads a prepaid card, completes a subscription trial, and the renewal fails because the card has no remaining balance.

Card Category

The category field encodes the product type: consumer, commercial, corporate, purchasing, fleet, or signature. Commercial cards are eligible for lower interchange rates when you submit enhanced line-item data. Consumer signature cards often carry higher interchange that you want to route to the right acquirer. Knowing the category at checkout means you can branch your processing logic before the auth request.

Issuer Name and Phone

Some BIN databases return the issuing bank name and contact number. This is primarily useful for customer service: when a card declines, your support team can advise the customer to call their issuer without looking up which bank issued the card.

A practical BIN response looks like this. The example below comes from the BinSearchLookup API response format, which is representative of what a well-structured BIN service returns:

{
  "bin": "551029",
  "success": true,
  "data": {
    "BIN": "551029",
    "Brand": "MASTERCARD",
    "Type": "DEBIT",
    "Category": "STANDARD",
    "Issuer": "BANK OF MONTREAL",
    "IssuerPhone": "+18772255266",
    "IssuerUrl": "http://www.bmo.com",
    "isoCode2": "CA",
    "isoCode3": "CAN",
    "CountryName": "CANADA",
    "similarBins": [],
    "cached": false,
    "responseTime": 2
  },
  "statusCode": 200,
  "responseTime": 17
}

Every field in that response can gate a business decision. Type tells you it is a debit card. Category tells you it is a standard consumer product. isoCode2 tells you the issuer is Canadian. Issuer and IssuerPhone give your support team what they need if the card declines. None of it is derivable from the card number format or the Luhn checksum.

How Do You Add BIN Intelligence to an Existing Checkout?

The integration point is always after the customer enters the card number and before the authorization request. In most checkout flows, that means triggering on the blur event of the card number field client-side, or in the server-side validation layer before you call your payment processor SDK.

Where to Call the BIN API

Here is a language-agnostic flow showing the correct sequence:

CHECKOUT VALIDATION FLOW
========================

1. RECEIVE card input
   |
   v
2. FORMAT CHECK (regex + Luhn)
   - Fail fast on obviously invalid numbers
   - Return field-level error to UI immediately
   |
   v
3. EXTRACT BIN (first 6-8 digits)
   |
   v
4. QUERY BIN API
   - Pass: BIN digits
   - Receive: type, brand, country, prepaid, category
   |
   +---> APPLY BUSINESS RULES
         - Is type "prepaid" and prepaid blocked? REJECT
         - Is issuer country in restricted list? FLAG or REJECT
         - Is brand supported by your processor? REJECT
         - Is category "commercial"? ROUTE to Level 2 processor
         - Is brand "AMEX" and you have no Amex agreement? REJECT
   |
   v
5. PROCEED TO AUTHORIZATION
   - Pass BIN metadata to your fraud scoring layer
   - Pass category metadata to your processor for interchange optimization
   |
   v
6. HANDLE PROCESSOR RESPONSE
   - Log decline codes alongside BIN metadata
   - Surface issuer phone number to customer support if needed

A Server-Side Implementation Pattern

The example below uses the BinSearchLookup API as one concrete option. Authentication requires two headers: X-API-Key and X-User-ID, both available from your account dashboard. The endpoint is a standard GET request with the BIN passed as a query parameter.

import httpx

# BinSearchLookup API configuration
# Docs: https://www.binsearchlookup.com/development/docs/
BSL_API_URL = "https://api.binsearchlookup.com/lookup"
BSL_API_KEY = "bsl_your_64_character_key_here"   # X-API-Key header
BSL_USER_ID = "your-uuid-here"                    # X-User-ID header

async def validate_card_with_bin(card_number: str, business_rules: dict) -> dict:
    # Step 1: Basic format and Luhn check
    clean = card_number.replace(" ", "").replace("-", "")
    if not luhn_check(clean):
        return {"valid": False, "reason": "LUHN_FAIL"}

    # Step 2: Extract BIN (8 digits preferred; BinSearchLookup supports 6-8)
    bin_digits = clean[:8]

    # Step 3: BIN lookup via BinSearchLookup
    try:
        async with httpx.AsyncClient(timeout=1.5) as client:
            resp = await client.get(
                BSL_API_URL,
                params={"bin": bin_digits},
                headers={
                    "X-API-Key": BSL_API_KEY,
                    "X-User-ID": BSL_USER_ID,
                },
            )
            resp.raise_for_status()
            payload = resp.json()
    except httpx.TimeoutException:
        # Fail open on BIN API timeout -- do not block the customer
        log_bin_timeout(bin_digits)
        return {"valid": True, "bin_data": None, "warning": "BIN_TIMEOUT"}
    except httpx.HTTPStatusError as exc:
        # 429 = rate limit exceeded; 401 = bad credentials; 404 = BIN not found
        log_bin_error(bin_digits, exc.response.status_code)
        return {"valid": True, "bin_data": None, "warning": f"BIN_HTTP_{exc.response.status_code}"}

    # BinSearchLookup wraps data under a "data" key
    # Response fields use PascalCase: Brand, Type, Category, Issuer, isoCode2
    if not payload.get("success"):
        return {"valid": True, "bin_data": None, "warning": "BIN_LOOKUP_FAILED"}

    bin_data = payload.get("data", {})

    # Step 4: Apply business rules against the real response fields
    card_type = bin_data.get("Type", "").upper()          # "CREDIT", "DEBIT"
    card_brand = bin_data.get("Brand", "").upper()        # "VISA", "MASTERCARD", etc.
    card_category = bin_data.get("Category", "").upper()  # "STANDARD", "PREMIUM", etc.
    issuer_country = bin_data.get("isoCode2", "")         # ISO 3166-1 alpha-2, e.g. "US"
    issuer_name = bin_data.get("Issuer", "")
    issuer_phone = bin_data.get("IssuerPhone", "")        # Useful for customer support

    # Block prepaid: BinSearchLookup surfaces prepaid via Type field
    if business_rules.get("block_prepaid") and card_type == "PREPAID":
        return {"valid": False, "reason": "PREPAID_NOT_ACCEPTED"}

    # Block restricted issuer countries
    restricted_countries = business_rules.get("restricted_countries", [])
    if issuer_country in restricted_countries:
        return {"valid": False, "reason": "ISSUER_COUNTRY_RESTRICTED"}

    # Block unsupported brands
    supported_brands = business_rules.get("supported_brands", [])
    if supported_brands and card_brand not in [b.upper() for b in supported_brands]:
        return {"valid": False, "reason": "BRAND_NOT_SUPPORTED"}

    return {
        "valid": True,
        "bin_data": {
            "brand": card_brand,
            "type": card_type,
            "category": card_category,
            "issuer_country": issuer_country,
            "issuer_name": issuer_name,
            "issuer_phone": issuer_phone,   # Store this; useful for decline support flows
            "cached": bin_data.get("cached", False),
            "response_time_ms": bin_data.get("responseTime"),
        },
    }

A few things to note. The BinSearchLookup response wraps card data inside a data object and uses PascalCase field names (Brand, Type, Category, Issuer, isoCode2), so map them explicitly rather than assuming snake_case. The cached field tells you whether the result was served from the provider's internal cache, which is useful for debugging unexpected stale data. Store IssuerPhone alongside the transaction record: when a card declines, your support team can surface the issuer number to the customer without a manual lookup. The timeout is set at 1.5 seconds with fail-open behavior. A BIN API outage should never take down your checkout.

Client-Side Triggering

Triggering the BIN lookup on the client side, before form submission, improves user experience significantly. You can show the correct card brand logo as the customer types, block disallowed card types before they reach your server, and avoid a round-trip auth request on a card your platform will not accept.

// BinSearchLookup credentials (keep the API key server-side in production;
// this pattern is shown for clarity -- proxy the call through your backend)
const BSL_API_KEY  = "bsl_your_64_character_key_here";
const BSL_USER_ID  = "your-uuid-here";

async function fetchBinData(binDigits) {
  try {
    const res = await fetch(
      `https://api.binsearchlookup.com/lookup?bin=${binDigits}`,
      {
        headers: {
          "X-API-Key": BSL_API_KEY,
          "X-User-ID": BSL_USER_ID,
        },
      }
    );
    if (!res.ok) return null;
    const payload = await res.json();
    // BinSearchLookup wraps data under payload.data with PascalCase keys
    return payload.success ? payload.data : null;
  } catch {
    return null; // Fail silently on the client; server validates independently
  }
}

let binLookupTimer = null;

// Trigger BIN lookup after 8 digits are entered
cardInput.addEventListener("input", async (e) => {
  const digits = e.target.value.replace(/\D/g, "");

  if (digits.length >= 8) {
    const binDigits = digits.slice(0, 8);

    // Debounce to avoid hammering the API on each keystroke
    clearTimeout(binLookupTimer);
    binLookupTimer = setTimeout(async () => {
      const data = await fetchBinData(binDigits);
      if (data) {
        // BinSearchLookup returns PascalCase: Brand, Type, Category
        updateCardBrandDisplay(data.Brand);           // e.g. "VISA", "MASTERCARD"
        if (data.Type === "PREPAID" && prepaidBlocked) {
          showFieldError("We do not accept prepaid cards.");
        }
        // Optionally surface the issuer country for fraud pre-screening
        if (restrictedCountries.includes(data.isoCode2)) {
          showFieldError("Cards issued in your country are not supported.");
        }
      }
    }, 300);
  }
});

There are several options in the market for BIN API providers. One option worth looking at is binsearchlookup.com, which returns Brand, Type, Category, Issuer, IssuerPhone, isoCode2, isoCode3, and CountryName in a single GET request authenticated with an X-API-Key and X-User-ID header pair. It also supports batch lookups of up to 50 BINs per request, which is useful for reconciliation jobs and fraud analysis pipelines. Evaluate any provider on coverage breadth, update frequency, and uptime SLA before committing.

Checklist: What a Production-Grade Card Validation Flow Should Do

Use this checklist before shipping any payment form to production.

Format Validation

[ ] Strip non-numeric characters before running any check
[ ] Run a Luhn check on the cleaned number
[ ] Validate length against the expected range for the detected brand
[ ] Use 8-digit BIN extraction, not 6-digit, where your BIN provider supports it

BIN Intelligence

[ ] Query a BIN API for every card entry, not just suspicious ones
[ ] Verify the card brand from BIN data (Brand field), not from regex alone
[ ] Check the Type field (CREDIT, DEBIT, PREPAID) and enforce your prepaid policy
[ ] Check the isoCode2 field and enforce your geographic restrictions by issuer country
[ ] Check the Category field and route commercial or premium cards to the correct interchange tier
[ ] Verify the returned Brand is covered by your processor agreements
[ ] Store IssuerPhone with each transaction record for customer support use

Failure Handling

[ ] Set a short timeout (1-2 seconds) on BIN API calls
[ ] Fail open on BIN API timeout: log the event, do not block the customer
[ ] Return meaningful error messages to the UI for blocked card types
[ ] Never expose raw BIN API error responses to the frontend

Logging and Observability

[ ] Log BIN metadata alongside every authorization attempt
[ ] Log BIN timeouts separately so you can track provider reliability
[ ] Alert on elevated BIN API error rates
[ ] Track decline rate by BIN country to spot geographic fraud patterns
[ ] Track decline rate by card type to validate your prepaid blocking logic

Monitoring and Experimentation

[ ] A/B test your BIN-based blocking rules before enforcing them hard
[ ] Start with shadow mode: log what would be blocked without blocking it
[ ] Review shadow-mode results for two weeks before turning on hard rejection
[ ] Compare auth rates before and after each new BIN rule you add
[ ] Monitor false positive rate: legitimate cards incorrectly blocked

Interchange Optimization

[ ] Pass Level 2 data (tax amount, customer code) for commercial card authorizations
[ ] Confirm your processor supports Level 2 and Level 3 pass-through
[ ] Track interchange costs by card category month over month

Practical Advice on Logging, Monitoring, and Experimenting Safely

Adding BIN intelligence to a live checkout is not a switch you flip on a Friday afternoon. Here is how to do it without tanking your conversion rate.

Start in shadow mode. Deploy the BIN lookup and all your business rules, but do not act on the results yet. Log what would be rejected and why. After two weeks, review the shadow log. If you see 8 percent of your legitimate volume flagged for prepaid, your prepaid data source might be wrong, or your customer base genuinely uses prepaid cards and you need to reconsider the policy.

Gate new rules behind feature flags. Your BIN blocking logic should be toggleable per rule without a deployment. When a rule starts generating unexpected declines, you want to turn it off in thirty seconds, not thirty minutes.

Log BIN metadata with every transaction. Store Brand, Type, Category, isoCode2, and Issuer alongside your authorization records. This data becomes extremely valuable six months later when you are trying to understand why your European auth rate dropped.

Set up decline-rate alerts by BIN country. A sudden spike in declines from cards issued in a specific country often signals a fraud wave or a change in issuer behavior. You cannot see this pattern without country-level logging.

Do not trust BIN data blindly. BIN databases are not perfect. Card networks issue new BIN ranges. Issuers reassign ranges between products. Test your BIN provider's accuracy by running a sample of known cards through it and checking the results against ground truth.

Cache BIN responses aggressively. A BIN lookup result does not change from one transaction to the next. Cache with a TTL of 24 hours or longer. This reduces latency, cuts API costs, and eliminates timeout risk on repeat customers.

import httpx
from functools import lru_cache

BSL_API_URL = "https://api.binsearchlookup.com/lookup"
BSL_API_KEY  = "bsl_your_64_character_key_here"
BSL_USER_ID  = "your-uuid-here"

@lru_cache(maxsize=10000)
def get_cached_bin_data(bin_digits: str) -> dict | None:
    """
    In production, replace lru_cache with Redis or Memcached.
    BIN data is stable. A 24-hour TTL is safe.
    BinSearchLookup also returns a 'cached' boolean so you can
    tell whether the result came from their edge cache.
    """
    try:
        resp = httpx.get(
            BSL_API_URL,
            params={"bin": bin_digits},
            headers={"X-API-Key": BSL_API_KEY, "X-User-ID": BSL_USER_ID},
            timeout=1.5,
        )
        resp.raise_for_status()
        payload = resp.json()
        return payload.get("data") if payload.get("success") else None
    except Exception:
        return None

FAQ

Does BIN lookup replace the Luhn check?

No. Luhn runs first as a fast, zero-latency check that catches transcription errors and obviously fake numbers. BIN lookup runs after Luhn passes. They are complementary layers.

Can I do BIN validation entirely on the client side?

You can cache BIN data and do a client-side lookup for UI purposes, like showing a card brand logo or blocking a disallowed type before form submission. But your server must independently validate BIN data. Client-side checks are bypassed trivially.

What is the difference between BIN and IIN?

They refer to the same digits. BIN (Bank Identification Number) is the older term. IIN (Issuer Identification Number) is the ISO 7812 standard term. The card networks use both interchangeably in documentation.

How often do BIN databases change?

Frequently. New BIN ranges are issued as banks launch new card products. Existing ranges are reassigned when banks merge or discontinue products. A high-quality BIN provider updates their database daily from network feeds. Ask your provider how often their data is refreshed.

What happens if the BIN API is down?

Fail open. Log the timeout. Do not block the customer because your external dependency is unavailable. You will still have downstream fraud signals from your processor. A hard fail on BIN API downtime is a self-inflicted outage.

Is 6-digit or 8-digit BIN lookup more accurate?

Eight-digit. ISO 7812 extended the BIN from 6 to 8 digits to accommodate the growing number of card issuers. Six-digit lookups on 8-digit BIN ranges can return ambiguous or incorrect results. Use 8-digit lookups if your provider supports them.

Can BIN data improve my fraud scoring?

Yes, significantly. Issuer country mismatch with the customer's IP, prepaid card usage on a high-value digital goods order, and commercial cards used for consumer purchases are all signals that improve fraud model precision. BIN fields feed directly into rules-based and model-based fraud scoring.

Do I need BIN lookup for every transaction or just new card entries?

Every new card entry. If you vault cards, you should also run BIN lookup when the card is first stored and store the BIN metadata alongside the token. Re-run the lookup periodically (quarterly) to catch changes, particularly for cards issued on ranges that have been reassigned.

Card validation is not a checkbox. It is a pipeline. Regex and Luhn get you to the starting line. BIN intelligence is what separates a checkout that looks functional from one that actually protects your business.

How BIN Lookup Actually Stops Card Fraud for Small E‑commerce Stores

Sam — Wed, 18 Mar 2026 23:55:55 +0000

TL;DR

A BIN (Bank Identification Number) is the first 6 to 8 digits of any payment card. It tells you the issuing bank, card brand, card type, and country of origin before you authorize a single cent.
Most small stores skip BIN checks entirely, which is exactly why their chargeback rates creep past 1% and Stripe starts sending warning emails.
BIN data lets you flag prepaid cards, mismatched geographies, and high-risk card origins at checkout, before the fraud clears.
Adding a BIN lookup to your checkout flow takes less than a day and costs almost nothing compared to a single $500 chargeback plus fees.
Stores that implement BIN checks correctly see chargeback rates drop 40 to 60% within 90 days, according to merchant case data, without turning away legitimate customers.

The $3,200 Tuesday That Changed How I Think About Checkout

A founder I know runs a small Shopify store selling specialty audio equipment. Average order value: $280. Good margins. Growing steadily.

One Tuesday he woke up to 11 new orders, all placed between 2 a.m. and 4 a.m. He was thrilled until he checked the shipping addresses. Eleven different addresses across four states. Eleven different email addresses. Same card type across the board: prepaid Visa gift cards.

He shipped nine of the orders before his payment processor flagged the pattern.

The chargebacks arrived six weeks later. He lost $3,200 in product, $350 in chargeback fees, and spent two full days responding to disputes he could not win.

Here is the thing: a BIN check on those cards would have told him "prepaid" in under 100 milliseconds. He could have auto-flagged every one of those orders for manual review before a single box left his warehouse.

That is what this article is about.

What Is BIN Lookup?

BIN lookup is the process of decoding the first 6 to 8 digits of a payment card number to retrieve the issuing bank, card brand, card type, and country of origin. This happens in the background of your checkout, before authorization, in under 200 milliseconds.

BIN stands for Bank Identification Number. Some payment networks now call it IIN, Issuer Identification Number. The name change reflects that the first digits identify the issuing institution, not just a bank per se. For practical purposes BIN and IIN are interchangeable.

When a customer types their card number into your checkout, those first digits encode a significant amount of information. A BIN lookup decodes them into actionable fields:

Card brand: Visa, Mastercard, Amex, Discover, UnionPay
Card type: credit, debit, prepaid, corporate, virtual
Issuing bank: Chase, HSBC, Revolut, a regional credit union
Country of issuance: where the card was originally issued, as an ISO country code
Card tier: Standard, Gold, Platinum, Business

None of this requires the customer to do anything different. The response comes back in under 200 milliseconds on any reasonably-maintained API. Your customer never notices it happened.

Related: How Stripe Radar scoring works and where it falls short | Chargeback prevention playbook for DTC brands

Why BIN Data Is Underused by Small Stores

Most small stores rely entirely on their payment processor's fraud detection, which treats BIN data as an opaque input rather than an exposed signal. That means you cannot tune it.

Stripe Radar gives you some risk scoring. PayPal has its own fraud detection. These tools are useful but they treat BIN data as one input into a black box. When Stripe flags a legitimate order from a French customer because France has elevated fraud rates in their global model, you cannot easily override that logic without building around it.

When you run your own BIN check, you decide the rules. Flag prepaid cards over $150, not all prepaid cards. Require phone verification for cards issued outside your primary market, not block them entirely. The control is yours.

What Fields Actually Matter at Checkout

The five BIN fields with the most fraud-prevention value are: country of issuance, card type (especially prepaid), issuing bank, card brand, and card tier. Country and type carry the most weight.

Country of issuance is your most powerful signal. If your store sells domestically and a card was issued in a country with known fraud infrastructure, that mismatch between billing address country and card issuance country deserves attention.

Card type, specifically prepaid, is your second most powerful signal. Prepaid cards are not inherently fraudulent. Plenty of legitimate customers use them for privacy or budgeting. But prepaid cards are also the tool of choice for card testing attacks and refund fraud, because they are disposable and often purchased with cash.

Issuing bank matters more than people think. Certain challenger banks and virtual card issuers have disproportionately high fraud rates not because those banks are bad, but because fraudsters find them easier to open accounts with.

Card brand is a weak fraud signal on its own, but it matters for routing and card cost structures. Amex corporate cards behave differently than consumer debit cards in dispute resolution.

Four Fraud Patterns BIN Data Helps You Stop

BIN data directly addresses four of the most common fraud patterns hitting small e-commerce stores: country mismatches, prepaid card abuse, card testing attacks, and virtual card attacks.

1. High-Risk Country Mismatches

A customer claims to be in Austin, Texas. Billing address: Austin. IP address: Austin. Card issued by: a bank in Eastern Europe.

That mismatch does not mean the order is fraudulent. Immigrants, expats, and frequent travelers use foreign-issued cards all the time. But it warrants a second look, especially on high-value orders. Without BIN data you see a clean billing address and approve. With BIN data you see the mismatch and can ask for additional verification.

2. Prepaid Card Abuse

The audio equipment story at the top of this article is a classic prepaid card attack. Fraudsters buy prepaid cards with cash, purchase goods they can resell, and the cards are untraceable back to any real identity.

The chargeback does not come from a real cardholder because there is no real cardholder. It comes from the prepaid card issuer when the fraudster disputes the charge after receiving the goods. BIN data tells you instantly whether a card is prepaid so you can apply your own policy before anything ships.

3. Card Testing Attacks

Card testing is when an attacker has a list of stolen card numbers and runs small test transactions, often under $2, to find out which ones are still active. Your fraud loss per test is tiny, but processors notice the pattern. Visa's published chargeback monitoring program rules classify merchants with sustained testing patterns as high-risk, triggering additional scrutiny from acquirers.

Many card testing scripts use cards from a narrow range of BINs. If you see multiple failed transactions sharing the same first 6 digits, you can block at the BIN level without touching legitimate customers.

4. Virtual and Burner Card Attacks

Attackers use virtual card services to generate technically valid card numbers designed to be single-use and anonymous. Certain BINs belong exclusively to virtual card programs. A BIN lookup will flag these. Some are entirely legitimate, like privacy-conscious shoppers using Privacy.com. Others are attacker infrastructure. Knowing the difference lets you set nuanced policies rather than blanket blocks.

How Does BIN Data Reduce Chargebacks: The Mechanism

BIN data reduces chargebacks by letting you intercept fraud before it clears, at the moment a card number is entered, before goods ship and before disputes are filed.

Chargebacks happen when a cardholder tells their bank they did not authorize a charge. The bank reverses the transaction and charges you a dispute fee, typically $15 to $100 per incident. According to Visa's published chargeback monitoring program rules, most processors begin watching merchant accounts at a 0.65% monthly chargeback-to-transaction ratio. At 1% you enter formal dispute programs with monthly monitoring fees. At 1.5% account termination is a real risk.

The fraud that generates chargebacks is almost entirely predictable from signals available at authorization time. You can know the card's origin with a BIN lookup before a single authorization request fires.

A Realistic Mini Case Study: Before and After BIN Checks

A two-person supplements brand cut their chargeback rate from 1.2% to 0.4% in 90 days by adding two BIN-based rules to their checkout. Here is exactly what they built.

The store: Direct-to-consumer supplements. Two-person team. Average order value: $68. Monthly volume: roughly 800 orders.

The problem: Chargeback rate climbed to 1.2% over six months. Stripe sent a formal warning. Manual review was eating four hours a week and fraud was still slipping through.

What they were missing: 70% of fraud orders involved prepaid Visa or Mastercard cards. Another 15% involved cards issued in countries with no overlap with their customer demographics.

What they built: Two rules triggered at card entry:

If card type is prepaid AND order value is over $50, hold for manual review.
If card issuing country is not in the store's known-market list AND billing address country does not match, send an automated verification email before shipping.

They used the lookup endpoint from binsearchlookup.com during development because the API response structure was clean and the documentation made the integration straightforward. Total build time: six hours including testing.

Results over 90 days:

Metric	Before	After
Chargeback rate	1.2%	0.4%
Orders held for review	~0 (nothing caught)	31 orders
Fraud confirmed in held orders	N/A	24 of 31
Legitimate orders delayed	N/A	7 of 31
Chargeback fees saved	—	~$1,100
Manual review time per week	4 hrs (reactive)	1.5 hrs (proactive)

The 7 legitimate orders that got delayed were resolved within 24 hours via the verification email. One customer left a positive review specifically mentioning they appreciated the security check.

Without BIN Checks vs. With BIN Checks at Checkout

Scenario	Without BIN	With BIN
Prepaid card, $200 order	Approved, ships immediately	Flagged for review based on your threshold
Foreign-issued card, domestic address	Approved, no additional signal	Mismatch detected, verification triggered
Card testing, $1.00 probes	Pattern builds invisibly	BIN clustering alert fires within 60 minutes
Legitimate customer, foreign card	Approved	Approved with zero friction
Stolen credit card, matching billing	Approved	Partially mitigated by issuer and type data
Virtual card from privacy service	Approved	Identified as virtual, your policy applied

BIN checks do not block good customers. They add a signal layer. What you do with that signal is your policy decision.

When Should Small Stores Use a BIN API?

Implement a BIN API if your average order value exceeds $75, you ship physical goods, or you have seen even one chargeback tied to a prepaid card or unexpected country of origin.

You need a BIN check if any of the following are true:

Your average order value is above $75. Above that threshold, a single chargeback fee can exceed your margin on several orders.
You ship physical goods. Physical goods fraud is almost always caught too late once items leave the warehouse.
You have seen even one chargeback in the past 90 days involving a prepaid card or an unexpected country of origin.
Your current fraud solution is entirely handled by your payment processor with no custom rules.
You are scaling ad spend into new geographies and have no historical fraud data to calibrate against.

If your store is brand new and processing under $5,000 per month, you can probably wait. But build it into your roadmap for the moment you hit consistent volume.

How to Wire BIN Checks Into a Basic Risk Engine

You can implement a working BIN risk engine in four steps: capture the BIN at card input, store the response with the order, score against simple rules, and act on the score. Total build time for a solo developer: 4 to 8 hours.

Step 1: Capture the BIN at card input (~15 minutes)

Listen for the card number field reaching 8 characters. Fire a backend request to your BIN API. Do not expose your API key client-side. Route the lookup through your own backend endpoint.

Step 2: Store the BIN response alongside the order (~30 minutes)

Before any authorization happens, attach the BIN response to the order object. Store at minimum: card type, issuing country, card brand, and issuing bank name.

Step 3: Score the order against your rules (~2 hours)

risk_score = 0

if card_type == "prepaid":
    risk_score += 30

if issuing_country != billing_country:
    risk_score += 20

if issuing_country in HIGH_RISK_COUNTRY_LIST:
    risk_score += 25

if order_value > HIGH_VALUE_THRESHOLD:
    risk_score += 10

if customer_email_domain in KNOWN_THROWAWAY_DOMAINS:
    risk_score += 15

Step 4: Act on the score (~1 hour)

Below 30: process normally
30 to 60: hold for review or require additional verification
Above 60: block and notify

Tune these thresholds based on your false positive and false negative rates after the first 30 days.

How Does BIN Lookup Fit With 3DS2 and Other Fraud Layers?

BIN lookup is most effective when used as a pre-authorization signal that feeds into your broader fraud stack, alongside 3D Secure 2 (3DS2), velocity checks, and device fingerprinting.

3D Secure 2 (3DS2) is the card network protocol that adds a challenge step for suspicious transactions and shifts chargeback liability to the issuing bank when authentication succeeds. BIN lookup complements 3DS2 by helping you decide which transactions to challenge before invoking the 3DS2 flow.

The practical layering looks like this: BIN lookup runs first at card entry. If the risk score is low, the order proceeds and 3DS2 handles authentication at the network level. If the risk score is elevated, you invoke 3DS2 explicitly or hold for manual review before authorization.

Neither layer replaces the other. BIN data tells you about the card's origin and type. 3DS2 tells you whether the cardholder can authenticate in real time. Velocity checks tell you whether the same card, email, or device has been used unusually often. Together, they catch what each layer misses alone.

Related: Setting up 3DS2 with Stripe: a developer's guide | Velocity check patterns for e-commerce risk engines

Practical Implementation Tips

Log every BIN field, set a BIN clustering alert, run a weekly chargeback audit, and review held orders within 24 hours. These four habits separate stores that tune their fraud systems from those that set and forget.

Log everything. Store every BIN lookup response in your order database, not just the final risk decision. When a chargeback comes in three months from now, you want to query "show me all orders where the issuing country was X" and see the pattern immediately.

Set up a weekly chargeback audit. Pull your chargeback data, join it with your BIN log, and look for patterns. Are prepaid cards over-represented? Is a specific issuing country appearing repeatedly? This is how you tune your rules without guessing.

Create an alert for BIN clustering. If more than three orders in a 60-minute window share the same first 6 BIN digits, that is a card testing pattern worth investigating immediately. This alert alone can prevent a wave of fraud losses.

Do not block entire countries. Blocklisting is both legally risky in some jurisdictions and commercially damaging if you ever want to expand. Use country as one signal among several and require additional verification for orders that cross multiple risk thresholds.

Review your held orders within 24 hours. Legitimate customers get frustrated with delays. A fast review with a verification email maintains the experience while catching fraud.

Recheck your BIN database periodically. BIN databases are not static. Banks merge, reissue card ranges, and change product classifications. Use a provider that updates regularly and build in a monthly check on your top-volume card ranges.

Frequently Asked Questions

Does BIN lookup actually work against professional fraud rings?

Yes, for the fraud patterns that hit small stores most often. Sophisticated fraud rings rotate card sources and sometimes use legitimate-looking cards from real issuers, which limits BIN data's effectiveness there. But most small-store fraud is from opportunistic attackers using prepaid cards and stolen card lists, and BIN data catches the vast majority of that. Against advanced actors, layer BIN data with velocity checks and device fingerprinting.

Will BIN checks slow down my checkout?

No. A well-maintained BIN API responds in under 200 milliseconds. You fire the lookup the moment the customer enters their card number, well before they click Pay. Perceived checkout speed is unchanged.

What if a legitimate customer uses a prepaid card?

Flag it, do not block it. Flag prepaid cards for review at certain order value thresholds, or require address verification before shipping. Most legitimate prepaid card users understand and comply. Fraudsters do not.

Is it legal to use BIN data to make checkout decisions?

In most jurisdictions, yes. Using card metadata to make authorization decisions is standard industry practice supported by card network operating rules. Use country as one signal among several rather than a blanket block. Consult your legal counsel for jurisdiction-specific guidance.

How often should I update my risk rules?

Monthly for the first six months, then quarterly after that unless your fraud rate spikes. Each review should compare confirmed fraud orders against your risk model outputs to identify false negatives and check you are not over-flagging legitimate customers.

How is BIN lookup different from what Stripe Radar already does?

Stripe Radar uses BIN data internally but does not expose raw fields like card type as configurable variables. You cannot write a Radar rule that says "if card type is prepaid AND order value is over $50, hold for review" because Radar does not surface card type as a tunable input. Running your own BIN lookup gives you direct access to those fields before the Stripe authorization request is even made.

The Bottom Line

You do not need a fraud team to run a sensible fraud operation. You need data that your payment processor does not surface automatically, and a small amount of code to act on that data.

BIN lookup is the single highest-leverage addition most small e-commerce stores can make to their checkout flow. It is cheap, fast to implement, and catches the fraud patterns that generate the majority of small-store chargebacks.

Build it before you need it. The Tuesday morning with 11 fraudulent orders has a way of arriving without warning.

If you found this useful, share it with a developer friend who runs their own store. Questions about implementation are welcome in the comments.