DNS
CYBERSECURITY
Stop Email Imposters: How to Protect Your Domain From Spoofing
Someone can send an email that looks like it came from you.
Here's how SPF, DKIM and DMARC can stop them.
It said I had a virus, my camera was hacked, and I needed to send
$1,800 in Bitcoin or my "recorded videos" would be shared.
It was completely fake — but here's what got my attention:
it looked like it came from ME.
If you're a business owner, you've probably seen something similar.
Someone can make an email appear to come from your domain even though
the message actually originated somewhere completely different.
That's called email spoofing, and fortunately,
there are several things you can do about it.
What Just Happened to Me — And You
That email was spoofed. The scammer forged the visible
sender address to make the message appear to come from
seth@solarblu.net.
The message did not actually originate from my mail server. The sender
was using a completely unrelated server.
⚠️ Here's the Problem
Email was originally designed around trust and interoperability.
Without proper authentication, receiving mail servers may have
very little information proving that the person sending a message
is actually authorized to use your domain.
That means scammers can send messages that look like they're
from your company, your employees, or even your CEO.
How Email Spoofing Works
Think of email spoofing like someone putting your return address on
an envelope. The address says it's from you, but that doesn't mean
you actually sent the letter.
❌ Without Authentication
Scammer: "From: seth@solarblu.net"
Receiving server: "Okay, I guess that's legitimate."
Message delivered.
🛡️ With SPF / DKIM / DMARC
Scammer: "From: seth@solarblu.net"
Receiving server:
"Let me verify this is actually authorized by solarblu.net."
Authentication fails → message can be rejected.
The Three Authentication Protocols
1
SPF — Sender Policy Framework
What it does:
SPF tells receiving email servers which systems are authorized
to send mail for your domain.
A basic SPF record looks something like this:
v=spf1 include:your-email-provider -allBreaking it down:
v=spf1— This identifies the record as SPF.include:your-email-provider— Authorizes the provider's mail servers.-all— Everything else should fail SPF.
-all vs. ~all
~all— Soft fail. The message may still be accepted but treated as suspicious.-all— Hard fail. The sender is not authorized.
Use
-all when you know your SPF record accuratelyrepresents every legitimate system that sends mail for your domain.
2
DKIM — DomainKeys Identified Mail
What it does:
DKIM adds a cryptographic signature to outgoing email.
Receiving servers can use the public key published in your DNS
records to verify that the message was authorized by your domain
and that important parts of the message were not altered.
The good news is that many email providers can configure DKIM
automatically or provide the DNS record you need to publish.
To check your setup:
- Ask your email provider whether DKIM is enabled.
- Look in your DNS records for a DKIM selector.
- Your provider will tell you the exact selector and DNS value.
3
DMARC — Domain-based Message Authentication
What it does:
DMARC tells receiving mail servers what to do when messages
claiming to come from your domain fail authentication checks.
A basic DMARC record can look like this:
v=DMARC1; p=reject; rua=mailto:admin@yourdomain.comBreaking it down:
v=DMARC1— Identifies the record as DMARC.p=reject— Requests rejection of messages that fail DMARC.rua=mailto:admin@yourdomain.com— Requests aggregate reports.
DMARC Policies
| Policy | What It Does |
|---|---|
p=none |
Monitor authentication without requesting blocking. |
p=quarantine |
Request that failing messages be treated as suspicious, often by sending them to spam. |
p=reject |
Request that failing messages be rejected. |
Step-by-Step: Protect Your Domain
Log In to Your Domain Registrar
Go to wherever your domain is managed. This might be your
domain registrar, hosting company, or DNS provider.
Look for something called:
- DNS Management
- DNS Settings
- Manage DNS
- Zone Editor
Find Your TXT Records
Your DNS control panel will normally contain several types
of records:
- A Records
- CNAME Records
- MX Records
- TXT Records ← This is where you'll work.
Add Your SPF Record
Add a TXT record for your domain.
| Field | Example |
|---|---|
| Name / Host | @ or blank, depending on your DNS provider |
| Value | v=spf1 include:your-email-provider -all |
Common examples:
- Google Workspace:
v=spf1 include:_spf.google.com -all - Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all - Other providers: Ask the provider for its official SPF record.
⚠️ Don't Create Multiple SPF Records
A domain should have a single SPF policy record. If multiple
services send email for your domain, their authorized
mechanisms normally need to be combined into that one SPF record.
Add DMARC
Add another TXT record:
| Field | Value |
|---|---|
| Name / Host | _dmarc |
| Value | v=DMARC1; p=reject; rua=mailto:admin@yourdomain.com |
Replace admin@yourdomain.com with an address
you actually monitor if you want to receive aggregate reports.
Verify Your Configuration
DNS changes may take some time to propagate. Once the records
are visible, use a reputable DNS or DMARC testing service to
verify your configuration.
Don't just check whether the record exists. Make sure the
actual value is correct and that every legitimate email
sending service is accounted for.
Important Tips & Considerations
✅ DO
- Use
-allonce your SPF configuration is correct. - Set up DKIM with your email provider.
- Start cautiously with DMARC monitoring if you're unsure of your mail flow.
- Move toward enforcement once legitimate mail is passing authentication.
- Keep DNS records updated when changing email providers.
- Check every value carefully — one typo can cause authentication failures.
⚠️ DON'T
- Don't create multiple SPF records.
- Don't forget DKIM.
- Don't ignore DMARC reports.
- Don't blindly publish
p=rejectbefore understanding your legitimate mail sources. - Don't assume your website host and email provider are necessarily the same company.
Things You Should Check
- Does your hosting or email provider have DKIM enabled?
Ask them. - Do you use third-party email services?
Services such as marketing platforms may require additional
authentication configuration. - Do multiple systems send mail for your domain?
Make sure each legitimate sender is accounted for. - Did you recently change email providers?
Update your SPF, DKIM and DMARC configuration.
Will This Block Legitimate Emails?
This is one of the biggest questions people have when they first
hear about email authentication.
SPF, DKIM and DMARC are about protecting the use of YOUR domain
as the sender.
They do not prevent random people from sending you email.
These Can Still Email You:
- ✓ Gmail users
- ✓ Customers using other email providers
- ✓ People using completely different domains
- ✓ Anyone contacting your address normally
What You're Trying to Stop:
- ✗ Scammers pretending to be your domain
- ✗ Fake messages claiming to come from your company
- ✗ Spoofed executive or employee messages
- ✗ Phishing campaigns abusing your domain's reputation
Need Help?
If You're Stuck
- Contact your domain/DNS provider and ask how to add TXT records.
- Contact your email provider and request the correct SPF and DKIM configuration.
- Verify that every legitimate service sending mail for your domain is included.
- Test your DNS records after making changes.
🚩 Watch Out for Bad Advice
- "SPF can't be set up."
— In normal domain configurations, SPF is simply a DNS record. - "SPF will block your customers."
— SPF is about mail claiming to originate from your domain;
it doesn't stop people from emailing you. - "You have to pay extra just to have SPF."
— SPF itself is a DNS-based authentication mechanism.
Some providers may charge for services around email security,
but the DNS record itself isn't inherently a paid feature.
The Bottom Line
That scam email I received was a perfect example of why domain
authentication matters.
Without proper authentication, an attacker can make an email appear
to come from your domain even though they have no relationship with
your company.
With SPF, DKIM and DMARC, receiving mail systems have
much more information available to determine whether a message is
actually authorized to use your domain.
Protect Your Domain
It doesn't have to be complicated.
Check your DNS. Configure SPF. Enable DKIM. Deploy DMARC.
Then monitor your results and tighten your policy once you know
your legitimate mail is authenticating correctly.
Your customers, your employees, and your domain reputation
are worth protecting.
Next Steps
- Log into your domain/DNS provider.
- Find the DNS/TXT records section.
- Verify your SPF record.
- Verify DKIM is enabled.
- Add or verify your DMARC record.
- Test your configuration.
- Monitor authentication results.
- Move toward an enforcement policy when you're confident legitimate mail is passing.