Tools Learn Login Sign up
Home / Learn / Email Security Basics

Email Security Basics: Protecting Your Domain from Spoofing

Every day, billions of emails are sent pretending to be from domains they don't actually belong to. This is called "email spoofing" and it's the foundation of most phishing attacks. Let's learn how three simple DNS records can protect your domain.

The Problem: Anyone Can Pretend to Be You

Email was designed in a more trusting time. By default, anyone can send an email claiming to be from your domain - there's no built-in verification. This is like being able to write any return address on a physical letter.

Real-World Impact: Without email authentication, criminals can send emails that appear to come from your CEO asking employees to wire money, or from your brand asking customers to "verify" their credit cards on a fake website.

That open door fuels three of the most damaging email attacks:

Phishing

Fake emails lure recipients to bogus login pages to steal passwords and card numbers.

Spoofing

Attackers forge your domain in the "From" address so the mail looks genuinely yours.

BEC

Business Email Compromise impersonates executives to trick staff into wiring money.

It is no longer optional. Since 1 February 2024, Google (Gmail) and Yahoo require any sender pushing more than 5,000 messages per day to their users to have valid SPF, DKIM, a published DMARC policy with aligned identifiers, one-click List-Unsubscribe (RFC 8058), and a spam-complaint rate below 0.3%. Microsoft Outlook.com began enforcing the same requirements on 5 May 2025. Senders without these in place get bulk-rejected or sent to spam by default.

The Solution: Email Authentication

Three technologies work together to verify that emails actually come from who they claim. Each answers a different question:

SPF

"Who is allowed to send?"

  • A DNS list of approved mail servers
  • Checked against the sending IP
  • Breaks on forwarding
DKIM

"Is this email authentic?"

  • A cryptographic signature on each message
  • Proves nothing was tampered with
  • Survives forwarding
DMARC

"What to do with failures?"

  • Ties SPF + DKIM together with alignment
  • Sets the deliver / quarantine / reject policy
  • Sends you reports on abuse

SPF: The Sender's Guest List

SPF (Sender Policy Framework) is like a guest list for your domain's email. It's a DNS record that lists which mail servers are authorized to send email on behalf of your domain.

How SPF Works

1

Publish your list

You add a list of approved mail servers to your domain's DNS as an SPF record.

2

Receiver looks it up

When someone receives an email "from" your domain, their server checks your SPF record.

3

Compare the sender

If the sending server isn't on your list, the email is flagged as suspicious.

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

This example SPF record says: "Only Google and SendGrid servers can send email for us. Reject everything else."

The "-all" vs "~all" Difference:
  • -all (hard fail) - Reject unauthorized emails outright
  • ~all (soft fail) - Mark as suspicious but deliver anyway
Start with ~all while testing, then switch to -all for full protection.

DKIM: The Digital Signature

DKIM (DomainKeys Identified Mail) adds a digital signature to your emails. It's like a wax seal on a letter - it proves the email hasn't been tampered with and really came from your domain.

How DKIM Works

  1. Your mail server has a private key (kept secret) and a public key (published in DNS)
  2. When sending an email, your server creates a unique signature using the private key
  3. The receiving server uses your public key to verify the signature matches
  4. If the email was altered in transit, the signature won't match
Why DKIM Matters: Unlike SPF, DKIM survives email forwarding. If someone forwards your email, the signature stays valid because it's part of the email itself.

DMARC: The Policy Enforcer

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication, and sends you reports about who's trying to use your domain.

DMARC Policies

Policy What Happens Use Case
p=none Deliver normally, just report Monitoring phase - see who sends as you
p=quarantine Send to spam folder Intermediate - catch suspicious emails
p=reject Don't deliver at all Full protection - block fake emails 
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100

This DMARC record says: "Reject any email that fails authentication, and send me daily reports about it."

How They Work Together

When someone receives an email claiming to be from your domain, their mail server runs these checks in order:

1

SPF check

Is the sending server on your domain's approved list?

2

DKIM check

Does the message's digital signature verify against your published public key?

3

DMARC check

Does SPF or DKIM pass and align with the visible "From" address?

4

Action

Based on your DMARC policy, the receiver delivers, quarantines, or rejects the email.

Important: DMARC requires "alignment" - the domain in the From address must match the domain that passed SPF or DKIM. This prevents clever attacks that pass individual checks but still spoof you.

Getting Started: Implementation Order

Follow this recommended sequence:

  1. Set up SPF first - List all services that send email for your domain (email provider, marketing tools, support systems, etc.)
  2. Configure DKIM - Most email providers have a button to enable it. You'll add a DNS record they provide.
  3. Start DMARC with p=none - Monitor for a few weeks to see all legitimate sources of your email.
  4. Move to p=quarantine - Once you've verified all legitimate senders are passing.
  5. Finally, p=reject - Full protection once you're confident in your setup.

Common Mistakes to Avoid

Do
  • List every third-party sender — marketing tools, CRM systems and support desks all belong in your SPF record.
  • Stay under SPF's 10 DNS-lookup limit — too many include: statements will break the record.
  • Protect subdomains too — add policy for mail.yourdomain.com, not just the root domain.
Don't
  • Forget a sending service — anything left out of SPF will fail authentication.
  • Jump straight to p=reject — without monitoring on p=none first, you may block legitimate email.
  • Leave subdomains exposed — attackers can spoof mail.yourdomain.com if only the root is protected.

Test Your Email Security

Use our free Email Security Checker to see how well your domain is protected:

Next Steps

Now that you understand the basics, dive deeper:

Report a bug

We're new and growing — your feedback helps us improve.

Click to upload, or paste (Ctrl+V) an image