Skip to main content
Passwork LogoPasswork LogoSecurity champion course

Email security

Your CEO gets an email from "[email protected]" asking them to wire $50,000 to a vendor. The email looks legitimate — it's from your domain. Except it isn't. An attacker spoofed your domain because you never set up email authentication. And now you're explaining to the board why someone wired money to a scammer.

This happens to small companies regularly. Email spoofing requires zero technical skill — free tools generate spoofed emails in seconds. Without SPF, DKIM, and DMARC, anyone can send email that appears to come from your domain.

This chapter fixes that. You'll configure email authentication so spoofed emails get rejected, and set up basic phishing defenses so your team doesn't fall for the attacks that do get through.

Why email is the #1 attack vector​

Email is how most attacks start. Not because email systems are insecure, but because humans are the target. A developer who would never run a suspicious binary will happily click a link in an email that looks like it's from GitHub.

The attacks are simple:

Spoofing — Sending email that appears to come from your domain. Used for CEO fraud, vendor impersonation, and credential phishing. Without authentication, anyone can send as you.

Phishing — Tricking people into clicking malicious links or entering credentials on fake login pages. The fake Google login that steals your password? Classic phishing.

Business Email Compromise (BEC) — Attackers compromise a real email account (through phishing or credential stuffing) and use it to request wire transfers, change payment details, or steal data. This isn't spoofing — it's actually your email being used against you.

Email authentication (SPF, DKIM, DMARC) stops spoofing. Employee training and technical controls reduce phishing success. Neither is complete without the other.

Understanding SPF, DKIM, and DMARC​

These three work together. Each solves a different problem.

SPF (Sender Policy Framework)​

SPF tells the world which servers are allowed to send email for your domain. It's a DNS TXT record that lists your authorized senders.

When someone receives email claiming to be from [email protected], their mail server checks your SPF record. If the sending server isn't on the list, the email fails SPF.

Example SPF record:

v=spf1 include:_spf.google.com include:sendgrid.net -all

This says: "Only Google's servers and SendGrid can send email for our domain. Reject everything else (-all)."

The problem SPF solves: Someone spinning up a random server and sending email as your domain.

What SPF doesn't solve: The "From" header can still be spoofed. SPF only checks the envelope sender (the Return-Path), not what shows up in email clients.

DKIM (DomainKeys Identified Mail)​

DKIM adds a cryptographic signature to your outgoing emails. Your mail server signs each message with a private key. You publish the public key in DNS. Recipients verify the signature matches.

What it looks like in DNS:

google._domainkey.yourcompany.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The problem DKIM solves: Verifying that an email hasn't been modified in transit and actually came from a server with your private key.

What DKIM doesn't solve: By itself, it doesn't tell recipients what to do with unsigned or failed emails.

DMARC (Domain-based Message Authentication, Reporting & Conformance)​

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also sends you reports about who's sending email as your domain.

Example DMARC record:

_dmarc.yourcompany.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

This says: "If an email fails both SPF and DKIM, reject it. Send aggregate reports to [email protected]."

The policy levels:

  • p=none — Monitor only, don't reject anything (use this first)
  • p=quarantine — Send failures to spam
  • p=reject — Reject failures outright (the goal)

What DMARC solves: Actually enforcing authentication and getting visibility into who's spoofing your domain.

Setting up email authentication​

This is the practical part. The order matters.

Step 1: audit your current state​

Before changing anything, check what you have:

# Check existing SPF record
dig +short TXT yourcompany.com | grep spf

# Check DKIM (Google Workspace example)
dig +short TXT google._domainkey.yourcompany.com

# Check DMARC
dig +short TXT _dmarc.yourcompany.com

Or use online tools:

Write down what you find. Many companies have partial configurations from years ago that nobody maintains.

Step 2: inventory your email senders​

