Overview

---
name: overview
description: "Cross-platform mail and collaboration strategy: platform selection (Exchange vs. M365 vs. Google Workspace vs. Postfix), mail flow architecture, DNS design, migration planning, and compliance framework mapping across the whole mail-collab plugin. WHEN: \"email platform comparison\", \"migrate to M365 or Google Workspace\", \"design mail flow architecture\", \"DNS records for a new mail domain\", \"on-prem vs cloud email\", \"email compliance framework\", \"tenant migration planning\". Do NOT use for single-platform implementation, cmdlets, or troubleshooting — read that platform's skill directly (`exchange`, `m365`, `google-workspace`, `postfix`)."
license: MIT
---

# Mail & Collaboration Domain Overview

This skill covers cross-platform mail, messaging, and collaboration expertise: email infrastructure, mail flow architecture, DNS configuration, compliance, and migration planning. Read it for strategic and comparison questions; read a platform skill directly for implementation depth.

## When to Use This Skill vs. a Technology Skill

**Use this agent when the question is cross-platform or strategic:**
- "Should I migrate from Exchange on-prem to M365 or Google Workspace?"
- "Design our mail flow architecture with a third-party SEG"
- "Compare Exchange Online vs. Google Workspace for a 5,000-user org"
- "What DNS records do I need for a new mail domain?"
- "How should we handle email coexistence during a merger?"
- "MX record best practices for failover"
- "What compliance framework applies to our email archiving?"
- "Evaluate on-prem vs. cloud email for regulated industries"

**Use a technology skill directly when the question is technology-specific:**
- "Exchange DAG failover not working" --> the `exchange` skill
- "Hybrid Configuration Wizard errors" --> the `exchange` skill
- "M365 Conditional Access policy for email" --> the `m365` skill
- "Microsoft Purview retention policy setup" --> the `m365` skill
- "Google Workspace GCDS sync failing" --> the `google-workspace` skill
- "Gmail DLP rule not triggering" --> the `google-workspace` skill
- "Postfix TLS configuration" --> the `postfix` skill
- "Postfix queue stuck in deferred" --> the `postfix` skill

## How to Approach Tasks

1. **Classify** the request:
   - **Platform selection / comparison** -- Use the comparison tables below
   - **Architecture / mail flow design** -- Load `references/concepts.md` for protocol fundamentals and mail flow patterns
   - **On-premises architecture** -- Load `references/paradigm-onprem.md` for Exchange Server and Postfix patterns
   - **Cloud architecture** -- Load `references/paradigm-cloud.md` for Exchange Online, M365, and Google Workspace patterns
   - **Migration planning** -- Identify source and target, then read the relevant technology skill
   - **Compliance / governance** -- Load `references/concepts.md` for regulatory frameworks, then read the platform skill
   - **Email security** -- Use the `email-security` skill (in the `security` plugin) for SPF/DKIM/DMARC, phishing, BEC, and SEG architecture
   - **Technology-specific** -- Read that technology skill directly

2. **Gather context** -- Organization size, current platform, target platform, regulatory requirements, hybrid needs, mail volume, geographic distribution, existing identity infrastructure

3. **Analyze** -- Apply mail architecture principles (DNS hygiene, authentication chain, transport security, high availability, compliance obligations)

4. **Recommend** -- Actionable guidance with trade-offs, not a single answer

## Mail Architecture Principles

1. **Authentication is layered** -- SPF validates the sending server, DKIM validates message integrity, DMARC ties them together with policy enforcement. All three are mandatory for any production mail domain. For details, see the `email-security` skill in the `security` plugin.
2. **Encryption in transit is non-negotiable** -- TLS 1.2+ for all SMTP connections. Enforce with MTA-STS or DANE, not just opportunistic STARTTLS. Port 587 for client submission must require encryption.
3. **DNS is your mail infrastructure** -- MX records, SPF, DKIM selectors, DMARC, MTA-STS, BIMI, and Autodiscover all live in DNS. DNS errors are mail outages. Treat DNS changes as production deployments.
4. **High availability requires redundancy at every layer** -- Multiple MX records, DAG copies (Exchange), multi-geo (M365/Google), clustered MTAs (Postfix). No single point of failure.
5. **Compliance drives architecture** -- Retention, legal hold, journaling, and eDiscovery requirements determine whether native tools suffice or third-party archiving is required. Know your regulatory obligations before designing.
6. **Separation of concerns** -- MTA (routing) is separate from MDA (delivery) is separate from MUA (client). Each layer can be independently scaled, secured, and replaced.
7. **Migration is a project, not a button** -- Every migration requires DNS planning, identity sync, coexistence strategy, user communication, and rollback planning. Batch migrations with validation gates reduce risk.
8. **Monitor mail flow, not just server health** -- Message trace, queue depth, delivery latency, bounce rates, and DMARC aggregate reports are the metrics that matter. Server CPU is not a mail flow metric.

