Phishing Protection for Websites: Stop Email Spoofing and Domain Abuse

Phishing Protection for Websites: Stop Email Spoofing and Domain Abuse

Phishing protection starts with your own domain configuration — because attackers don't always build a fake site, they often send emails that appear to come directly from your legitimate domain. If your SPF, DKIM, and DMARC records are missing or misconfigured, anyone can impersonate your brand in their inbox. This guide shows website owners exactly how to close those gaps.

Is your site exposed? Run a free ZeriFlow scan →

How Phishing Attacks Target Your Website and Brand

Phishing is the art of impersonation. Attackers leverage your brand's trust in two main ways:

1. 1Email spoofing — they send emails with your domain in the From: field. Recipients see your logo, your name, your email address — then click a link to a malicious site. Without proper email authentication records, mail servers accept these spoofed messages.

1. 1Lookalike domains — they register domains like paypa1.com, amaz0n-security.com, or yourcompany-support.net to host credential-harvesting pages. Users who don't inspect URLs carefully don't notice the difference.

Both attacks damage your users and your reputation. A phishing campaign abusing your domain erodes customer trust, triggers blocklist listings, and can lead to regulatory scrutiny under GDPR or similar frameworks.

SPF: Declaring Who Can Send Email for Your Domain

Sender Policy Framework (SPF) is a DNS TXT record that lists every mail server authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from @yourcompany.com, it checks your SPF record. If the sending IP isn't listed, the message can be rejected or marked as spam.

A properly configured SPF record looks like this:

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

Key directives: - include: — authorizes a third-party provider's mail servers (Google Workspace, SendGrid, Mailchimp, etc.) - ip4: — authorizes a specific IP address - -all — hard fail — rejects mail from all unlisted senders (recommended) - ~all — soft fail — marks unlisted senders as suspicious (a transitional setting)

Common mistakes: - Using +all (allows anyone — completely defeats the purpose) - Exceeding 10 DNS lookups (SPF has a hard limit; use tools like MXToolbox to count yours) - Forgetting to include all your transactional email providers

DKIM: Cryptographic Proof That You Sent the Email

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing emails. Your mail server signs each message with a private key; the receiving server verifies the signature using the public key published in your DNS.

Even if an attacker spoofs your From: address, they can't produce a valid DKIM signature because they don't have your private key. This makes DKIM a strong integrity guarantee.

What a DKIM DNS record looks like:

selector._domainkey.yourcompany.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."

Setup checklist: - Generate a 2048-bit RSA key pair (or Ed25519 for modern systems) - Add the public key to DNS under selector._domainkey.yourdomain.com - Configure your mail server or ESP to sign outgoing messages with the private key - Rotate keys at least annually - Keep old selectors in DNS for 48–72 hours after rotation to avoid rejecting in-transit messages

DMARC: Enforcement and Reporting

SPF and DKIM alone don't prevent spoofing if the receiving server doesn't enforce them. DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers what to do when authentication fails, and sends you reports so you can see who is sending email using your domain.

A DMARC record example:

_dmarc.yourcompany.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; pct=100"

Policy options (p=): - none — monitor only, take no action (good for initial deployment) - quarantine — move failing messages to spam - reject — block failing messages entirely (the goal)

Deployment strategy: 1. Start with p=none; rua=mailto:... to collect reports for 2–4 weeks. 2. Analyze reports (use tools like Postmark DMARC, Dmarcian, or Google Postmaster). 3. Move to p=quarantine once all legitimate senders are authenticated. 4. Escalate to p=reject when reports show no false positives.

ZeriFlow checks whether your domain has a valid SPF record, a DKIM selector, and a DMARC policy — and flags domains stuck at p=none where spoofing can still occur freely.

Scan your SPF, DKIM, and DMARC setup →

HTTPS Enforcement: Blocking Credential Theft in Transit

A phishing page that mimics yours over plain HTTP is less convincing than one served over HTTPS with a valid certificate. But more critically, if your own site is accessible over HTTP, attackers can intercept login credentials with a man-in-the-middle attack before users ever reach a phishing page.