List every service that sends email as your domain:

  • Primary email (Google Workspace, Microsoft 365)
  • Marketing email (Mailchimp, SendGrid, HubSpot)
  • Transactional email (your app's notification emails)
  • Support systems (Zendesk, Intercom)
  • HR/recruiting tools
  • CRM that sends email

Each of these needs to be in your SPF record or needs DKIM configured. Miss one, and legitimate email starts failing.

Step 3: configure SPF​

Add or update your SPF record in DNS:

For Google Workspace:

v=spf1 include:_spf.google.com ~all

For Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

With additional services (example):

v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ~all

Important notes:

  • Start with ~all (soft fail) instead of -all (hard fail). This quarantines failures rather than rejecting them. Switch to -all after you're sure everything's configured correctly.
  • SPF has a 10 DNS lookup limit. Each include: counts as one. If you have many senders, you might need to flatten or consolidate.
  • Only one SPF record per domain. If you have two, both break.

Step 4: configure DKIM​

DKIM setup varies by provider. Here's how to find the records you need:

Google Workspace:

  1. Admin Console → Apps → Google Workspace → Gmail → Authenticate Email
  2. Click "Generate New Record"
  3. Copy the TXT record value and add it to your DNS

Microsoft 365:

  1. Microsoft 365 Defender → Email & Collaboration → Policies → DKIM
  2. Enable DKIM for your domain
  3. Add the CNAME records they provide to your DNS

Third-party senders (SendGrid, Mailchimp, etc.): Each service has its own DKIM setup. Usually:

  1. Go to their domain authentication settings
  2. They'll give you DNS records to add
  3. Add them, then verify in their dashboard

Add DKIM for every service that sends email as your domain. This takes time but matters.

Step 5: configure DMARC (carefully)​

DMARC deployment should be gradual:

Week 1-2: Monitor mode

v=DMARC1; p=none; rua=mailto:[email protected]

This doesn't block anything — it just sends you reports about every email claiming to be from your domain. You'll see:

  • Your legitimate senders
  • Things you forgot about
  • Actual spoofing attempts

Week 3-4: Analyze reports

DMARC reports are XML files. They're unreadable raw. Use a free tool:

Look for:

  • Legitimate senders failing SPF/DKIM (fix their configuration)
  • Unknown senders (investigate — are they legitimate or spoofing?)
  • Clear spoofing attempts (attackers sending as your domain)

Week 5+: Start enforcement

Once you're confident legitimate email is passing:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Monitor for a few more weeks. If nothing breaks, move to full rejection:

v=DMARC1; p=reject; rua=mailto:[email protected]

Don't rush this. A misconfigured DMARC with p=reject will block your own email. The gradual approach takes 4-6 weeks but prevents self-inflicted outages.

Beyond the basics: MTA-STS, TLS-RPT, and BIMI​

Once you have SPF, DKIM, and DMARC working, there are three more standards worth knowing about.

MTA-STS (Mail Transfer Agent Strict Transport Security)​

MTA-STS forces other mail servers to use encrypted connections (TLS) when sending to your domain. Without it, an attacker could downgrade connections to plaintext and intercept emails.

Setup:

  1. Create a policy file at https://mta-sts.yourcompany.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.yourcompany.com
mx: *.mail.protection.outlook.com
max_age: 604800
  1. Add a DNS TXT record:
_mta-sts.yourcompany.com TXT "v=STSv1; id=20240115"

Change the id value whenever you update the policy.

TLS-RPT (TLS Reporting)​

TLS-RPT sends you reports when other servers have problems establishing TLS connections to your mail server. Useful for catching certificate issues.

DNS record:

_smtp._tls.yourcompany.com TXT "v=TLSRPTv1; rua=mailto:[email protected]"

BIMI (Brand Indicators for Message Identification)​

BIMI displays your company logo next to emails in supported clients (Gmail, Apple Mail, Yahoo). It requires DMARC at p=quarantine or p=reject.

Requirements:

  1. DMARC with enforcement
  2. Your logo in SVG format (specific requirements — use BIMI Generator)
  3. A VMC (Verified Mark Certificate) for Gmail — costs ~$1,500/year from DigiCert or Entrust
  4. DNS record pointing to your logo

DNS record:

default._bimi.yourcompany.com TXT "v=BIMI1; l=https://yourcompany.com/logo.svg"

BIMI is optional and has ongoing costs. Consider it once everything else is solid — it's more about brand than security, though it does help recipients trust your email is legitimate.

Solving the SPF lookup limit​

The 10 DNS lookup limit is real and annoying. Here's how to handle it.

Check your current count​

Use MXToolbox SPF Record Check — it shows your total lookups.

Each include: triggers lookups. Some services nest multiple includes. Google Workspace alone uses 4-5 lookups internally.

Option 1: remove unused senders​

Audit which services actually send email. That Mailchimp include from 2019 when you tried email marketing for a month? Remove it.

Option 2: use IP addresses directly​

Instead of include:sendgrid.net, you can list SendGrid's IP ranges directly:

v=spf1 ip4:167.89.0.0/16 ip4:208.117.48.0/20 include:_spf.google.com ~all

IP addresses don't count toward the lookup limit. But they're harder to maintain — IPs change.

Option 3: SPF flattening​

Flattening replaces include: statements with the actual IP addresses they resolve to. Tools that automate this:

The catch: flattened records need updating when providers change IPs. Manual flattening creates maintenance burden. Use a service if you go this route.

Option 4: split by subdomain​

Use different subdomains for different senders:

  • @yourcompany.com — Primary email only
  • @mail.yourcompany.com — Marketing tools
  • @notify.yourcompany.com — Application notifications

Each subdomain has its own SPF record with its own 10-lookup limit.

How to read email headers​

When investigating phishing or delivery issues, email headers tell the story. Here's what to look for.

Finding headers​

Gmail: Open email → Three dots → "Show original" Outlook: Open email → File → Properties → "Internet headers" Apple Mail: View → Message → All Headers

Key headers to check​

Authentication-Results — Shows SPF, DKIM, DMARC pass/fail:

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender);
       dmarc=pass (p=REJECT sp=REJECT) header.from=company.com

