Outlook stores email addresses in message bodies, signatures, contact cards, calendar invitations, and message headers, and you can extract those addresses by copying the relevant Outlook text and pasting it into the Email Extractor, which scans the characters locally and returns a deduplicated, newline-separated list. The whole workflow happens inside the current browser tab, so the message content you paste never travels to a server and no Outlook add-in, COM plugin, or external program is required. The tool recognizes common ASCII email shapes, merges case-only duplicates while preserving the first spelling it saw, and stops on surrounding punctuation so signatures and prose do not bleed into the result. There is no upload step, no sign-in, and no install: you copy text from Outlook, paste it into the text area, pick first-appearance order or A–Z, and select Extract emails. The output is one address per line, ready to drop into a CRM import, a spreadsheet column, or a suppression list.
Where Outlook Hides Email Addresses
Outlook spreads addresses across many surfaces, and the trick is knowing which surfaces to copy so the extractor has good candidates to work with. The most common source is the message body itself, where replies and forwards accumulate addresses inside quoted history and signature blocks. The signature block on a received message is often the cleanest source because it usually contains a single person's mailbox, while replies and reply-alls can stack dozens of addresses inside the quoted text.
Other surfaces that hold useful addresses include:
- Contact cards in the People pane, where each card has up to three email fields plus a Notes area that sometimes lists more.
- Meeting invitations, which store organizer, required attendees, and optional attendees in the message body and in the .ics attachment.
- Message headers, reached through File > Properties, which list every hop plus the original From, To, Cc, and Reply-To values.
- Search results in the ribbon, where any address shown for a found message can be copied through a right-click menu.
- Shared mailboxes and delegated folders, where the address you want to capture belongs to someone other than the account owner.
The Outlook data file itself, a .pst in Outlook for Windows or an .olm in Outlook for Mac, is a binary container and not something the Email Extractor can open. The tool works on plain text only, so the workflow is to surface the address through Outlook's own copy commands and feed that text into the extractor.
Copy the Outlook Text You Want to Scan
The extractor is pattern-based, so what you paste determines what you get. Plain-text copies give the cleanest input because the pattern matcher only sees the characters on screen. HTML and rich-text copies bring hidden formatting tags that do not contain addresses but can occasionally wedge a Unicode character next to an address-shaped suffix and cause the candidate to be rejected as unsupported.
For a single message, the simplest path is to open the message, press Ctrl+A to select all, then Ctrl+C. For a forwarded chain, decide whether you want addresses from earlier in the thread as well; leaving the quoted history in place lets the extractor pick up those addresses too. For a folder of messages, the Outlook save-as-archive route produces a .pst that still needs to be opened elsewhere, but you can use Outlook's print-to-file or copy-paste from the reading pane to keep the work in plain text.
Two habits keep the input clean. First, avoid pasting from the message header dialog box raw into the extractor when the header includes a long Received chain, because the chain tends to contain delivery-system addresses rather than the people you actually want. Second, if your contact notes include addresses inside square brackets, drop the brackets or rely on the extractor's automatic handling of common surrounding punctuation, which already strips commas, semicolons, closing brackets, quotes, and exclamation marks from the end of each candidate.
Run the Email Extractor on Pasted Outlook Content
- Paste the Outlook text into the text area. Watch the visible character counter and confirm the input stays within 500,000 JavaScript characters. If you go over, the counter turns red and extraction returns an error rather than truncating the input silently.
- Pick an order. Choose first-appearance order if you want to preserve the order in which addresses appeared in the source, or case-insensitive A–Z if you want a tidy list to skim. Switching the order after a run clears the previous result.
- Select Extract emails. The tool scans the text in the current tab, runs each candidate through its validator, deduplicates using a lowercase key, and prepares the newline-separated output. No network request is made.
- Read the counts. After a successful run, the result area reports the number of unique addresses, the number of duplicates that were merged, and the number of rejected candidates. Use the rejected figure to decide whether the source needs editing.
- Copy the result. Click Copy all to push the newline-separated list to the clipboard asynchronously, or select the output manually if clipboard permission is unavailable.
Sort, Review Counts, and Copy the List
The output places one address on each line with no numbering and no header row. Counts matter because they tell you what the tool actually did. The unique count is the size of your final list. The duplicate count is the number of times the same lowercase key reappeared in the source, which is common in reply chains where the same sender signs every message. The rejected count covers malformed candidates, URL userinfo segments, Unicode attachments, and any local-part or domain shape that violates the documented rules.
If you change the sort order or edit the input after a run, the prior list, the error state, and the copy status all clear, so the on-screen result always matches the text currently in the text area. A failed run also clears the previous result before reporting the problem, which means a stale list from earlier text cannot linger and look like it matches new text. The Copy all button only reports success for the result that is currently on screen; editing the input or leaving the page invalidates any in-flight copy status update.
What the Extractor Catches and What It Rejects
The tool is intentionally narrow. It recognizes a documented practical ASCII form: a local part of up to 64 characters made of letters, digits, dots, underscores, percent signs, plus signs, and hyphens; a single at sign; and a DNS-style domain with at least two labels, where the final label must be 2 to 63 ASCII letters under this product's policy. These rules match the dot-atom form described in RFC 1035's preferred name syntax for the domain side and the practical mailbox shape used by ordinary web addresses.
| Pattern in Outlook text | Result | Why |
|---|---|---|
| [email protected] | Accepted | Standard local part, multi-label domain, final label of letters only. |
| [email protected] | Accepted | Allowed plus sign and interior dot, two-letter final label within the 2 to 63 letter policy. |
| mailto:[email protected] | Accepted | Mailto prefix is preserved and the address after it is extracted because mailto is explicitly an email destination. |
| [email protected] | Rejected | Consecutive dots in the local part are disallowed to prevent obvious typos. |
| [email protected] | Rejected | Domain label cannot begin with a hyphen. |
| [email protected] | Rejected | Empty domain label is not permitted. |
| https://[email protected]/private | Rejected | URL userinfo is collected separately and is not reported as a contact address. |
| alice@пример.рф | Rejected | Cyrillic mailbox text falls outside the practical ASCII form. |
Quoted local parts, comments, escaped characters, domain literals written as an IP address in brackets, and Unicode mailboxes are excluded by design because the tool is a practical extractor, not a full RFC 5322 parser. Some technically legal but unusual mailboxes are therefore skipped on purpose, and any extracted string is only proof that the pattern matched, not that the mailbox exists or accepts mail.
After Extraction: Verifying and Using the List
An address in the output is a pattern match, not a verification. Outlook data files, forwarded threads, and contact cards all mix real mailboxes with role addresses, distribution lists, and typos, so a clean extraction is the starting point rather than the final answer. The extractor's behavior matches the input contract used by browser input fields per MDN's email input validation guidance, where the goal is practical recognition rather than proof of existence.
Before you send anything to the list, review consent, privacy rules, suppression requirements, and the source of every address. Extraction does not grant permission to contact someone, confirm mailbox ownership, distinguish role accounts from personal mailboxes, or flag disposable domains. For high-stakes account creation or deliverability work, combine the extracted list with confirmation messages, DNS checks, bounce handling, and human review rather than treating the pattern match as proof that the address is live.
For everyday tasks such as cleaning a contact list, pulling addresses out of project notes, preparing a small spreadsheet import, or inspecting test data, the local extract-and-copy workflow is usually enough. If the addresses you need are trapped in an Excel column rather than Outlook text, a separate Excel cell extraction walkthrough covers the same tool in that context.
If you're weighing options, Extract Numbers From Google Sheets Text in One Pass covers this in detail.