Stop Emails Going to Spam: Configure SPF, DKIM & DMARC

If customers never see your invoices, password resets, or contact-form replies, broken email authentication is usually the cause—not “bad luck” with Gmail.

This guide walks homeowners and small businesses through properly configuring SPF, DKIM, and DMARC so legitimate mail from your domain stops failing spam filters. You will get concrete DNS checks, record examples, and numbered DIY fixes. When records conflict across hosts, WordPress SMTP plugins, and CRMs, Fixwebnode can configure SPF, DKIM, and DMARC end-to-end so delivery is consistent rather than guesswork.

We work with sites and mail stacks used across Melbourne and nearby suburbs; see all service areas if you need on-site or remote help tied to your hosting region.

Why SPF, DKIM, and DMARC decide whether mail reaches the inbox

Receiving servers (Google, Microsoft 365, Yahoo, and most business filters) no longer trust a From address alone. They ask three questions:

• SPF — Is this IP allowed to send for the domain?
• DKIM — Was the message cryptographically signed by a key published in DNS?
• DMARC — Do SPF/DKIM align with the visible From domain, and what should happen on failure (none, quarantine, or reject)?

Fail any of those consistently and bulk filters score you as spoof-prone. Fixing the trio is the highest-leverage way to stop emails going to spam without rewriting your whole marketing stack.

Common issues that push good mail into spam

1. Multiple or contradictory SPF TXT records

Symptom: Gmail shows “SPF softfail” or “SPF permerror”; Microsoft marks bulk as junk even though one host “already added SPF.” Root cause is almost always two separate TXT records both starting with v=spf1, or an SPF string that exceeds lookup limits after too many include: mechanisms.

2. DKIM selector published but messages unsigned (or wrong key)

Symptom: DNS has a selector._domainkey TXT record, yet headers show dkim=none or dkim=fail (body hash did not verify). Common on WordPress sites that still send through PHP mail() instead of the provider’s authenticated SMTP, and after panel key rotations that never updated DNS.

3. DMARC missing, on p=none forever, or alignment broken

Symptom: You “set DMARC” months ago at p=none with no reporting mailbox, so spoofing and misaligned third-party tools (booking widgets, CRMs, newsletter ESPs) keep failing quietly while inbox placement worsens. Or DMARC is p=reject before SPF/DKIM cover every real sender.

4. Contact forms and transactional plugins bypass authenticated SMTP

Symptom: Manual mail from webmail is fine; form notifications and WooCommerce/order mail die in spam. The site submits via the server’s raw sendmail path, which is not covered by your ESP’s DKIM and may not match SPF.

How to fix each issue (DIY runbook)

Fix 1 — Collapse SPF into one valid record

SPF allows one SPF policy per domain name (the apex you send as). Multiple v=spf1 TXT records cause permanent errors at many receivers.

Step 1 — Inventory every sender that uses your domain

List web host, Google Workspace or Microsoft 365, transactional SMTP (e.g. Amazon SES, Postmark, Mailgun), newsletter tools, and ticket systems. Each vendor documents an include: or IP mechanism you must merge.

Step 2 — Read what is live in DNS

dig +short TXT example.com
dig +short TXT example.com @8.8.8.8

Expect zero or one string beginning with v=spf1. If you see two, delete or merge until a single record remains at your DNS host (Cloudflare, Route 53, registrar DNS, cPanel, etc.).

Step 3 — Publish one merged policy

Example pattern (replace includes with your real vendors; keep under 10 DNS lookups total):

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.example-esp.com -all

Use ~all only while testing; move to -all once every production path is listed. Never leave +all.

Step 4 — Verify propagation and evaluation

dig +short TXT example.com
host -t TXT example.com

Send a test to a Gmail address you control, open the message, choose “Show original,” and confirm spf=pass. If you still see permerror, you likely nested too many includes—flatten with vendor guidance or a specialist.

When to call Fixwebnode: more than three ESPs, inherited DNS with duplicate SPF strings, or lookup-limit errors you cannot flatten safely.

Fix 2 — Make DKIM actually sign outbound mail

A DNS record alone does nothing if the MTA never signs.

Step 1 — Confirm the published key

Your provider gives a selector name (for example google, k1, s1). Check it:

dig +short TXT google._domainkey.example.com
dig +short TXT default._domainkey.example.com

You should see a TXT value containing v=DKIM1 and a p= public key. Empty answers mean DNS was never updated or the selector name is wrong.

Step 2 — Enable signing on the real sending path

• Google Workspace: Admin console → Gmail → Authenticate email → generate and paste the DNS TXT.
• Microsoft 365: Defender / DKIM settings per domain; enable after CNAME records resolve.
• cPanel/Exim or Plesk: enable DKIM for the domain and copy the exact TXT the panel shows.
• Third-party SMTP: install their DNS CNAMEs/TXT and force the app to send through that SMTP host with auth.

Step 3 — Stop unsigned PHP mail on WordPress