Received — Chain of servers the email passed through. Read bottom-to-top (oldest first):

Received: from mail.attacker.com (suspicious-ip.com [192.168.1.1])
        by your-server.com with SMTP
        for <[email protected]>;
        Thu, 15 Jan 2024 10:30:00 -0500

From vs Return-Path — The From: header is what users see. Return-Path: is what SPF checks. If they don't match, investigate:

From: [email protected]
Return-Path: [email protected]

This is classic spoofing — the display name fakes your domain, but the actual sender is different.

Tools for header analysis​

Lookalike domain protection​

SPF/DKIM/DMARC protect your domain. But attackers register similar domains:

  • yourcompany.co (different TLD)
  • yourcornpany.com (rn looks like m)
  • yourcompany-support.com (added word)
  • yourc0mpany.com (letter substitution)

Defensive registration​

Register obvious variations of your domain, especially:

  • Common TLDs (.co, .io, .net, .org)
  • Typos of your name
  • Your name with common suffixes (-app, -mail, -support)

This costs money but prevents easy impersonation.

Monitoring for lookalikes​

Tools that scan for newly registered similar domains:

Free:

  • dnstwist — Open source, generates permutations and checks which are registered
  • URLCrazy — Similar, generates typosquatting domains
# Run dnstwist
dnstwist --registered yourcompany.com

Commercial:

  • PhishLabs — Domain monitoring plus takedown services
  • Bolster — AI-based phishing detection
  • Red Points — Brand protection including domains

What to do when you find one​

  1. Check if it's hosting content (email, website)
  2. If it's clearly impersonating you, file abuse complaint with the registrar
  3. For active phishing, report to Google Safe Browsing and browser vendors
  4. Consider legal takedown for egregious cases

