Microsoft Blocking GoPhish: SPF Alignment Fix

You set up a GoPhish campaign, craft a realistic phishing template, upload your user list, and hit send. Microsoft delivers some of it to junk. Some of it disappears entirely. Your security awareness team asks why the simulation did not reach Finance, and you have no clean answer.

The answer is SPF alignment.

The Problem: Your Simulation Fails SPF Without You Knowing

GoPhish sends emails from an SMTP server you control or configure. When that server sends mail claiming to be from yourdomain.com, Microsoft checks whether the sending IP is actually authorized to send mail for yourdomain.com. If your GoPhish server IP is not in yourdomain.com SPF record, Microsoft fails the SPF check.

This is not a GoPhish problem. GoPhish is doing exactly what you configured it to do. The issue is that most organizations set up GoPhish, point it at their own domain for realistic sender names, and never check whether the sending infrastructure is authorized under that domain's SPF record.

The result is that Exchange Online Protection treats your simulation emails the same way it treats any other unsolicited mail from an unauthorized server: it blocks or junk-filters it.

This catches many security teams off guard because the simulation appears to come from an internal sender. Users see the correct display name and email address. Microsoft sees the actual sending IP and its relationship to DNS.

How Microsoft Evaluates Incoming Mail

Exchange Online Protection checks three things when a message arrives:

**SPF**: Is the sending IP authorized for the domain in the RFC5321 Mail From field?
**DKIM**: Did the sending server cryptographically sign the message with a valid key for the RFC5322 From domain?
**DMARC**: Do SPF and DKIM results align with the From domain?

A message passes SPF when the sending server IP is listed in the DNS SPF record for the domain that appears in the Mail From command. A message passes DKIM when a valid DKIM signature exists for the From domain. A message passes DMARC when at least one of SPF or DKIM passes alignment, meaning the authoritative domain in the check matches the From domain.

When GoPhish sends from yourdomain.com using a server IP that is not in yourdomain.com SPF, the SPF check fails. If GoPhish also does not DKIM-sign the message for yourdomain.com, both SPF and DKIM fail. With no aligned pass, DMARC also fails. Microsoft then applies its spam or block verdict.

The simulation does not look like phishing to Microsoft. It looks like an unauthorized sender impersonating your domain.

Fix Option 1: Use a Dedicated Simulation Subdomain

The cleanest fix is to isolate your simulation traffic to its own subdomain with its own SPF record and DKIM key.

Create a subdomain specifically for phishing simulations. A common pattern is:

`sim.yourdomain.com`
`phish.yourdomain.com`
`training.yourdomain.com`

Point your GoPhish From address at this subdomain. Set up an SPF record for the subdomain that explicitly includes the GoPhish server egress IPs:

v=spf1 ip4:203.0.113.50 ip4:198.51.100.25 -all

Set up a DKIM selector for the subdomain and configure GoPhish to DKIM-sign messages using that key.

Keep the simulation subdomain outside your main DMARC policy. Do not apply a strict p=reject DMARC record to the simulation subdomain until you have verified that your mail flow is clean, because mistakes in SPF inclusion can cause legitimate test mail to fail.

The advantage of this approach: your main domain SPF record stays clean, your DMARC alignment is unaffected, and your security team can send realistic simulations from an address that looks like your production environment.

The disadvantage: some employees may not recognize the simulation subdomain. You can address this with internal communication before each campaign.

Fix Option 2: Add GoPhish Server IPs to Your Main SPF Record

If you prefer to send simulations from your primary domain rather than a subdomain, add your GoPhish server IPs to your existing SPF record.

First, identify the egress IPs your GoPhish installation uses. In GoPhish, check your SMTP configuration for the server address. If you use a cloud-hosted GoPhish instance, the hosting provider's egress IPs may be used. Run a test send and check the message headers on the receiving end to confirm the actual sending IP.

Add those IPs to your domain SPF record:

v=spf1 include:spf.protection.outlook.com ip4:203.0.113.50 -all

Replace 203.0.113.50 with your actual GoPhish server IP.

This approach is simpler but has a real drawback: publishing your simulation infrastructure IPs in public DNS means anyone doing reconnaissance can identify your simulation servers. This is a minor security trade-off. If your threat model includes adversaries who use your simulation server list to calibrate phishing lures, this approach is not ideal.

Monitor your SPF record carefully after making this change. If your GoPhish hosting provider changes egress IPs without warning, your simulations will start failing SPF again.

Fix Option 3: Use DKIM Signing in GoPhish