HTTPS enforcement requires two things:

1. 1A valid TLS certificate — issued by a trusted CA (Let's Encrypt is free and widely trusted). Ensure it hasn't expired and covers all subdomains you use.

1. 1HTTP Strict Transport Security (HSTS) — the Strict-Transport-Security header tells browsers to refuse all HTTP connections to your domain for a defined period:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The preload directive submits your domain to browsers' built-in HSTS preload lists, meaning even the very first visit is forced to HTTPS — closing the window that SSL stripping attacks exploit.

Additional Anti-Phishing Measures for Website Owners

Monitor for Lookalike Domains

Services like Doppel, Bolster, PhishLabs, or even the free dnstwist tool generate thousands of typosquatting variants of your domain and check which ones are registered and live. Set up automated monitoring so you're notified the moment a lookalike domain appears — before attackers use it in a campaign.

Implement MFA for All User Accounts

Even if a user is phished and their password is stolen, multi-factor authentication (MFA) prevents attackers from taking over the account. Prefer hardware keys (FIDO2/WebAuthn) or TOTP apps over SMS-based codes, which are vulnerable to SIM swapping.

Use a Content Security Policy to Block Malicious Redirects

A properly configured Content-Security-Policy header limits what resources your pages can load and where they can redirect users. This prevents a compromised third-party script from silently redirecting users to a phishing page.

Educate Your Users

Technical controls are necessary but not sufficient. Regularly remind users: - Your company will never ask for passwords via email. - Always check the full domain (not just the display name) before clicking. - Report suspicious emails to your security team rather than engaging.

Anti-Phishing Checklist

• [ ] SPF record published with -all hard fail
• [ ] DKIM configured for all sending domains and subdomains
• [ ] DMARC at p=quarantine or p=reject (not p=none)
• [ ] DMARC aggregate reports reviewed monthly
• [ ] HTTPS enforced with valid TLS certificate (not expired)
• [ ] HSTS header set with max-age ≥ 31536000
• [ ] Lookalike domain monitoring active
• [ ] MFA required for all privileged accounts
• [ ] CSP header configured to restrict resource loading

FAQ

Q: Can I still be spoofed if I have SPF set up?

A: Yes, if you don't also have DMARC. SPF and DKIM each authenticate different parts of the message, but without DMARC, receivers have no instruction to reject failures. Attackers can still use "header-from" spoofing that passes SPF checks on the envelope sender but displays your domain in the visible From: field.

Q: How long does it take to set up SPF, DKIM, and DMARC?

A: SPF and DMARC DNS records can be added in under 30 minutes. DKIM requires configuring your mail server or ESP, which varies by platform but typically takes 1–2 hours. Full DMARC enforcement (reaching p=reject) takes 4–8 weeks if you have multiple legitimate mail senders to authenticate first.

Q: Does HTTPS prevent phishing?

A: HTTPS prevents eavesdropping and tampering with your site's traffic, but it doesn't prevent an attacker from getting their own certificate for a lookalike domain. A phishing site at yourcompany-login.com can be fully HTTPS. HTTPS is necessary but not sufficient — DMARC prevents email-based spoofing, and domain monitoring catches lookalike sites.

Q: What is a DMARC aggregate report?

A: An XML report sent daily (by default) from receiving mail servers to your rua address. It shows which IPs are sending email claiming to be from your domain, and whether each message passed SPF and DKIM. These reports are invaluable for identifying unauthorized senders and legitimate services you forgot to include in your SPF record.

Q: Does ZeriFlow check all of these email security records?

A: Yes. ZeriFlow's free scan checks for the presence and validity of SPF, DKIM selectors, and DMARC records, and flags policies that leave your domain open to spoofing — all in about 60 seconds.

Conclusion

Phishing protection for your website is a combination of DNS configuration, HTTPS enforcement, and ongoing monitoring. SPF, DKIM, and DMARC are not optional extras — they are the baseline authentication layer that prevents your brand from being weaponized against your own users. Most of the configuration is a one-time DNS change.

Audit where you stand right now.

Scan your site free on ZeriFlow →