Email security gateways​

For companies wanting more than basic protection, email security gateways add layers of filtering, sandboxing, and threat detection.

Cloud-based options​

Enterprise:

Mid-market:

SMB-friendly:

When you need one​

Consider a gateway when:

  • You're getting significant phishing despite DMARC
  • You need advanced threat protection (sandboxing, URL rewriting)
  • Compliance requires email archiving or encryption
  • You want centralized policy across multiple domains

For most small companies, native Google/Microsoft security plus proper DMARC is enough. Gateways add complexity and cost.

BEC protection: financial verification procedures​

Business Email Compromise costs companies more than any other cyber attack type. Technical controls help, but process controls are essential for financial transactions.

The verification policy​

Write this down and make it official:

For wire transfers and payment changes:

  1. Any request to change payment details must be verified by phone
  2. Use a known phone number — not one from the email requesting the change
  3. Two people must approve transfers over $X (set your threshold)
  4. New vendors require verification before first payment

For sensitive data requests:

  1. Requests for employee data (W-2s, SSNs, etc.) must be verified in person or by phone
  2. Never send sensitive data via email — use encrypted file sharing

The callback procedure​

When you get a wire transfer request:

  1. Do not reply to the email
  2. Look up the sender's phone number independently (company directory, previous records)
  3. Call them directly
  4. Confirm the request, amount, and account details
  5. Document the verification

This takes 5 minutes and prevents six-figure losses.

Train finance specifically​

Your finance team is the primary BEC target. Give them specific training:

  • Real examples of BEC emails (request fake ones from KnowBe4 or similar)
  • Practice the verification procedure
  • Permission to delay suspicious requests ("I need to verify this, I'll process it after a callback")
  • Direct line to IT/security for suspicious emails

What to do if you're being spoofed​

You set up DMARC reports and discover someone is actively spoofing your domain. Now what?

Immediate actions​

  1. Check your DMARC enforcement level — If you're at p=none, spoofed emails are being delivered. Move to p=quarantine or p=reject as fast as safely possible.

  2. Alert your customers/partners — If attackers are spoofing you to your contacts, warn them. A brief email: "We've detected fraudulent emails claiming to be from our domain. We're addressing it. Please verify unexpected requests through official channels."

  3. Document the spoofing — Save DMARC reports, email headers, and any samples. You might need these for legal action or law enforcement.

Trace the source​

DMARC reports show the IP addresses sending spoofed email. You can:

  • Look up the IP's owner (who's hosting the attacker's server)
  • File abuse complaints with the hosting provider
  • Report to Spamhaus if it's a significant spam source

Report phishing campaigns​

If the spoofing is part of a phishing campaign:

Long-term fixes​

  1. Complete DMARC enforcement (p=reject)
  2. Subdomain policy (sp=reject)
  3. Register lookalike domains defensively
  4. Monitor DMARC reports ongoing

Phishing defense: the human layer​

Technical controls stop spoofing. But attackers can still:

  • Use lookalike domains (yourcompany-support.com instead of yourcompany.com)
  • Compromise a real account and send from it
  • Send from their own domain with convincing content

The human layer matters.

Training that actually works​

Most security awareness training is useless. Employees click through slides, pass a quiz, and forget everything. Here's what actually works:

Show real examples

Collect real phishing emails that targeted your company (or similar companies). Show the team:

  • What made them look legitimate
  • What the red flags were
  • What would have happened if someone clicked

Real examples stick better than hypothetical ones.

Run phishing simulations

Send fake phishing emails to your team. Track who clicks. This isn't about punishing people — it's about:

  • Measuring your baseline risk
  • Giving people practice spotting phish in a safe environment
  • Identifying who needs more training

Free/cheap tools:

Commercial (easier to use):

Run simulations quarterly. Keep them realistic — don't make them obvious. The goal is training, not tricking.

Teach the "when in doubt" process

