Email Security Fundamentals: Protect Your Primary Business Channel

Email is how you talk to your customers, vendors, and employees. It's also how attackers reach them—pretending to be you.

The question isn't whether someone will try to send fake emails "from" your domain. They're already doing it. The question is whether those emails reach their targets.

The Core Problem

Without email authentication, anyone can send an email that appears to come from ceo@yourcompany.com. This isn't a hypothetical. Here's what it looks like in practice:

Fake Invoice Scenario Attacker sends an email to your customer that looks exactly like it came from accounting@yourcompany.com. Subject: "Invoice #4521 due today." Body: "Please find attached invoice. Payment details below." The payment goes to the attacker's account. Your customer paid the wrong person and expects the work done anyway.

Vendor Impersonation Scenario Attacker sends an email to your AP department that appears to come from support@yourbigvendor.com—your biggest vendor. "We've updated our banking information. Please use the new account for all future payments." Your employee updates the records. Every payment goes to the attacker.

CEO Fraud Scenario Attacker spoofs your CEO's email and sends to your office manager: "I'm in a meeting, need you to buy $2,000 in gift cards and send me the codes immediately. I'll explain later." It's embarrassing and it happens to small businesses constantly.

The Three Controls

SPF (Sender Policy Framework) SPF tells the internet which mail servers are allowed to send email for your domain.

Think of it like a guest list. When Microsoft 365 sends an email "from" you@yourcompany.com, it says: "I'm sending this from server 1.2.3.4, which is on your SPF list, so it's legitimate." Receiving mail servers check: "Is 1.2.3.4 on their guest list?" Yes? Email passes. No? Email fails.

If you don't have SPF, anyone can claim to be on the guest list.

DKIM (DomainKeys Identified Mail) DKIM adds a digital signature to your emails—like a wax seal on an envelope.

When you send an email through your email provider, it cryptographically signs it with a private key. Receiving servers use your public key (published in DNS) to verify: "Did this email actually come from your servers? Was it changed in transit?"

Without DKIM, attackers can not only fake who an email is from—they can modify the contents in transit without detection.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) DMARC tells receiving mail servers what to do with emails that fail SPF and DKIM checks.

It has three settings:

p=none — Do nothing. Just report failures to me. This is "monitoring mode."
p=quarantine — Mark failing emails as spam.
p=reject — Block failing emails entirely.

DMARC also tells receiving servers where to send you reports about what's happening with your domain—who's sending email "from" you, what's passing, what's failing.

What Can Go Wrong

"We listed only our mail system in SPF" You set up SPF and it looks clean. But you forgot: your CRM sends email "from" you. Your online form plugin sends email "from" you. Your accounting software sends email "from" you. Now legitimate emails from those services are failing SPF. Customers aren't getting invoices. Leads aren't getting follow-ups.

"We went straight to p=reject" You heard reject is the strongest setting. You set it immediately. A week later, you find out your newsletter tool—sending from a shared server—wasn't included in your SPF. 30% of your customer emails bounced. Some never came back.

"We set it and forgot it" Six months later, you switched email providers. Your old SPF record still points to servers that no longer send for you. Incoming emails fail authentication. Deliverability tanks.

"We don't know how to read DMARC reports" DMARC reports are XML files full of numbers. Most business owners ignore them. But those reports show you exactly who's trying to send email "from" your domain—including attackers.

What It Costs

Time investment:

Initial setup (SPF + DKIM + DMARC): 2-4 hours
Monitoring first month: 30 minutes weekly
Ongoing maintenance: 15 minutes quarterly

Financial cost: $0/year for most setups

DNS hosting (already have): $0
SPF and DKIM: Free, built into Microsoft 365 and Google Workspace
DMARC monitoring service (optional): $0-$50/month for services like DMARCly, OnDMARC, or MXToolbox Premium
Email authentication consultant (one-time): $500-$1,500 if your setup is complex

Hidden costs of getting it wrong:

Customer complaints about bounced emails
Time troubleshooting delivery issues
Lost business if customers think you're ignoring them

Minimum Viable Implementation

Week 1: Audit

List every service that sends email "from" your domain:
- Your main email system (Microsoft 365, Google Workspace, etc.)
- Any CRM or sales tools
- Your website contact form
- Your invoicing or accounting software
- Newsletter or marketing tools
- Password reset or notification systems
For each service, find its SPF requirement. Most will give you a string like include:spf.sender.net.
Document your current DNS records. Screenshot them.

Week 2: Implement SPF

Create your SPF record. It looks like:

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

Add it to your DNS as a TXT record at yourcompany.com.
Test it with MXToolbox's SPF checker.
Send test emails from each service. Check that they pass.

Week 3: Implement DKIM

Enable DKIM in your email provider. In Microsoft 365: Admin Centers > Exchange > Mail Flow > DKIM. In Google Workspace: Admin Console > Apps > Google Workspace > Gmail > Authenticate Email.
Add the DKIM record to your DNS. It's usually a CNAME record.
Test it. Most providers have built-in diagnostics.

Week 4: Implement DMARC

Create your initial DMARC record in DNS at _dmarc.yourcompany.com:
```
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com
```
Create the dmarc@yourcompany.com address to receive reports.
Review DMARC reports weekly for at least 4 weeks.
After monitoring, if no legitimate emails are failing, upgrade to p=quarantine.
After a few more weeks of monitoring, if nothing fails, upgrade to p=reject.

Vendor Questions (Copy/Paste)

"Does your service send email from our domain? If yes, what's the SPF entry we need to add?"
"Do you support DKIM signing? If yes, what's the CNAME record we need to add?"
"We'd like to check our DMARC reports monthly. Can you show us a sample report and explain what the numbers mean?"
"What happens if our email fails SPF or DKIM—does your service notify us?"
"We're setting up DMARC monitoring. What percentage of legitimate email from our domain should we expect to pass?"

When to Hire Help

DIY-friendly if:

Single email provider (Microsoft 365 or Google Workspace only)
No third-party services sending email from your domain
Under 50 employees
Basic DNS knowledge
Using a simple DNS interface (Cloudflare, Google Domains)

Get professional help if:

Multiple domains with different email configurations
Complex email routing (shared mailbox, multiple providers)
Previous email deliverability issues
Previous impersonation attempts targeting your domain
No one comfortable editing DNS records
Regulated industry with email security requirements

Warning signs:

Customers reporting fake emails "from" your domain
Bounced emails you can't explain
No one knows how to read DMARC reports
You've changed email providers in the last 6 months and haven't rechecked SPF