GoPhish supports DKIM signing. If you configure DKIM signing for your domain, your simulation messages can pass the DKIM check even when SPF fails, and a DKIM pass combined with DMARC alignment allows the message to pass DMARC.

To use this approach:

Generate a DKIM key pair for your simulation domain
Add the public key to your DNS as a DKIM record
Configure GoPhish to use the private key for DKIM signing
Set the From address to use the domain that holds the DKIM record
Ensure your DMARC record is set to `p=quarantine` or `p=reject` with `aspf=r` or `aspf=s` alignment set to relaxed or strict

If your main domain DMARC policy requires strict alignment and your simulation subdomain is separate, you need either a DKIM key published for the main From domain or a DMARC record for the simulation subdomain with relaxed alignment.

DKIM signing alone is not sufficient if you are also failing SPF alignment under a strict DMARC policy. You need at least one aligned pass. DKIM gives you that pass when configured correctly.

How to Verify Your Fix Works

After making any of these changes, test before running your next campaign.

Send a test email from GoPhish to yourself or a dedicated test account. Check the message headers in the received email. Look for:

`Authentication-Results`: This header shows SPF, DKIM, and DMARC results
`Received-SPF`: Shows whether SPF passed or failed
`DKIM-Signature`: Confirms DKIM was attempted

A passing result looks like this in the Authentication-Results header:

Authentication-Results: mx.microsoft.com; dkim=pass header.d=yourdomain.com; spf=pass smtp.mailfrom=yourdomain.com; dmarc=pass

If you see spf=fail or dmarc=fail, the configuration is not yet correct.

Use Microsoft Message Trace in the Exchange admin center to check delivery status for specific messages. Look for the event type DLPpolicyMatch, TransportRule, or malware if delivery is being affected by additional policies beyond authentication.

How DMARC Aggregate Reports Surface Simulation Problems

If you manage phishing simulations across multiple domains, manually checking each GoPhish configuration is time-consuming. A more systematic approach is to monitor DMARC aggregate reports for all your domains in one place.

DMARC aggregate reports do not contain message-level detail, but they do show which IPs are sending mail for your domain and whether those IPs are passing or failing SPF and DKIM. When a new IP starts sending mail for your domain without being authorized in SPF, it shows up in your next aggregate report as an SPF failure.

For organizations running periodic phishing simulations, DMARC aggregate reports give you a way to catch simulation configuration drift before your next campaign. If your DMARC reporting shows SPF failures from an IP you do not recognize, it may be a misconfigured simulation rather than an attack.

DMARCFlow aggregate report monitoring tracks this across all your domains. When your simulation infrastructure changes, DMARCFlow alerts you to new SPF failures before they affect campaign delivery. This is particularly useful for security teams managing simulations across multiple tenants or cloud email configurations.

FAQ

Does DMARC block GoPhish?

DMARC itself does not block GoPhish. DMARC checks whether SPF or DKIM passes alignment with the From domain. GoPhish fails DMARC when it sends from a domain whose SPF record does not include the GoPhish server IP and when no valid DKIM signature exists for that domain. Fix the SPF or DKIM configuration and DMARC passes.

Can I use a free SMTP relay for GoPhish instead?

Yes. Services like SendGrid, Mailgun, or Amazon SES can relay your GoPhish traffic. The same SPF and DKIM alignment rules apply: whichever domain appears in the From address must be authorized by the relay service or your own SPF record. Many organizations use a dedicated subdomain routed through a bulk mail provider to avoid polluting their main domain reputation.

What if my GoPhish server IP changes?

If your GoPhish hosting provider rotates egress IPs, you need to update your SPF record to include the new IPs. Set up monitoring on your SPF record or use DMARC aggregate reports to catch new SPF failures quickly. If you use a cloud provider with documented egress IP ranges, you can include the entire range in your SPF record rather than specific IPs.

Does Microsoft have a process to whitelist simulation senders?

Microsoft does not offer a formal whitelist process for internal phishing simulation senders. The supported approach is to configure your simulation infrastructure to pass standard email authentication checks. Some organizations work with Microsoft FastTrack or their E5 licensing team for guidance on configuring simulation mail flows, but there is no approved simulation sender list.

Can I run simulations from an internal domain that bypasses Microsoft filtering entirely?

Internal mail flows within your own Exchange or M365 environment do not traverse the same perimeter filtering as external mail. However, if your simulation is meant to test how employees handle external-looking mail, you need the mail to come from outside your organization. For that, the SPF or DKIM fix is the correct approach.