Give people a clear action when they're unsure:

  1. Don't click anything
  2. Forward the email to [email protected] (or your designated address)
  3. If it's urgent (like a wire transfer request), verify through a separate channel — call the person directly using a known number, not the one in the email

This needs to be easy. If reporting is complicated, people won't do it.

Technical anti-phishing controls​

Beyond SPF/DKIM/DMARC:

External email warnings

Configure your email provider to tag emails from outside your organization:

  • Google Workspace: Admin → Apps → Gmail → Safety → Enable external recipient warning
  • Microsoft 365: Mail flow rules → Add "[EXTERNAL]" prefix to subject

This reminds people to be cautious when an email claims to be from a coworker but is actually from outside.

Link and attachment scanning

Both Google Workspace and Microsoft 365 have built-in scanning:

  • Google: Security Sandbox, Safe Browsing
  • Microsoft: Safe Attachments, Safe Links

Enable these. They're not perfect, but they catch known malware and phishing domains.

Report phishing button

Make it one-click to report suspicious emails:

  • Google Workspace: Enable "Report phishing" in Gmail settings
  • Microsoft 365: Enable "Report Message" add-in

Reports should go to someone who actually reviews them.

Common mistakes to avoid​

Testing with your own domain

When testing your SPF/DKIM/DMARC setup, don't just send to yourself. Your mail server might treat internal email differently. Send to a personal Gmail or use Mail Tester for accurate results.

Forgetting about subdomains

Your DMARC policy might not apply to subdomains by default. Attackers can spoof billing.yourcompany.com even if yourcompany.com is protected. Add:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

The sp=reject applies the policy to all subdomains.

Breaking legitimate senders

Moving to p=reject too fast breaks email. Common casualties:

  • Old marketing tools nobody remembers
  • The vendor your finance team uses to send invoices
  • The CEO's personal mail client forwarding through your domain

Monitor in p=none mode until you're sure you've found everything.

SPF lookup limit

SPF allows max 10 DNS lookups. Each include: typically counts as one (some services nest includes). If you exceed 10, SPF breaks silently.

Check your count:

# Online tools like MXToolbox show this
# Or manually trace each include

If you're over, you need to flatten your SPF record or remove unused senders.

Executive and high-risk user protection​

C-level executives and finance teams are prime targets. They have authority to approve transactions and access to sensitive information. Extra protection is warranted.

Identify high-risk users​

Create a list of accounts that need additional monitoring:

  • CEO, CFO, COO and other executives
  • Finance team (anyone who can initiate payments)
  • HR (access to employee data)
  • IT admins (elevated privileges)
  • Anyone with access to customer data or trade secrets

Enhanced controls for executives​

Dedicated phishing simulation

Run executive-specific simulations with more sophisticated attacks. CEO fraud often uses urgency and authority — test for that.

Stricter MFA

Require hardware keys (YubiKey) for executives, not just TOTP. Hardware keys are resistant to phishing in ways that SMS and authenticator apps aren't.

Out-of-band verification

For executives, any unusual request should trigger a phone call. "The CEO emailed asking for wire transfer" → Call the CEO's known number before acting.

VIP impersonation alerts

Some email security tools can flag emails that impersonate your executives by name. Google Workspace and Microsoft 365 have these features in advanced tiers.

Limited email exposure

Consider using different email addresses:

Reduces targeted spear-phishing when attackers can't easily find executive emails.

Email account compromise: incident response​

When an email account gets compromised, speed matters. Here's the playbook.

Signs of compromise​

  • Password changed unexpectedly
  • Login from unusual location/device (check login history)
  • Contacts receiving phishing from the account
  • Unknown forwarding rules set up
  • Sent folder contains emails user didn't send
  • User locked out of their account

