Skip to content
HackIndex logo

HackIndex

Email Infrastructure Analysis

4 min read Apr 11, 2026

Overview

Email infrastructure analysis maps a domain's mail configuration through its DNS records. MX records reveal what mail providers an organisation uses. SPF and DMARC records expose internal infrastructure, cloud services, and security posture. This data is useful for both identity intelligence and organisational profiling, and feeds directly into email discovery by confirming the mail stack before probing it.

MX Record Enumeration

MX records identify the mail servers responsible for receiving email on behalf of a domain. The provider revealed by MX records tells you where the organisation's email is hosted and what security controls to expect.

┌──(kali㉿kali)-[~]
└─$ dig MX $DOMAIN +short | sort -n 
10 mail1.example.com.
20 mail2.example.com.
30 aspmx.l.google.com.

Common MX record patterns and what they reveal:

  • *.google.com or *.googlemail.com — Google Workspace. SMTP verification is unreliable because Google returns 250 for all addresses on most domains.

  • *.outlook.com or *.protection.outlook.com — Microsoft 365. SMTP verification is more reliable but Microsoft has rate limiting on repeated RCPT TO probes.

  • *.mimecast.com or *.proofpoint.com — Third-party email security gateway in front of the actual mail server. The real internal server is hidden behind it.

  • Self-hosted MX pointing to the organisation's own domain — on-premises mail infrastructure. More likely to respond accurately to SMTP verification.

SPF Record Analysis

SPF records list every IP range, hostname, and service authorised to send email on behalf of the domain. Reading them reveals internal mail infrastructure, cloud providers, marketing platforms, CRM systems, and third-party services the organisation uses.

┌──(kali㉿kali)-[~]
└─$ dig TXT $DOMAIN +short | grep spf 
"v=spf1 include:_spf.google.com include:mail.zendesk.com ip4:203.0.113.0/24 ip6:2001:db8::/32 include:sendgrid.net ~all"

Each include: and ip4: entry is a data point. In the example above, the organisation uses Google Workspace for primary email, Zendesk for support ticketing, SendGrid for bulk mail, and owns the IP range 203.0.113.0/24. This single record maps a significant portion of the organisation's SaaS stack and identifies IP ranges that belong to them.

Resolve nested SPF includes to find additional infrastructure:

┌──(kali㉿kali)-[~]
└─$ dig TXT _spf.google.com +short 
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

For IP ranges that belong to the organisation rather than a provider, those ranges are worth investigating further for exposed services, hostnames, and additional infrastructure.

DMARC Record Analysis

DMARC records define how the domain handles unauthenticated email and where forensic and aggregate reports are sent. The reporting addresses are often internal distribution lists or third-party monitoring services, and they reveal additional email addresses and infrastructure.

┌──(kali㉿kali)-[~]
└─$ dig TXT _dmarc.$DOMAIN +short 
"v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100"

The rua address receives aggregate reports. The ruf address receives forensic copies of failed messages. Both are confirmed live email addresses. The forensic reporting address in particular is often monitored by a security or IT team, making it a useful contact for social engineering context.

DMARC policy also indicates security maturity:

  • p=none — monitoring only, no enforcement. The domain does not reject spoofed email.

  • p=quarantine — unauthenticated mail is sent to spam.

  • p=reject — unauthenticated mail is rejected outright. Hardest to spoof from.

DKIM Key Discovery

DKIM selectors are named identifiers used to look up the public key for email signing. Knowing the selector names reveals which mail platforms are in use and confirms the signing infrastructure. Common selectors include google, k1 for Mailchimp, s1 and s2 for various providers, and default.

┌──(kali㉿kali)-[~]
└─$ for selector in google default s1 s2 k1 mail dkim selector1 selector2; do dig TXT ${selector}._domainkey.$DOMAIN +short | grep -q 'v=DKIM' && echo "[+] Selector found: $selector"; done 
[+] Selector found: google
[+] Selector found: s1

Automated Infrastructure Summary

MXToolbox aggregates MX, SPF, DMARC, and blacklist checks in a single query and is faster than running each lookup manually for initial triage:

┌──(kali㉿kali)-[~]
└─$ curl -s "https://api.mxtoolbox.com/api/v1/Lookup/mx/?argument=$DOMAIN" -H "Authorization: $MXTOOLBOX_API_KEY" | jq '.Information'

The full picture from MX, SPF, DMARC, and DKIM together maps the organisation's email providers, internal IP ranges, third-party services, security posture, and live internal addresses. This feeds directly into organisational profiling and provides context for any further email-based investigation.

References