## Platform Comparison

### Email Platforms

| Platform | Model | Best For | Trade-offs |
|---|---|---|---|
| **Exchange Server 2019/SE** | On-premises, self-managed | Regulated industries requiring on-prem data control, hybrid coexistence | High operational overhead, end-of-support (2019), annual subscription (SE) |
| **Exchange Online (M365)** | Cloud-managed | Enterprise email with compliance, hybrid identity, Defender integration | Microsoft ecosystem lock-in, licensing complexity, feature velocity |
| **Google Workspace** | Cloud-managed | Cloud-native organizations, Google ecosystem, education | Limited hybrid AD integration, less granular compliance tooling vs. Purview |
| **Postfix** | Open-source MTA | Linux mail relay, custom mail flow, ISP-scale delivery, edge transport | No built-in mailbox storage (pair with Dovecot), no GUI, requires Linux expertise |

### Collaboration Suites

| Feature | Microsoft 365 | Google Workspace |
|---|---|---|
| Email | Exchange Online (100 GB E3/E5) | Gmail (pooled storage) |
| Calendar | Outlook/Exchange Calendar | Google Calendar |
| File storage | OneDrive + SharePoint | Google Drive + Shared Drives |
| Real-time docs | Office Online (Word, Excel, PPT) | Docs, Sheets, Slides |
| Chat/messaging | Microsoft Teams | Google Chat |
| Video meetings | Teams Meetings | Google Meet |
| Identity | Entra ID (AD integration native) | Cloud Identity (GCDS/SAML for AD) |
| Compliance | Microsoft Purview (E5) | Google Vault + DLP (Enterprise) |
| Security | Defender for Office 365 | Gmail security + BeyondCorp |
| Archiving | Exchange Online Archiving | Google Vault |
| eDiscovery | Purview eDiscovery (Standard/Premium) | Google Vault search/export |

## Decision Framework

### Step 1: On-premises or cloud?

| Factor | On-premises | Cloud |
|---|---|---|
| **Data sovereignty** | Full control over data location | Depends on provider data residency options |
| **Regulatory** | Some regulations mandate on-prem (government, defense) | Most regulations now permit cloud with proper controls |
| **Operational cost** | CapEx + skilled Exchange/Linux admins | OpEx subscription, lower admin overhead |
| **Scalability** | Hardware-bound | Elastic |
| **HA/DR** | DAG + site resilience (Exchange), clustered Postfix | Built-in (Microsoft/Google manage HA) |
| **Feature velocity** | Slower (CU cadence) | Continuous updates |

### Step 2: Microsoft or Google ecosystem?

| Factor | Microsoft 365 | Google Workspace |
|---|---|---|
| **Existing identity** | On-prem AD + Entra ID Connect | Cloud-first or GCDS/SAML |
| **Desktop apps** | Full Office desktop suite | Web/mobile-first, limited desktop |
| **Compliance depth** | Advanced (Purview, E5 compliance suite) | Standard (Vault, DLP, data regions) |
| **Admin tooling** | PowerShell + Graph API + Admin Centers | Admin Console + GAM + APIs |
| **Hybrid mail** | Native HCW, free/busy, shared namespace | Limited (GWSMO, no native hybrid) |
| **Pricing (enterprise)** | E3 ~$36/user/mo, E5 ~$60/user/mo | Enterprise Standard ~$20, Plus ~$30 |
| **Education** | A1 free, A3/A5 discounted | Education Fundamentals free |

### Step 3: Migration path?

| Source | Target | Recommended Path |
|---|---|---|
| Exchange on-prem | Exchange Online | Full Hybrid (>150 mailboxes), Cutover (<150) |
| Exchange on-prem | Google Workspace | GWMME + GCDS for directory sync |
| Google Workspace | M365 | Native M365 migration endpoint + Entra ID |
| M365 Tenant A | M365 Tenant B | Cross-tenant mailbox migration + BitTitan |
| IMAP server | M365 or Google | IMAP migration batch (email only) |
| Postfix/Dovecot | M365 or Google | IMAP migration (email) + manual calendar/contacts |
| Lotus Notes | M365 | Third-party tools (Quest, Binary Tree) |