Immediate response (first 30 minutes)​

  1. Reset the password — Immediately, using admin console if user is locked out
  2. Terminate all sessions — Force logout on all devices
  3. Disable the account temporarily if the compromise is severe
  4. Check and remove forwarding rules — Attackers set these for persistence
  5. Check and remove mailbox rules — Look for rules that delete, forward, or hide emails
  6. Review OAuth/app connections — Revoke any suspicious third-party app access
  7. Enable MFA if not already enabled (this should prevent the attack in the first place)

Investigation (next few hours)​

  1. Check login history — Where did the attacker log in from? When did it start?
  2. Review sent emails — What did the attacker send while in control?
  3. Check if contacts were phished — Did the attacker use the account to attack others?
  4. Identify the entry point — How was the password compromised? Phishing? Credential stuffing? Malware?
  5. Check for data access — What emails/files did the attacker view or download?

Notification (as needed)​

  • Internal: Alert affected colleagues if phishing was sent from the account
  • External: Notify partners/customers if they received fraudulent emails
  • Legal: If sensitive data was accessed, you may have breach notification obligations

Post-incident​

  1. User training — How was the user compromised? Address that specifically
  2. Review MFA coverage — Was MFA enabled? If yes, how was it bypassed?
  3. Document the incident — For future reference and pattern recognition
  4. Update detection — Can you catch this faster next time? Add alerts for the IOCs observed

OAuth and app passwords: hidden email access​

Email compromise isn't always about stealing passwords. OAuth grants and app passwords provide persistent access that survives password changes.

The OAuth threat​

When users click "Sign in with Google" or "Connect your email," they grant OAuth tokens. These tokens let third-party apps read email, sometimes indefinitely.

Attackers use this:

  1. Send phishing email with "Review this document"
  2. User clicks and lands on fake OAuth consent screen
  3. User grants access to "Document Viewer" app
  4. App is actually attacker-controlled, now has email access
  5. Changing password doesn't revoke the OAuth token

Audit OAuth grants​

Google Workspace: Admin Console → Security → API Controls → App Access Control

Review connected apps. Revoke anything suspicious or unused.

Microsoft 365: Azure AD → Enterprise Applications → User consent settings

Check what apps have been granted access.

App passwords​

App passwords are alternative credentials that bypass MFA. Users create them for mail clients or apps that don't support modern auth.

The problem: App passwords are just as good as the real password, with no MFA.

Disable app passwords if your apps support OAuth. Most modern clients do. Check:

  • Google Workspace: Admin → Security → Less secure apps → Disable
  • Microsoft 365: Azure AD → Authentication methods → Disable app passwords

Mobile email security​

Your security is only as good as the least secure device accessing email.

Basic mobile controls​

Require device encryption

  • iOS: Encrypted by default with passcode
  • Android: Enable in Settings → Security → Encryption

Require screen lock Both Google Workspace and Microsoft 365 can enforce minimum PIN length and biometrics.

Remote wipe capability Enable the ability to wipe company data if a device is lost:

  • Google Workspace: Admin Console → Devices → Mobile
  • Microsoft 365: Endpoint Manager / Intune

Mobile app choices​

For sensitive environments, consider:

  • Official apps only — Gmail app, Outlook app (not random third-party mail apps)
  • Managed apps — Apps that IT can configure and wipe separately from personal data
  • Container apps — Keep work email in a separate, encrypted container

MDM consideration​

Mobile Device Management (MDM) provides central control but adds complexity. For small companies:

  • Google Workspace has built-in basic MDM (free with Workspace)
  • Microsoft 365 has Intune (included in some plans)
  • Consider MDM if you have compliance requirements or high-risk data

For most small companies, requiring MFA and enabling remote wipe is enough without full MDM.

Common phishing patterns​

Knowing what attacks look like helps you spot them. These patterns hit small companies regularly.

The fake invoice​

"Your invoice is ready for payment" with an attachment or link. The attachment is malware or the link leads to credential phishing. Common senders: "DocuSign," "QuickBooks," "your bank."

Red flags: Unexpected invoice, sender domain doesn't match company, urgency.

The shared document​

