[NEW SKILL] email-security: domain authentication and mail transport posture review

[fok3jm]

Bounty type

New skill proposal / implementation candidate.

Please tag this with new-skill / bounty if maintainers consider it eligible.

Proposed skill

email-security: review domain email authentication, anti-spoofing, and mail transport posture for organizations using Microsoft 365, Google Workspace, self-hosted MTAs, marketing platforms, and third-party SaaS senders.

Why this skill is needed

The repository has useful adjacent coverage, but no dedicated email security posture skill:

• dns-security covers general DNS hygiene and phishing-domain blocking, but not mail-authentication policy correctness.
• ir-playbook and containment cover phishing/BEC response, but not preventive domain controls.
• iam-review covers phishing-resistant MFA, but not sender-domain spoofing resistance.
• pci-dss-review mentions phishing protection requirements, but not a review workflow for SPF, DKIM, DMARC, MTA-STS, TLS-RPT, ARC, or sender inventory.

Email authentication failures can let attackers spoof a trusted domain, break legitimate mail through misaligned third-party senders, or give a false sense of enforcement when DMARC reporting is unmonitored or outdated. This deserves a first-class review workflow.

Scope

The skill should guide reviewers through evidence collection and findings for:

1. Sender inventory

   • Primary mail platform: Microsoft 365, Google Workspace, self-hosted MTA, or managed provider.
   • Third-party senders: CRM, marketing, helpdesk, billing, HR, monitoring, ticketing, e-signature, and transactional email.
   • Domains and subdomains that send mail vs. domains that should never send mail.

2. SPF posture

   • SPF record exists for sending domains.
   • SPF does not exceed DNS lookup limits.
   • SPF includes only authorized senders.
   • Non-sending domains publish an explicit no-send posture where appropriate.
   • SPF pass alone is not treated as sufficient if the RFC5322 From domain is not aligned for DMARC.

3. DKIM posture

   • DKIM signing enabled for each platform/sender.
   • Selectors are known, rotated, and not stale.
   • Keys use acceptable strength and are scoped to the right sender.
   • Third-party senders sign with aligned domains where possible instead of provider-owned domains only.

4. DMARC posture

   • DMARC record exists at _dmarc.<domain>.
   • Policy, alignment, subdomain behavior, and reporting are reviewed against current DMARC standards.
   • Aggregate reporting is routed to an actively monitored mailbox or reporting service.
   • Reporting authorization is verified when reports are sent to a different domain.
   • Enforcement is staged based on evidence, avoiding both permanent p=none and unsafe enforcement that breaks legitimate mail.
   • Review logic should be current with the May 2026 DMARC RFC split: RFC 9989 for core protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting.

5. Mail transport security

   • MTA-STS DNS record and HTTPS policy are present and valid where applicable.
   • TLS-RPT is configured and monitored.
   • MX hosts match the MTA-STS policy.
   • TLS policy changes are validated before enforcement.
   • DANE/TLSA is considered for DNSSEC-enabled mail environments where appropriate.

6. Provider and gateway edge cases

   • Microsoft 365 and Google Workspace authentication setup is verified through headers and admin settings, not DNS alone.
   • Inbound gateways do not accidentally bypass authentication controls for spoofed mail.
   • Mailing lists, forwarding, CRM aliases, and calendar/invite senders are classified as known alignment edge cases instead of noisy false positives.

7. Reporting and monitoring

   • DMARC aggregate reports are parsed and reviewed.
   • TLS-RPT failures are triaged.
   • Authentication failures are linked to sender inventory, ticket owners, and remediation state.
   • Spoofing attempts and legitimate sender failures are separated.

8. Output safety

   • Reviewers should not publish sensitive customer domains, private report addresses, full DMARC aggregate report contents, or internal gateway topology unless necessary and approved.

Example vulnerable signals

example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:spf.protection.outlook.com include:_spf.salesforce.com ~all"
_dmarc.example.com. TXT "v=DMARC1; p=none"

Why this should be reviewed:

• Sender inventory may be unknown or stale.
• SPF may approach or exceed lookup limits depending on included records.
• DMARC is monitoring-only with no documented path to stronger policy.
• rua is missing, so nobody can prove which sources pass alignment.

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@vendor.example"

