PCI DSS and Email: What Must Never Reach Your Inbox

PCI compliance and email card data collide the moment a customer types their card number into a reply. PCI DSS does not flatly ban card data from email, but it sets hard rules: the card number has to be protected in transit, the security code can never be stored, and any mailbox that receives either is pulled into the standard's scope. This guide is about containment — keeping card data out of your inbox, and cleaning it up fast when it lands there anyway.

It is written for anyone whose support or sales inbox receives payment details: the founder, the office manager, the person triaging a shared mailbox. This is practical guidance on how card data is treated in email, not a compliance opinion — for a formal PCI assessment, talk to your acquiring bank or a Qualified Security Assessor.

What PCI DSS actually says about card data in email#

PCI DSS — the Payment Card Industry Data Security Standard — is the security baseline the major card brands require through your merchant agreement. It applies to every entity that stores, processes, or transmits cardholder data, or that could affect the security of the cardholder data environment. It is a contractual standard enforced by the card brands and your acquiring bank, not in most places a government law — though a few jurisdictions reference it in their own rules.

Two of its rules decide what may travel by email. First, the full card number — the PAN, or Primary Account Number — must be rendered unreadable with strong cryptography whenever it is sent over end-user messaging technologies such as email, chat, SMS, or instant message. A PAN sitting in plain text in a message body does not meet that bar.

Second, and stricter: the security code (the CVV, CVC, or CID), the full magnetic-stripe or chip track data, and the PIN are Sensitive Authentication Data. PCI DSS forbids retaining any of it after a transaction is authorized — and encryption is not an exception to that rule. Email stores everything by default: the Sent copy, the archive, the backup. So a CVV emailed to you becomes stored Sensitive Authentication Data the instant it arrives, which the standard does not allow.

Why one card email drags your whole mailbox into scope#

PCI DSS scope follows the data. Any system that stores, processes, or transmits cardholder data is in scope, and — without network segmentation to isolate it — so are the systems connected to it. A mailbox is a system that stores and transmits. The instant a PAN lands in it, that mailbox, the mail server behind it, and the backups that copy it are all handling cardholder data.

That is the part people miss. "We don't store cards" is a common and honest belief, right up until someone searches the support inbox and finds six months of replies with card numbers in them. The inbox stored them for you. Deleting your view of a message does not undo that — copies persist in Sent, in Trash until it purges, in server backups, and in any archive or eDiscovery tool an administrator runs.

This is also where automation matters. Because scope extends to connected systems, pointing any third-party tool — a client, an assistant, a CRM sync, an integration — at a mailbox that receives card data extends that scope to the tool as well. That is a question to raise before you connect anything, not after.

The data that must never reach your inbox#

Not all card data is equal. The card number can, in principle, travel by email if it is strongly encrypted; the security code can never be kept at all. The table sorts the common elements by what the standard allows, why, and what to do when each one lands in your inbox anyway.

The single rule underneath that table: the PAN is the element you may sometimes send when it is protected, and the CVV, track data, and PIN are the elements you must never retain. When one message mixes them, the safest move is to treat the whole message as something to remove, not something to keep and secure.

What to do when a customer emails their card number#

It will happen. A customer, trying to be helpful, pastes their sixteen digits and the CVV into a reply. Panic and improvisation are what create the real problem — a forward here, a screenshot there. Here is the containment sequence, in order.

1. 1

   Do not forward, reply-all, or quote it back

   Every forward and every quoted reply makes another copy in another mailbox you do not control. Stop there. Handle it yourself rather than looping in a colleague, and never paste the number into a ticket, chat, or CRM note.

2. 2

   Complete the payment through your normal secure channel

   If a charge genuinely needs to happen, run it the way you always do — your payment terminal, hosted checkout, or processor portal — reading from the email once, then closing it. Do not save the number anywhere to "process it later".

3. 3

   Delete every copy you control

   Remove the message from the Inbox, then from Trash or Deleted Items, and purge that folder. If you quoted the card in a reply, delete the Sent copy too. Your goal is that no PAN or CVV remains anywhere you can reach.

4. 4

   Reply to redirect — without quoting the card

   Send a short, friendly reply that does not repeat any card details: explain you cannot take card numbers by email, and give a secure alternative such as a hosted payment link or a phone number. The redirect is what stops it happening again next time.

5. 5

   Check backups and archives with IT

   Your delete does not reach server backups or a compliance archive an administrator runs. Ask whoever manages the mailbox to confirm the message is gone from those too, and to check whether retention or eDiscovery captured a copy.

6. 6

   Fix the intake so it stops

   One card email is an accident; a steady trickle is a process problem. Remove any macro or form that invites customers to send card details, and replace it with a payment link or PCI-compliant form so the number never reaches email at all.

Red flags your inbox already has a card-data problem#

Most inboxes that hold card data got there quietly, one helpful reply at a time. These are the signs worth searching for today, before an assessor or a breach finds them for you.

• A support macro or auto-reply that tells customers to "reply with your card details" to complete a payment.
• Card numbers sitting in Sent, Trash, or a shared archive from weeks or months ago that nobody has cleared.
• A shared or delegated inbox where card emails get forwarded between staff to "whoever can process it".
• Screenshots or photos of cards saved as attachments — an image of a PAN is still a PAN.
• Auto-forwarding rules that copy customer replies into a CRM, ticketing tool, or a second mailbox.
• The belief that "we never store card data" without anyone having actually searched the mailbox to check.

What we'd recommend — and where an AI inbox fits#

There is no email setting that makes card data safe to keep, so the honest recommendation is a stack, in priority order. First, and most important: stop card data reaching email at all. Send customers a hosted payment link or a PCI-compliant form so the number goes to your processor, never your inbox — this is the only step that actually shrinks your scope. Second: a written delete-and-redirect process for the times it slips through anyway. Third: fast human handling, so a card email is caught and cleared in minutes, not left to age in a queue.

That third layer is the only one where an AI email client like AI Emaily is relevant. AI Emaily triages incoming mail so a message that needs action surfaces quickly instead of sitting unread, and in Copilot mode it holds every reply and forward for your approval — so a card number is never forwarded to a colleague on reflex. It keeps an audit log of what the agent did, with undo, and it does not train on your mail. We build AI Emaily.

Be just as clear about what it is not. AI Emaily is a mail client, not a PCI service, a data-loss-prevention tool, or a redaction system — it does not detect card numbers, strip them out, or remove anything from PCI scope, and nothing it does makes it safe to store a CVV. If your inbox already receives card data, connecting any third-party client, ours included, is itself a scope decision to run past your acquirer or QSA first. It is the right fit if you want faster human handling and a send you control; it is the wrong fit if what you actually need is an automated compliance control.

See the plans and start a free trial if you want to test the approve-before-send workflow for yourself — with the scope caveat above kept firmly in mind.