"[Colleague name] shared a document with you" from Google Drive, Dropbox, or OneDrive. Link goes to fake login page.

Red flags: You didn't expect a shared document, the link domain is wrong (drive.google.com.malicious.com).

The account suspension​

"Your account will be suspended unless you verify" from IT, Microsoft, Google, or the bank. Creates urgency to click without thinking.

Red flags: Generic greeting, threats, urgency, sender domain doesn't match.

The CEO request​

"I need you to handle something urgently" apparently from the CEO or CFO. Usually requests wire transfer, gift cards, or sensitive data. Often claims to be traveling or in a meeting (can't be reached by phone).

Red flags: Unusual request, urgency, asks to keep it confidential, different reply-to address.

The package delivery​

"Your package could not be delivered" from UPS, FedEx, DHL. Link leads to credential phishing or malware.

Red flags: Unexpected delivery notification, wrong tracking format, suspicious link.

The password expiry​

"Your password will expire in 24 hours" from IT. Link leads to fake company login page that harvests credentials.

Red flags: IT probably doesn't email about password expiry this way, link goes to wrong domain.

When email isn't secure enough​

Email was designed in an era of trust. For truly sensitive communications, consider alternatives.

End-to-end encrypted messaging​

For sensitive internal discussions:

  • Signal — Gold standard for encrypted messaging
  • Wire — Business-focused, end-to-end encrypted
  • Element (Matrix) — Self-hostable, open source

Secure file sharing​

Don't email sensitive documents. Use:

  • Password-protected links with expiration
  • Platforms with access controls and audit logs
  • Your password manager for sharing credentials (Passwork, etc.)

When to use alternatives​

Consider non-email channels for:

  • Sharing passwords or API keys (use password manager)
  • Discussing M&A, legal, or HR matters (encrypted messaging)
  • Sending contracts or legal documents (secure portals with audit trails)
  • Communicating during a security incident (assume email is compromised)

Tools and resources​

Testing and validation​

DMARC reporting​

Phishing simulation​

Free/Open source:

Commercial:

Domain monitoring​

Practical tricks​

A few things that make email security easier.

The quarterly DMARC review​

Set a calendar reminder every 3 months to:

  1. Check your DMARC reports for new unauthorized senders
  2. Verify all legitimate senders still work
  3. Look for failed DKIM (certificate expiry, service changes)
  4. Review your SPF record for services you no longer use

Takes 30 minutes. Catches drift before it causes problems.

Test before DNS changes​

Before updating SPF/DKIM/DMARC in production:

  1. Test the new record syntax with MXToolbox
  2. Set a short TTL (300 seconds) before making changes
  3. Make the change
  4. Send test emails to Mail Tester immediately
  5. If something breaks, the short TTL means fast rollback
  6. Once verified, increase TTL back to normal (3600+)

The phishing sample collection​

Create a shared folder (Notion page, Google Doc, whatever) where anyone can add phishing attempts they receive. Over time you build:

  • A library of real examples for training
  • Patterns in what attackers target at your company
  • Evidence if you ever need it for law enforcement

Make it easy to add samples — a simple form or email forward works.

Forward vs redirect for reporting​

When users report phishing, they should forward as attachment (not regular forward). Regular forwarding can strip headers you need for analysis.

Gmail: Select email → Three dots → "Forward as attachment" Outlook: Select email → Home → More → "Forward as Attachment"

Train users on this or set up a system that handles it automatically.

The "known sender" list​

For high-risk transactions (wire transfers, sensitive data), maintain a verified contact list:

  • Name
  • Verified phone number (not from email)
  • Verified email domain
  • Last verification date

When requests come in, check against this list. If the sender isn't on it or something seems off, verify before acting.

Email forwarding audit​

Email forwarding rules are a favorite persistence mechanism. Attackers compromise an account, set up forwarding to their external email, then get copies of everything even after you change the password.

Check regularly:

  • Google Workspace: Admin Console → Reports → Audit → Gmail → Filter by "Email forwarding enabled"
  • Microsoft 365: Security & Compliance → Threat management → Mail flow → Auto-forwarded messages

Remove any forwarding you don't recognize. Also check individual mailbox rules (attackers create rules that forward specific emails).

Quick wins checklist​

Things you can do today:

  • Check your current SPF, DKIM, DMARC records
  • Inventory all services that send email as your domain
  • Enable external email tagging in your email provider
  • Enable link/attachment scanning
  • Set up a DMARC record in p=none mode to start collecting data
  • Enable the "Report phishing" button for users

Things that take a few weeks:

  • Configure DKIM for all senders
  • Fix SPF to include all legitimate senders
  • Analyze DMARC reports and fix issues
  • Move DMARC to p=quarantine then p=reject
  • Run first phishing simulation

Workshop: secure your email​

Block 2-3 hours for initial setup, then ongoing monitoring.

Part 1: Audit and SPF (45 minutes)

  1. Check current records with MXToolbox
  2. List all services that send email as your domain
  3. Build or update your SPF record with all senders
  4. Add/update the DNS record
  5. Verify with a test email to Mail Tester

Part 2: DKIM setup (60 minutes)

  1. Enable DKIM in your primary email provider
  2. Add the DNS records
  3. Verify DKIM is signing emails (check headers of sent email)
  4. Repeat for each third-party sender (this takes time)

Part 3: DMARC deployment (30 minutes initial, then ongoing)

  1. Create DMARC record with p=none
  2. Set up a free DMARC report analyzer
  3. Add the DNS record
  4. Wait for reports (usually 24-48 hours)
  5. Review weekly, fix issues, gradually increase enforcement

Part 4: Phishing simulation setup (45 minutes)

  1. Install Gophish or sign up for a commercial tool
  2. Create a realistic phishing template
  3. Import employee email list
  4. Schedule the simulation for a few days out
  5. Review results and plan follow-up training

Deliverables:

  • SPF, DKIM, DMARC all configured
  • DMARC monitoring set up
  • First phishing simulation scheduled
  • External email tagging enabled
  • Reporting process documented

Talking to leadership​

If someone asks why you spent time on this:

"I set up email authentication so people can't send fake emails that look like they're from our company. Before this, anyone could send email as our CEO and ask for wire transfers — it's a common attack. Now those emails get blocked. I also ran a phishing test and trained the team on what to look for. Phishing is how most breaches start, and we've reduced that risk."

Short version: "I made it so attackers can't impersonate our email, and I trained the team to spot phishing."

Self-check: did you actually do it?​

Before moving on, verify you've completed these items.

Email authentication​

  • SPF record configured with all legitimate senders
  • SPF passes validation (no lookup limit issues)
  • DKIM enabled for primary email provider
  • DKIM configured for major third-party senders
  • DMARC record published (at least p=none)
  • DMARC report analyzer set up
  • Tested by sending to Mail Tester or similar

Anti-phishing controls​

  • External email warning enabled
  • Link/attachment scanning enabled
  • "Report phishing" button available to users
  • Process for handling reported phishing documented

Training​

  • First phishing simulation scheduled or completed
  • "When in doubt" process communicated to team
  • Real phishing examples collected for training

If you can check off at least 10 of these 14 items, you're ready to move on.

What's next​

Technical controls handle spoofing. But no filter stops a well-crafted phishing email from getting through — that's a people problem.

Next chapter: email hygiene and phishing awareness training — building the human side of email security.

© 2017–2026 Passwork
Company
About usPrivacy policyISO 27001 certificateRelease notesRoadmapBlog
Browser extension
Google ChromeMozilla FirefoxMicrosoft EdgeApple Safari
Mobile application
App StoreGoogle Play
For business
TeamsSmall businessBusiness and corporatesEnterpriseOn-premise solutionPassword sharing toolSecret management
Help
User manualTechnical documentationHelp center