EVIDENCE GUIDE (NOT A POLICY)
Email Security Configuration Guide
Evidence checklist: DNS records (SPF, DKIM, DMARC) vs. tenant configuration (filtering, external sender warnings, link scanning). Understand what DNS proves and what carriers need to verify.
What this cyber insurance requirement is
Email security configuration for cyber insurance includes two layers: DNS authentication records (SPF, DKIM, DMARC) that prove domain-level protection, and email platform configuration (filtering, external sender warnings, link scanning, attachment sandboxing) that proves operational threat detection. Carriers evaluate both layers during underwriting — DNS records alone are insufficient. This guide helps you understand what each layer proves and what evidence to collect for your carrier.
Assess your email security configuration below
What you'll get
This is an evidence guide, not a policy template. It helps you understand:
- What DNS records (SPF, DKIM, DMARC) prove and don't prove
- What email platform settings (Microsoft 365, Google Workspace) prove
- Which evidence to collect for each carrier requirement
- Gaps between configuration and actual threat detection
This guide helps you assess what email security controls are configured and what evidence proves each control to carriers.
The domain(s) used in your company email addresses (e.g., user@example.com).
SPF (Sender Policy Framework) specifies which servers can send email for your domain. Check at mxtoolbox.com or nslookup your SPF record.
DKIM (DomainKeys Identified Mail) digitally signs emails. Both Microsoft 365 and Google Workspace support DKIM.
DMARC policy controls how receivers handle failed SPF/DKIM. p=none provides monitoring without enforcement. p=reject is strongest.
Email gateway (MTA proxy, cloud filter, or native platform filtering) that scans for malicious links and attachments.
Emails from external senders are tagged (e.g., [EXTERNAL] in subject or banner in body) to help users identify non-company emails.
Email gateway or platform scans URLs in email for known-malicious or suspicious domains and sandboxed URLs.
Attachments are detonated in a sandbox environment to detect malware that static scanning might miss.
What carriers are looking for
Each carrier asks slightly different questions. Here are some named artifacts by carrier.
Hartford
- Email filtering configuration
- Malicious link and attachment screening
- External sender tagging
- Proof of anti-phishing and malware detection
Beazley
- Email security assessment including filtering
- Phishing protections and external sender identification
- Configuration screenshots to satisfy requirements
Coalition
- SPF, DKIM, and DMARC records evaluation
- Authentication framework documentation
- Email gateway filtering configuration
- Link and attachment scanning settings
What DNS Records Prove (and Don't)
What DNS Proves
SPF Record: You've authorized specific mail servers to send email for your domain.
DKIM Keys: Emails from your domain are signed cryptographically. Recipient can verify you sent it.
DMARC p=reject: You've published policy telling receivers to reject emails that fail SPF/DKIM.
What DNS Does NOT Prove
SPF/DKIM: That email filtering actually blocked attacks or checked these records.
DMARC p=none: Provides monitoring only—non-authenticated emails still deliver. No enforcement.
Any DNS: That your email gateway scans links, sandboxes attachments, or tags external senders.
How to Collect Email Security Evidence
Step 1: DNS Records
For SPF: nslookup -type=TXT [domain].com | grep v=spf1
For DKIM: Check admin console for DKIM selectors and run nslookup to verify public key records
For DMARC: nslookup -type=TXT _dmarc.[domain].com
Step 2: Platform Configuration
Microsoft 365: Exchange admin center → Protection → Anti-phishing, Anti-malware, Safe Links, Safe Attachments policies
Google Workspace: Admin console → Security → Email & Calendar → Attachment/Link settings
3rd Party Gateway: Admin console showing anti-phishing, anti-malware, URL filtering, and sandboxing rules
Step 3: Evidence Documents
- Screenshots of DNS records (SPF, DKIM, DMARC)
- Admin console configuration pages for anti-phishing and anti-malware
- Safe Links / URL filtering policy screenshot
- Attachment sandboxing / detonation configuration
- External sender warning policy (if configured)
- Sample email showing external sender tag/banner
Frequently Asked Questions
Do we need SPF, DKIM, and DMARC all at once?
SPF and DKIM are prerequisite to DMARC. Start with SPF and DKIM, then DMARC p=none (monitoring), then p=quarantine, then p=reject. Most carriers accept p=quarantine or p=reject.
Is DMARC p=none acceptable to carriers?
p=none provides visibility but no enforcement. Attackers can still spoof your domain. Carriers prefer p=quarantine or p=reject. If you're using p=none, document your roadmap to enforcement.
What if we have multiple domains?
Collect SPF, DKIM, DMARC records for every domain you send email from. Include acquisition/subsidiary domains and branded domains. Missing records for any active domain is a gap.
Should we screenshot email gateway config or provide exports?
Screenshots are usually sufficient. If the carrier asks for more detail, they'll request policy exports or XML configuration. Start with screenshots.
What does external sender warning really prevent?
External sender warning tags emails from outside your organization. It creates a visual indicator that a message isn't from a colleague. It doesn't block anything—it relies on users noticing the tag.
Can we use both tenant filtering and a third-party gateway?
Yes. Many organizations use both (e.g., Proofpoint in front of Microsoft 365). Document both layers of filtering. Carriers appreciate defense in depth.
Common Email Security Gaps
- DMARC p=none: Monitoring without enforcement. Attackers can spoof domain. Upgrade to p=quarantine or p=reject.
- No external sender warning: Users can't distinguish internal from external emails. Enable in 365/Workspace.
- Link scanning not enabled: URL filtering configuration not activated. Check Safe Links or gateway filtering policies.
- No attachment sandboxing: Malware in attachments won't be caught by static analysis. Enable detonation.
- Tenant filtering only: No third-party gateway. Consider layered defense (gateway + tenant).
- Missing DKIM for some domains: Acquired brands or third-party senders not covered by DKIM.
Sources (March 2026)
- CISA – Domain-based Message Authentication, Reporting, and Conformance (DMARC) deployment guidance
- Microsoft 365 – Defender for Office 365 configuration best practices
- Google Workspace – Email security settings and anti-phishing configuration
- Coalition – Email security assessment criteria and carrier requirements
- Hartford – Email filtering and malware screening questionnaire requirements
- Beazley – Email security questionnaire and phishing protection assessment
- NIST – Email security controls (NIST CSF PR.PT-1, PR.PT-2)