Email Security Scanner (SPF / DMARC / DKIM / MX)

Passive DNS-only scan of a domain’s email authentication posture: MX targets with provider hints, SPF (v=spf1) parsing, DMARC at _dmarc, DKIM discovery via a bounded list of common selectors, plus MTA-STS and BIMI when published. No email is sent — there is no SMTP verification step.

Outputs a 0–100 email security score with a letter grade, plus human-readable issues and recommendations. Optional DNS fields are omitted from JSON when not present (no null noise — easier to read and harder to mistake for an actor failure).

What it does

Given one or more domains (or URLs — host is extracted; apex domain optional), the actor:

1. MX — Resolves MX records, sorted by priority. Adds inferredProvider only when the MX hostname matches a known pattern (Google Workspace, Microsoft 365, Cloudflare Email, etc.).
2. SPF — Finds v=spf1 in apex TXT, returns the raw record and a small parse (terminal all mechanism, redirect, include/mx/a flags, mechanism count).
3. DMARC — Reads _dmarc.<domain> TXT for v=DMARC1 and returns only tags that exist in the record (policy, rua, pct, sp, …).
4. DKIM — Probes {selector}._domainkey.<domain> for a bounded set of common selectors. A miss is inconclusive (many providers use custom selectors). If there is no DKIM match and DMARC is reject with SPF ending in -all or ~all, the hard “no DKIM” issue is not raised; instead a short informational recommendation explains the selector-list limitation. If any selector matches, no extra DKIM recommendation is added (avoids noise on strong domains like Cloudflare).
5. MTA-STS / BIMI — Detects _mta-sts and default._bimi TXT when present.
6. Score — Simple weighted model (MX + SPF strictness + DMARC policy + DKIM presence), capped 0–100 with grades A–F.

Use cases

• Sales / RevOps — Quick “does this domain look professionally managed?” signal before outreach
• Security & GRC — Lightweight evidence of SPF/DMARC posture (not a full pen-test)
• Deliverability audits — Baseline check for missing _dmarc, weak SPF defaults, missing MX
• Batch enrichment — Feed domains from CRM or spreadsheets; compare scores in a spreadsheet export

Input

Field	Type	Default	Description
domains	string[]	required	Domains or full URLs (host extracted).
useApexDomain	boolean	true	Collapse to registrable domain (mail.example.com → example.com).
maxDomains	integer	25	Max domains per run (1–100).
maxDkimProbes	integer	25	How many DKIM selectors to try per domain (5–60).
dnsTimeoutSeconds	number	12	Resolver timeout budget per query type (capped 4–30s).

Example input

{
  "domains": ["google.com", "https://www.cloudflare.com/"],
  "useApexDomain": true,
  "maxDomains": 25,
  "maxDkimProbes": 25,
  "dnsTimeoutSeconds": 12
}

Output

One dataset item per input. Keys appear only when meaningful — e.g. spf.record exists only if SPF is present; bimi.record only if BIMI TXT exists; inferredProvider on an MX row only if a hint matched.

Empty issues / recommendations arrays mean nothing material was flagged for that domain (not an error).

Example shape (illustrative)

{
  "domain": "cloudflare.com",
  "input": "https://www.cloudflare.com/",
  "mx": [
    {
      "priority": 5,
      "host": "mxa-canary.global.inbound.cf-emailsecurity.net",
      "inferredProvider": "Cloudflare Email Routing / Security"
    }
  ],
  "spf": {
    "present": true,
    "record": "v=spf1 ip4:199.15.212.0/22 ... -all",
    "parsed": {
      "raw": "v=spf1 ... -all",
      "allMechanism": "-all",
      "mechanismCount": 9,
      "hasInclude": true,
      "hasMx": false,
      "hasA": false
    }
  },
  "dmarc": {
    "lookupName": "_dmarc.cloudflare.com",
    "present": true,
    "record": "v=DMARC1; p=reject; pct=100; rua=mailto:...",
    "parsed": {
      "raw": "v=DMARC1; ...",
      "policy": "reject",
      "percentage": "100",
      "aggregateReports": "mailto:..."
    }
  },
  "dkim": {
    "validSelectors": [
      {
        "selector": "mandrill",
        "recordPreview": "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrLHiExVd55zd/...",
        "queryName": "mandrill._domainkey.cloudflare.com"
      }
    ],
    "probedSelectors": ["default", "google", "..."]
  },
  "mtaSts": { "present": false },
  "bimi": {
    "present": true,
    "record": "v=BIMI1; l=https://www.cloudflare.com/....svg; a=....pem"
  },
  "emailSecurityScore": { "score": 100, "grade": "A" },
  "issues": [],
  "recommendations": [],
  "scannedAt": "2026-05-15T12:00:00.000000+00:00"
}

Invalid input / errors

If a row cannot be scanned, you get input, error, and scannedAt (and domain when normalization succeeded). No fake null fields for “missing scan sections”.

What makes this different

Aspect	This actor	“Full security suite”
Data source	DNS only (fast, cheap)	Often includes SMTP, APIs, crawlers
SMTP / send test	No	Sometimes yes
DKIM certainty	Probes common selectors; custom selectors may not appear	May require provider API or live mail
Output style	Omits absent fields; lists can be empty	Often many nulls
Pairing	Complements Tech Stack Detector (same “signal from domain/URL” family)	Broader scope, higher cost

Limitations

• Not SMTP verification — The actor never connects to port 25 or sends mail; it cannot prove inbox deliverability.
• Heuristic score — The 0–100 grade is a practical summary, not a certification or legal/compliance sign-off.
• DKIM coverage — Only a fixed list of common selectors is probed; absence in output does not prove absence of signing infrastructure.

Technology

• DNS: dnspython (TXT, MX)
• Domain normalization: tldextract for optional apex collapse
• Runtime: Python 3.12 on apify/actor-python

Local test

cd actors/email-security-scanner
python3 test_local.py google.com cloudflare.com

Deploy

Same workflow as your other actors: from this folder, apify push builds a new Docker image and updates the same Apify actor (no separate “second deploy” flow — every push is a new build/version on that actor). Ensure you are logged in (apify login) and the folder is linked to the right actor if you use multiple accounts.

cd actors/email-security-scanner
apify push