Install and configure a maintained SMTP plugin (for example WP Mail SMTP, Easy WP SMTP, or Post SMTP) pointed at your provider’s submission host on port 587 with STARTTLS, or 465 with SMTPS. Use an app password or API key—not your daily login—wherever the provider requires it.

For hosts where you manage the stack yourself, confirm the site is not calling raw sendmail:

# Example: check whether a local MTA is the only path
systemctl status postfix 2>/dev/null || systemctl status exim4 2>/dev/null
# Prefer authenticated relay over local pickup for web apps

Step 4 — Verify signature on a live message

Send from the same channel users hit (contact form, not only webmail). In Gmail “Show original” you want dkim=pass for your domain. body hash did not verify usually means a gateway altered content after signing—or you published a stale key after rotation. Re-copy the current public key and wait for TTL expiry.

When to call Fixwebnode: mixed signing (some tools pass, forms fail), key rotations across several selectors, or Collingwood / inner-Melbourne WordPress stacks that need SMTP and form plugins aligned—see Collingwood WordPress contact form & SMTP fixes.

Fix 3 — Stand up DMARC with alignment and reporting

DMARC ties SPF and DKIM to the From domain users see.

Step 1 — Create a reporting mailbox you monitor

Use something like dmarc-reports@example.com (or a dedicated group). You will receive XML aggregate reports from major receivers.

Step 2 — Publish a starter record at the apex

dig +short TXT _dmarc.example.com

If empty, add a TXT host _dmarc:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r; pct=100

p=none monitors without forcing quarantine while you read reports. Relaxed alignment (r) is appropriate at the start for subdomains and common ESP setups.

Step 3 — Read failures before tightening policy

For one to two weeks, note which sources fail SPF or DKIM alignment. Add missing include: mechanisms, fix DKIM selectors, or change those tools to send from a subdomain you control (for example mail.example.com) with its own SPF/DKIM.

Step 4 — Move policy forward deliberately

When legitimate mail shows pass/pass alignment:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100; adkim=s; aspf=s

Only advance to p=reject after quarantine shows no false positives for real customer mail. Jumping straight to reject is a common way businesses lock out their own booking or CRM traffic.

Step 5 — Confirm header evaluation

Gmail original headers should show dmarc=pass (or fail only on intentional spoof tests). Authentication-Results should reference your domain, not only an ESP’s mail-from domain, when alignment is correct.

When to call Fixwebnode: you need subdomain strategies for agencies and ESPs, BIMI readiness later, or a corporate site rebuild where brand mail and the website must match—related design work is covered under corporate website design in Melbourne, VIC when the public site and mail identity are being reworked together.

Fix 4 — Force forms and apps through authenticated SMTP

Step 1 — Identify the From domain used in form notifications. It must be a domain you control and authenticate—not a free freemail address.

Step 2 — Create a mailbox or SMTP credential at your provider solely for application mail (for example noreply@example.com or a transactional API key).

Step 3 — Configure the CMS to use that SMTP host, port, encryption, and credential. Send the plugin’s built-in test message, then submit the live contact form once.

Step 4 — Re-check authentication results on the received form mail. You need spf=pass, dkim=pass, and ideally dmarc=pass on that path specifically—not only on manual webmail.

If the host blocks outbound 587/465, open those ports or switch to the provider’s documented HTTP API for transactional mail; do not “fix” it by spoofing From without SPF/DKIM coverage.

When DIY is enough vs when to book Fixwebnode

DIY is enough when you have one primary mail host, DNS access, fewer than a handful of sending tools, and you can merge SPF, enable DKIM in the panel, publish DMARC at p=none, and prove pass results on form mail within a maintenance window.

Book a specialist when any of the following are true: duplicate SPF inherited from old developers; DKIM passes in webmail but fails on WordPress, CRM, and billing tools; DMARC reports show unknown sources you cannot map; host lock-in prevents SMTP; or you are ready for p=quarantine/reject and cannot risk cutting off customers. Fixwebnode acts as a direct specialist on this exact problem—authentication records, SMTP paths, and form delivery—not a bid marketplace.

Remote DNS and mail configuration covers most small-business cases across Melbourne; local context helps when hosting, registrars, and on-site routers interact with outbound ports.

Checklist before you tighten filters

• Exactly one SPF TXT at the sending domain; dig shows a single v=spf1 string.
• DKIM selector resolves and production messages show dkim=pass.
• Contact forms and apps use authenticated SMTP or the ESP API—not raw PHP mail alone.
• _dmarc TXT exists with a monitored rua address; policy only rises after clean reports.
• Test messages from every real path reviewed via Gmail “Show original” or Microsoft message headers.

Get mail out of spam—talk to Fixwebnode

SPF, DKIM, and DMARC only work when DNS, the mail platform, and every application path agree. If your domain still fails authentication after the steps above—or you want a clean cutover without trial-and-error on live customers—start a conversation with the team that handles this service directly.

Book help to stop emails going to spam with proper SPF, DKIM, and DMARC configuration. Bring your domain name, DNS host login (or willingness to add records), and a list of tools that send as your brand. We will map senders, publish correct records, verify headers, and leave you with a policy you can tighten safely.