### Step 4: Compliance requirements?

| Requirement | Recommended Approach |
|---|---|
| SEC 17a-4 / FINRA | Third-party journaling archive (Smarsh, Global Relay, Mimecast) |
| HIPAA | M365 E5 with DLP + sensitivity labels, or Google Enterprise Plus with DLP |
| GDPR | Data residency controls (Multi-Geo or data regions) + retention limitation |
| SOX | 7-year retention policy + audit logging + eDiscovery capability |
| Legal hold | Native litigation hold (M365) or Vault hold (Google) |
| General compliance | Native archiving + retention policies sufficient for most organizations |

## DNS Quick Reference for Mail Domains

Every mail domain requires a baseline set of DNS records. Missing any of these is a production gap.

### Required DNS Records

| Record | Type | Purpose | Example |
|---|---|---|---|
| MX | MX | Mail server(s) for the domain | `10 mail.example.com.` |
| SPF | TXT | Authorized sending servers | `v=spf1 include:spf.protection.outlook.com -all` |
| DKIM | TXT/CNAME | Public key for message signing | `selector1._domainkey.example.com` |
| DMARC | TXT | Authentication policy + reporting | `v=DMARC1; p=reject; rua=mailto:dmarc@example.com` |
| Autodiscover | CNAME/SRV | Client auto-configuration (Exchange) | `autodiscover.outlook.com` |

### Recommended DNS Records

| Record | Type | Purpose | Example |
|---|---|---|---|
| MTA-STS | TXT + HTTPS | Enforce TLS for inbound SMTP | `v=STSv1; id=20240101T000000` |
| TLS-RPT | TXT | TLS failure reporting | `v=TLSRPTv1; rua=mailto:tls@example.com` |
| BIMI | TXT | Brand logo in email clients | `v=BIMI1; l=https://example.com/logo.svg` |
| DANE/TLSA | TLSA | Certificate pinning (requires DNSSEC) | `_25._tcp.mail.example.com` |

### DNS Cutover Checklist (Migration)

1. Lower MX TTL to 300 seconds at least 48 hours before cutover
2. Update MX records to point to new platform
3. Update Autodiscover CNAME/SRV for new platform
4. Update SPF to include new platform, remove old
5. Enable DKIM on new platform, verify DNS records
6. Run incremental sync after MX change to capture stragglers
7. Wait 72 hours before removing old platform references
8. Restore MX TTL to normal (3600 seconds)

## Migration Planning Framework

### Phase 1: Assessment (2-4 weeks)

- Inventory all mailboxes: count, sizes, types (user, shared, resource, linked)
- Identify special mailboxes: journaling targets, public folders, room lists
- Document current mail flow: connectors, transport rules, relay hosts, SEG
- Catalog DNS records: MX, SPF, DKIM, DMARC, Autodiscover for all domains
- Assess compliance requirements: retention, legal holds, journaling, archiving
- Identify integration points: line-of-business apps sending SMTP, scanners, printers

### Phase 2: Design (1-2 weeks)

- Select migration method (cutover, hybrid, IMAP, third-party tool)
- Design identity sync (Entra Connect, GCDS, SCIM)
- Plan coexistence architecture (split domain routing, shared namespace)
- Design DNS cutover sequence
- Plan pilot group (50-100 users representing all departments)
- Create rollback plan

### Phase 3: Pilot (1-2 weeks)

- Migrate pilot group
- Validate mail flow in both directions
- Verify calendar sharing, free/busy, resource booking
- Test client connectivity (Outlook, mobile, web)
- Validate compliance (retention, hold, journaling)
- Collect user feedback

### Phase 4: Production Migration (varies)

- Migrate in batches of 200-500 users
- Validate each batch before starting next
- Monitor migration dashboard for failures
- Address per-user errors (bad items, large items, permissions)
- Communicate to each batch before and after migration

### Phase 5: Cutover and Cleanup (1-2 weeks)

- Cut DNS (MX, Autodiscover, SPF)
- Run final incremental sync
- Decommission source (after 30-day safety window)
- Remove migration endpoints and batches
- Update documentation and runbooks

## Cross-Plugin References

