Email Security Analysis

Overview

Email authentication relies on three DNS-based mechanisms:

• SPF - Authorized sending IPs
• DKIM - Cryptographic message signing
• DMARC - Policy enforcement and reporting

Complete Email Security Check

For domain example.com, start with a comprehensive DNS lookup:

datapulse_live_dns(domain="example.com")

This returns all record types (A, AAAA, MX, NS, TXT, SOA, CNAME, CAA, DNSKEY, DS) plus the DMARC policy in a single call. SPF is in the TXT records; DMARC is in the dedicated dmarc field.

1. SPF Record

Look for TXT record starting with v=spf1:

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

SPF Qualifiers:

Suspicious IP Literals in SPF

Do not stop at include: and the final qualifier. Also inspect any ip4: and ip6: mechanisms and explicitly report suspicious IP space.

If you find non-public address space in SPF, call it out as potentially hostile or, at minimum, a misconfiguration. Published SPF should normally reference globally routable mail-sending infrastructure.

Flag these especially:

• IPv4 RFC1918 private ranges in ip4:: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• IPv6 ULA space in ip6:: fc00::/7 including fd00::/8
• Other clearly non-routable or special-use space such as loopback, link-local, or unspecified addresses
• Malformed or impossible IP literals / prefix lengths in SPF mechanisms

Examples to report:

v=spf1 ip4:10.0.0.0/8 -all
v=spf1 ip6:fd00::/8 include:_spf.example.net ~all
v=spf1 ip4:300.1.2.3 -all
v=spf1 ip6:fd00::/129 -all

When reporting SPF findings, mention the exact suspicious mechanism and why it is unusual. Example: “ip4:10.0.0.0/8 is RFC1918 private space and should not appear as public sending infrastructure in SPF.”

2. DMARC Record

The dmarc field in the default DNS response contains the _dmarc.<domain> TXT record automatically — no separate query needed. The field has status ("found" or "none") and record (the full DMARC value when found).

Look for value starting with v=DMARC1:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com

DMARC Policies:

Key DMARC Tags:

3. DKIM Selector Records

Query common DKIM selector subdomains:

Common selectors to try:

• google._domainkey.example.com (Google Workspace)
• selector1._domainkey.example.com (Microsoft 365)
• selector2._domainkey.example.com (Microsoft 365)
• k1._domainkey.example.com (Mailchimp)
• s1._domainkey.example.com (Generic)
• default._domainkey.example.com (Generic)

Note: Selectors are arbitrary strings chosen by the domain owner. Absence of these common selectors does not prove DKIM is absent—the domain may use custom selectors.

DKIM record example:

v=DKIM1; k=rsa; p=MIIBIjANBgkq...

4. MX Records

MX records are included in the datapulse_live_dns response from step 1. Cross-reference with SPF to understand mail flow.

An MX record is a claim, not a credential

Anyone may publish an MX pointing at any host, including a major provider’s, without that provider having provisioned anything. Presence of a recognisable platform hostname is not evidence that the platform accepts mail for the domain.

Hosted platforms derive the inbound hostname from the tenant’s own domain. For Exchange Online, a correctly provisioned record for example.com reads example-com.mail.protection.outlook.com — the domain’s own label with dots replaced by hyphens. An MX that names a different organisation’s tenant hostname is a record that was copied rather than provisioned, and the platform will disown it at delivery time:

550 5.7.64 TenantAttribution; Relay Access Denied

Read the MX hostname against the domain publishing it before drawing conclusions from the platform it names.

Inbound and outbound are separate questions

A broken inbound path does not narrow the outbound one. With no SPF and no DMARC, nothing prevents a third party sending mail as the domain, whether or not it can receive any. Evaluate SPF and DMARC in their own right; never infer them from the presence or absence of an MX.

No MX can be the correct posture

A domain not intended to receive mail commonly publishes no MX at all while still publishing a restrictive SPF (-all) and p=reject DMARC. That configuration refuses inbound structurally and strongly protects against successful spoofing at DMARC-enforcing receivers — a forged message can still be transmitted, but compliant receivers reject or quarantine it — and is stronger than a brand-shaped MX with no SPF or DMARC. Do not score MX absence as a gap without reading SPF and DMARC alongside it.

Security Assessment Matrix

Example Workflow

# 1. Comprehensive DNS — gets MX, TXT (SPF), NS, A, AAAA, CAA, SOA + DMARC in one call
datapulse_live_dns(domain="example.com")

# 2. Check DKIM (try common selectors)
datapulse_live_dns(domain="google._domainkey.example.com")
datapulse_live_dns(domain="selector1._domainkey.example.com")

# 3. Historical context - did they recently add these?
datapulse_dns_dphistory(domain="example.com")

Red Flags

• No SPF record at all
• SPF with +all
• SPF contains private, non-routable, or malformed ip4: / ip6: mechanisms
• No DMARC record
• DMARC with p=none on a production domain (acceptable only during rollout)
• MX names a mail tenant belonging to a different organisation (copied record — see above)
• MX present on a domain with no SPF and no DMARC at all
• Very short DKIM keys (< 1024 bits)

Not a red flag: “DKIM status could not be determined from the common-selector probes”. Selectors cannot be enumerated (see the DKIM note above), so an undetermined DKIM status is an absence of evidence, not adverse evidence.

MX and SPF need not name the same hosts: MX controls inbound routing while SPF authorises outbound envelope senders, and a domain that receives mail on one platform and sends through another is ordinary. Do not flag the mismatch on its own.

Related Topics

• datapulse_help(topic="brand_adjacent") — brand-carrying domains whose MX names the brand’s mail platform without the tenant accepting the domain
• datapulse_help(topic="typo_squatting") — misspellings, homoglyphs, and defensive registrations