Why Phishing Test Emails Go to Spam — And How to Fix It (SMTP & Deliverability Guide)

There's a problem that kills most first phishing simulations: the test emails land in the spam folder, employees never see them, and you report a 2% click rate that means absolutely nothing.

Worse — your email gateway clicks every link automatically as part of safe-link scanning, you see a 97% click rate, and think your team is catastrophically vulnerable when actually no human saw the email at all.

Email deliverability for phishing simulations has specific requirements that are different from regular marketing email. This guide covers what you actually need to understand — and how to get every test email to the primary inbox.

Why phishing test emails go to spam

Email providers (Gmail, Outlook, Proofpoint, Mimecast) evaluate every incoming email on several signals before deciding whether to deliver it to the inbox or spam. The main ones:

• Sender IP reputation — is this IP address known for sending spam? New IPs with no sending history land in spam by default. Home IP addresses are blocked by Gmail entirely for direct mail delivery.
• SPF record — does the "envelope from" domain have an SPF record that includes this sending IP? If not, many providers reject or spam-folder the email.
• DKIM signature — is the email cryptographically signed with a DKIM key for the sending domain? Missing or invalid DKIM signatures are a major spam signal.
• DMARC policy — does the domain's DMARC record tell providers to reject emails that fail SPF/DKIM? If your simulation uses a domain with DMARC enforcement, failed authentication means the email never arrives.
• Content signals — suspicious link patterns, missing unsubscribe headers, certain phishing-like phrases trigger content filters.

Most DIY phishing simulation setups (GoPhish on a fresh VPS, a new Amazon SES account, a local mail server) fail on IP reputation and DKIM. The result: spam folder, and meaningless simulation data.

The three DNS records you must have

SPF (Sender Policy Framework)

An SPF record is a DNS TXT record on your sending domain that tells receiving mail servers which IP addresses are authorised to send email from that domain. Format:

v=spf1 ip4:YOUR_SENDING_IP ~all

The ~all means "soft fail" — emails from unauthorised IPs are accepted but marked as suspicious rather than rejected outright. For simulations, this is correct — you don't want to reject failures, you want them delivered so humans see them.

If using PhishSpark, your SPF record should include PhishSpark's sending IP: v=spf1 ip4:48.217.201.137 ~all. If using your own SMTP server, use your server's public IP instead.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every email you send. The receiving server looks up your public key in DNS and uses it to verify the signature. If it matches, the email is authenticated. If DKIM is missing or the signature is invalid, modern email providers treat it as a significant spam signal.

DKIM requires two things:

1. A private/public key pair — you sign emails with the private key; the public key goes in DNS
2. A DNS TXT record at SELECTOR._domainkey.yourdomain.com containing the public key

The format of the DNS record:

v=DKIM1; h=sha256; k=rsa; p=BASE64_PUBLIC_KEY

In PhishSpark, DKIM key generation is automatic. When you add a domain, PhishSpark generates a 2048-bit RSA key pair, stores the private key securely, and shows you the exact DNS TXT record to add. All outgoing emails from that domain are signed automatically — you don't touch the private key directly.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC tells receiving servers what to do when an email fails SPF or DKIM authentication. For phishing simulations, use a permissive policy:

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

p=none means: if authentication fails, still deliver the email, just send a report. This is correct for simulations — you never want legitimate simulation emails to be rejected because of a misconfiguration. As your domain matures, you can move to p=quarantine or p=reject for protection against spoofing, but during simulations keep it at p=none.

The DMARC record goes on _dmarc.yourdomain.com as a TXT record.

Why sending IP matters more than most people realise

Even with perfect SPF, DKIM, and DMARC, if your email comes from an IP address with a bad reputation, it goes to spam. IP reputation is built over time through consistent, legitimate sending behaviour — a new IP has no reputation at all, which most providers treat the same as a bad reputation.

This is why:

• Your home or office internet IP is blocked by Gmail and Outlook for direct email delivery — residential IPs cannot send email directly to major providers
• A brand new VPS on DigitalOcean or AWS will land in spam on its first few sends until the IP has a sending history
• Shared SMTP relays (like early-stage Amazon SES sandbox accounts) have restricted delivery until you request production access

PhishSpark sends from a dedicated IP (48.217.201.137) with an established sending reputation, DKIM-signed per domain. The relay sends direct to recipient mail servers (direct MX delivery), bypassing shared relay infrastructure that can get blocked when other senders abuse it.

If you're using your own SMTP credentials (BYO SMTP — configured in Settings → SMTP), use a provider that allows DKIM signing on your custom domain: Amazon SES, Mailgun, or SendGrid all support this. PhishSpark signs outgoing emails with your domain's DKIM key regardless of whether you use the platform relay or your own SMTP.

The gateway problem: why you see 100% click rates before launch

Even when your email is perfectly configured and reaches the inbox, corporate email security gateways create a second deliverability problem: they click everything.

Platforms like Microsoft Defender for Office 365, Zscaler, Proofpoint, Mimecast, and Barracuda automatically follow every link in every inbound email to check whether the destination is malicious. This scanning happens within seconds of the email being received — before any human opens it.

In a phishing simulation, this means your tracking links get clicked by bots, your dashboard shows 70–100% click rates, and your results are completely meaningless.

The fix: whitelist your simulation tool's sending IP in your gateway's safe-link exclusion list before the campaign launches. This tells the gateway "don't scan links in emails from this IP." In PhishSpark, the sending IP is shown in Domains → Your Domain. Add 48.217.201.137 to your gateway's trusted sender or URL-exclusion list.

Each gateway has a different location for this setting:

• Microsoft Defender for Office 365: Security policies → Safe Links → Trusted URLs list
• Proofpoint: Email protection → URL defense → Allow list
• Mimecast: Administration → Gateway → Policies → URL Protection → Managed URLs
• Zscaler: Policy → URL & Cloud App Control → URL Categories → Allowed URLs
• Barracuda: Security → Sender Authentication → Approved Senders

Verifying your setup before launch

Before running a campaign on your full target list, always test with a small group first:

1. Use Campaigns → Test Email to send the campaign email to your own address
2. Check whether it landed in inbox or spam
3. Check the email headers: look for dkim=pass and spf=pass in the authentication results header
4. Click the tracking link yourself — verify you see the phishing landing page, not an error
5. Check your PhishSpark dashboard: the click should register against your test email address

If the test email lands in spam, the most common causes are:

• DKIM record not yet propagated — DNS changes can take minutes to 48 hours; verify with dig TXT selector._domainkey.yourdomain.com
• SPF record not including the correct sending IP — re-check that the IP in your SPF record matches the actual sending IP shown in PhishSpark
• New domain with no sending history — try sending a few legitimate emails from the domain first to warm the reputation

Using your own SMTP (BYO SMTP)

If your organisation requires email to go through your own SMTP infrastructure, PhishSpark supports custom SMTP credentials. In Settings → SMTP, enter your SMTP host, port, username, password, and from address. PhishSpark will send all campaign emails through your server while still applying DKIM signing with your domain's private key.

Recommended SMTP providers for simulation deliverability:

• Amazon SES — excellent reputation, $0.10 per 1,000 emails, supports custom DKIM domains. Requires production access request (24–48 hour approval).
• Mailgun — good deliverability, strong DKIM support, $0.80 per 1,000 emails.
• SendGrid — broad deliverability, supports custom domain authentication, tiered pricing.

Avoid using shared hosting SMTP or consumer email accounts (Gmail SMTP, Outlook SMTP) for phishing simulations — these have rate limits and content filters that will interfere with delivery.

Start with deliverability sorted

The 30-minute setup claim for PhishSpark includes the DNS configuration. Create a free account, add your domain, follow the wizard to add your three DNS records, and you're ready to send — with SPF, DKIM, and DMARC all verified. The platform checks all three automatically before allowing you to launch a campaign.