How to Use 'RegEx' to Find Email Addresses in Text

Why Regular Expressions Belong in Your Toolkit

When you're staring at a 500MB log dump looking for every email address, IP, or timestamp buried in it, manually scanning is not an option. Regular expressions (regex) let you describe a pattern of characters rather than a literal string, so you can pull structured data out of unstructured text in one pass. Every mainstream language ships a regex engine, but Python's re module is the fastest way to prototype and reuse patterns, so that's what we'll use here.

Matching Email Addresses

A "perfect" RFC 5322-compliant email regex is notoriously long and impractical for everyday use. For log parsing and data extraction, a pragmatic pattern that covers the vast majority of real-world addresses is enough:

import re

text = "Contact us at support@xube.me or admin.backup@sub.example.co.uk for help."

pattern = r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}"

matches = re.findall(pattern, text)
print(matches)
# ['support@xube.me', 'admin.backup@sub.example.co.uk']

Breaking that pattern down:

• [a-zA-Z0-9._%+-]+ matches the local part before the @ — letters, digits, dots, underscores, percent signs, plus signs, and hyphens.
• @ matches the literal at-sign.
• [a-zA-Z0-9.-]+ matches the domain name, including subdomains separated by dots.
• \.[a-zA-Z]{2,} requires a final dot followed by a top-level domain of at least two letters (.com, .io, .co).

Matching IPv4 Addresses

IP addresses are trickier because a naive pattern like \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} will happily match invalid values like 999.999.999.999. If you need strict validation, constrain each octet to 0–255:

ip_pattern = r"\b(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\.){3}(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\b"

log_line = "Connection from 192.168.1.15 rejected by firewall rule 42"
print(re.findall(ip_pattern, log_line))
# ['192.168.1.15']

The \b word boundaries stop the pattern from matching partial numbers embedded inside longer digit strings. For most quick-and-dirty log grepping, the simpler \d{1,3}(?:\.\d{1,3}){3} is fine — you're extracting from trusted log output, not validating untrusted user input.

Matching Timestamps

Log timestamp formats vary wildly, but a common ISO-8601-style stamp looks like 2026-08-18 14:32:07 or with a T separator and milliseconds:

ts_pattern = r"\d{4}-\d{2}-\d{2}[T ]\d{2}:\d{2}:\d{2}(?:\.\d+)?"

line = "2026-08-18T14:32:07.451Z ERROR Failed to connect to db01"
print(re.findall(ts_pattern, line))
# ['2026-08-18T14:32:07.451']

If your logs use a syslog-style format instead (Aug 18 14:32:07), swap the date portion for [A-Z][a-z]{2}\s+\d{1,2}.

Pulling It All Together

To scan an entire log file and extract every email, IP, and timestamp in one pass, combine the patterns into named groups and iterate line by line rather than loading the whole file into memory:

import re

combined = re.compile(
    r"(?P\d{4}-\d{2}-\d{2}[T ]\d{2}:\d{2}:\d{2}(?:\.\d+)?)"
    r".*?(?P\d{1,3}(?:\.\d{1,3}){3})?"
    r".*?(?P[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})?"
)

with open("server.log", encoding="utf-8") as f:
    for line in f:
        match = combined.search(line)
        if match and any(match.groups()):
            print(match.groupdict())

Using named groups ((?P<name>...)) instead of positional groups makes the extracted dictionary self-documenting, which matters a lot once you're maintaining the script six months later.

Common Pitfalls

• Greedy vs. lazy quantifiers: .* is greedy and will consume as much as possible before backtracking. Use .*? when you want the shortest possible match between two anchors.
• Unescaped dots: A bare . matches any character, not just a literal period. Always escape it as \. when you mean a literal dot, or your email pattern will also match things like useraXcom.
• Catastrophic backtracking: Nested quantifiers like (a+)+ can cause the engine to hang on certain inputs. Keep patterns as specific as possible and avoid unnecessary nested groups.

Wrap-Up

Regex patterns for emails, IPs, and timestamps cover the vast majority of log-parsing needs without pulling in a heavier dependency. Keep your patterns as narrow as the data actually requires, test them against real samples before trusting them in production, and prefer named capture groups so future-you can read the extraction logic at a glance.