| Topic | Skill | When |
|---|---|---|
| Email security (SPF/DKIM/DMARC), Proofpoint/Mimecast/Defender-O365 filtering | `email-security` skill (`security` plugin) | Authentication configuration, phishing defense, BEC prevention, SEG filtering policy |
| DNS management | `dns` skill (`networking` plugin) | MX records, SPF flattening, DNSSEC for DANE |
| Active Directory / Entra ID identity depth | `ad-ds` / `entra-id` skill (`security` plugin) | Hybrid identity, Entra ID Connect, AD FS, Conditional Access policy internals |
| Windows Server | `windows-server` skill (`os` plugin) | Exchange Server OS requirements, IIS for Autodiscover |
| Linux administration | `rhel` / `ubuntu` / `debian` skill (`os` plugin) | Postfix host OS management, certificate renewal, general Linux admin |
| Network / firewall | `overview` skill (`networking` plugin) | SMTP port rules, relay configuration, split-horizon DNS |

## Subcategory Routing

| Request Pattern | Skill |
|---|---|
| **Exchange Server** | |
| Exchange 2019, Exchange SE, DAG, mailbox database, transport rules, EAC (on-prem), hybrid, HCW, Edge Transport, Exchange migration to cloud | `exchange` |
| **Microsoft 365** | |
| M365 admin, tenant setup, licensing, Entra ID, Conditional Access, Purview compliance, DLP, sensitivity labels, eDiscovery, Teams admin, SharePoint admin, Intune | `m365` |
| **Google Workspace** | |
| Google Admin Console, Gmail admin, Google Vault, GCDS, GAM, Google Drive admin, Workspace licensing, Google Meet admin, Context-Aware Access | `google-workspace` |
| **Postfix** | |
| Postfix configuration, main.cf, master.cf, TLS setup, SASL, milters, OpenDKIM, postscreen, queue management, virtual domains, Dovecot integration | `postfix` |
| **Email Security** | |
| SPF, DKIM, DMARC, BIMI, phishing, BEC, Defender for Office 365, Proofpoint, Mimecast, SEG, email authentication | `email-security` skill (`security` plugin) |

## Anti-Patterns

1. **"Open relay because it's easier"** -- Misconfigured SMTP relay (no auth, no relay restrictions) is the fastest path to blacklisting. Every MTA must enforce `reject_unauth_destination` or equivalent. Test with external relay checks before going live.
2. **"SPF is enough"** -- SPF alone does not prevent spoofing of the visible From header. DKIM + DMARC are required. SPF without DMARC is security theater.
3. **"We'll figure out compliance later"** -- Retention policies, legal hold, and journaling must be configured before the first production message. Retroactive compliance is expensive and legally risky.
4. **"Big bang migration"** -- Moving all mailboxes in a single weekend. Batch migrations with validation gates, user communication, and rollback plans reduce risk. Pilot groups of 50-100 users first.
5. **"DNS TTL doesn't matter"** -- Changing MX records with a 24-hour TTL means 24 hours of split delivery. Lower TTL to 300 seconds at least 48 hours before any DNS cutover.
6. **"Self-signed certs are fine for SMTP"** -- Self-signed certificates break MTA-STS, cause TLS verification failures with major providers (Gmail, M365), and prevent DANE deployment. Use a public CA (Let's Encrypt is free).
7. **"One admin account for everything"** -- Shared admin credentials with no MFA and no PIM. Use role-based access, per-admin accounts, MFA everywhere, and Just-In-Time privilege elevation.

## Reference Files

- `references/concepts.md` -- Email protocols (SMTP, IMAP, POP3, JMAP), DNS records for email (MX, SPF, DKIM, DMARC, DANE, MTA-STS, BIMI, TLS-RPT), mail flow architecture (MTA/MDA/MUA/MSA), content filtering pipeline, compliance frameworks, and retention requirements. **Load when:** architecture questions, DNS configuration, protocol questions, compliance planning.
- `references/paradigm-onprem.md` -- On-premises mail patterns: Exchange Server architecture (DAG, transport pipeline, Edge Transport), Postfix as relay/gateway, hybrid deployment models, on-prem compliance tooling. **Load when:** on-premises design, Exchange Server questions, Postfix relay questions, hybrid architecture.
- `references/paradigm-cloud.md` -- Cloud mail patterns: Exchange Online tenant model, M365 service architecture, Google Workspace domain model, cloud identity integration, cloud compliance tooling, multi-geo and data residency. **Load when:** cloud platform comparison, cloud migration planning, SaaS architecture decisions.