Published 2026-04-30 — v1.0

Email security stack methodology

CipherCue identifies email-security vendors observed in an entity's public DNS records. This page specifies the three signal types, the rule dictionary, the recorded fact shape, and false-positive policy.

An email security observation is an assertion that a vendor signature was matched in a public DNS record on the entity's apex domain. It is not an assertion that the vendor is in active use, that the configuration is correct, or that the vendor's product is correctly configured against the entity's threat model.

Signal types

Three independent signal types are observed:

MX records — the host that public mail servers route to is matched against vendor patterns. A Microsoft 365 tenant routes to *.mail.protection.outlook.com; a Mimecast pre-filter routes to *.mimecast.com; a Proofpoint tenant routes to *.pphosted.com. Multiple MX vendors can co-exist (e.g. Mimecast pre-filter in front of Microsoft 365).
DMARC rua= destinations — the addresses that DMARC aggregate reports are sent to. Vendors that monitor DMARC (Abnormal Security, Valimail, Agari, dmarcian, EasyDMARC) typically own a domain that rua= entries point to.
SPF include: directives — domains authorised to send on behalf of the apex. Transactional and marketing-email vendors (SendGrid, Mailchimp Transactional, Postmark, Amazon SES, Mailchimp, Salesforce) publish SPF includes that customers add to their record.

Rule dictionary

The current dictionary lives in config/ciphercue/email_security_rules.php. Each rule has the shape:

[
    'id' => 'mimecast-mx',
    'vendor' => 'Mimecast',
    'product' => 'Email Security Cloud Gateway',
    'category' => 'inbound_filter',
    'signal' => 'mx',
    'pattern' => '/\.mimecast(?:-offshore)?\.com$/i',
    'description' => '...',
]

Categories include inbound_filter, outbound_relay, dmarc_monitoring, provider, transactional. Adding a vendor is a documentation change and a methodology version bump.

Recorded fact

One email_security fact is written per (vendor, product) match per scan day. Multiple facts per entity are normal — a single domain can have a Microsoft 365 MX, a Mimecast pre-filter MX, and an Abnormal rua= destination, producing three facts.

domain — the apex domain
vendor, product, category
signal — mx, rua, or spf_include
evidence — the matched DNS string (the MX target, the rua destination, or the SPF-include domain)
authority_source = "public DNS query"
authority_url = this page

Pre-disclosure handling

Email security observations are derived from public DNS and are not subject to the 48-hour silent disclosure window. They are written with disclosure_status = "public_observation" and surfaced to customers immediately.

False-positive policy

The matcher is intentionally conservative — patterns are anchored to vendor-owned domains. Two known false-positive surfaces:

Shared providers — a generic Google Workspace MX (aspmx.l.google.com) is observed for any Workspace tenant. The recorded vendor is "Google" / "Google Workspace", not the customer's MSP.
Forwarded DMARC reports — some tenants DMARC-report to a third-party RUA aggregator that itself forwards to the vendor's analytics platform. CipherCue records the directly-observed RUA destination, not the downstream forwarding chain.

Correction

If a vendor match is wrong, email corrections@ciphercue.com. We investigate within 7 days. Adding a vendor to the dictionary is welcomed as a community contribution.

Changelog
v1.0 — 2026-04-30 — Initial publication. 25 vendor rules across MX, DMARC rua=, and SPF include: signal types.