Why this should be reviewed:

• Enforcement may be correct, but cross-domain report authorization must be verified.
• The reviewer should validate legitimate third-party senders before approving strict policy.

MTA-STS TXT exists, but https://mta-sts.example.com/.well-known/mta-sts.txt is missing or lists old MX hosts.

Why this should be reviewed:

• Senders may enforce a stale transport policy and fail delivery, or the organization may believe MTA-STS is active when it is not.

Expected reviewer workflow

1. Inventory all mail-sending domains, subdomains, providers, and third-party platforms.
2. Query DNS for SPF, DKIM selectors, DMARC, MTA-STS, TLS-RPT, MX, and relevant DNSSEC/DANE records.
3. Inspect representative message headers from each sender to verify SPF, DKIM, DMARC, and alignment results.
4. Review DMARC aggregate reports and TLS-RPT reports for real sender coverage and failures.
5. Classify domains as sending, non-sending, parked, delegated, marketing, transactional, or internal-only.
6. Produce findings for missing records, stale/overbroad senders, broken alignment, unmonitored reports, unsafe enforcement, missing transport policy, and report-processing gaps.
7. Provide staged remediation with DNS examples and rollback considerations.

Acceptance criteria for the skill

A completed email-security skill should include:

• A SKILL.md with scope, prerequisites, evidence checklist, review workflow, common findings, and remediation guidance.
• Checks for SPF, DKIM, DMARC, DMARC reporting, MTA-STS, TLS-RPT, sender inventory, third-party sender alignment, non-sending domains, and mail gateway edge cases.
• Current references to DMARC RFC 9989 / RFC 9990 / RFC 9991 rather than relying only on obsolete RFC 7489.
• Provider-specific notes for Microsoft 365 and Google Workspace.
• False-positive guidance for forwarding, mailing lists, legitimate third-party senders, monitoring-only DMARC rollout phases, and domains that intentionally do not send mail.
• Example vulnerable and fixed DNS records.
• Output table for each domain: MX, SPF status, DKIM status, DMARC policy, alignment, reporting destination, MTA-STS, TLS-RPT, owner, confidence, and next action.
• Not Evaluable guidance for missing DNS access, unavailable headers, no report data, unknown third-party sender ownership, or provider-specific admin evidence not available.

References

• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), core protocol: https://www.rfc-editor.org/info/rfc9989/
• RFC 9990: DMARC Aggregate Reporting: https://www.rfc-editor.org/rfc/rfc9990.pdf
• RFC 9991: DMARC Failure Reporting: https://www.rfc-editor.org/info/rfc9991
• RFC 7208: Sender Policy Framework (SPF): https://www.rfc-editor.org/rfc/rfc7208
• RFC 6376: DomainKeys Identified Mail (DKIM): https://www.rfc-editor.org/rfc/rfc6376
• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS): https://www.rfc-editor.org/info/rfc8461/
• RFC 8460: SMTP TLS Reporting: https://www.rfc-editor.org/info/rfc8460
• CISA DMARC resource: https://www.cisa.gov/resources-tools/resources/domain-based-message-authentication-reporting-and-conformance-dmarc
• CISA BOD 18-01, Enhance Email and Web Security: https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security
• Google Workspace sender guidelines: https://support.google.com/mail/answer/81126?hl=en
• Google Workspace MTA-STS and TLS reporting: https://support.google.com/a/answer/9276512?hl=en
• Microsoft Defender for Office 365 email authentication overview: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about

Payout

If this is accepted as a bounty contribution, PayPal through Ko-fi is preferred:

https://ko-fi.com/xantarescodex2233gmailcom

[BryanGM12]

Implemented this in PR #971: #971

Validation included:

• git diff --check and git diff --cached --check
• index.yaml parsed with skill_count=46, and all indexed files exist
• required frontmatter check across skills and roles
• Markdown fence balance for the new skill and all six fixtures
• prohibited prompt-injection pattern scan over skills/network/email-security
• ASCII scan for the new skill subtree
• source URL checks returned HTTP 200 for RFC 9989/9990/9991, SPF, DKIM, MTA-STS, TLS-RPT, CISA, Google Workspace, and Microsoft references

[Neustradamus]

@kamalsrini: Why have you closed the @BryanGM12 PR?