Wurdey.com
← Back to blog

email

SPF, DKIM & DMARC: Stop Email Spoofing for Good

If you have ever gotten a "did you send this?" text from a client, or watched a legitimate invoice land in someone's spam folder, you have run into the same root cause: your domain's email authentication is incomplete or misconfigured. Email was designed in an era when nobody lied about who they were. By default, anyone on the internet can type your domain into the "From" line and send a message that looks like it came from you. The only thing standing between your brand and that abuse is three DNS records — SPF, DKIM, and DMARC.

This guide explains each one in plain English, shows how gaps let attackers impersonate you (and quietly wreck your deliverability), and walks through setting them up correctly.

Why email spoofing is so easy

The address a recipient sees in the "From" field is just text. Nothing in the base email protocol verifies it. That means a scammer can send a message that appears to come from you@yourdomain.com without ever touching your systems — no password required, no server breached. This fuels two related problems:

  • Spoofing — attackers send phishing or fraud emails "as you," damaging your reputation and tricking your customers, staff, or vendors.
  • Account takeover fallout — spoofed messages are a common on-ramp to business email compromise, where an employee is tricked into wiring money or handing over credentials.

The flip side hurts too: when your domain has weak authentication, receiving servers like Gmail and Outlook can't confirm your real mail is legitimate, so they downrank it. That is why carefully written newsletters and one-off replies sometimes vanish into spam for no obvious reason.

Gmail and Yahoo now require this

As of 2024, major providers require valid SPF, DKIM, and (for bulk senders) DMARC to reliably deliver mail. "We'll set it up later" now means your messages get filtered or rejected today — not someday.

SPF: who is allowed to send for you

SPF (Sender Policy Framework) is a published list of the mail servers permitted to send email using your domain. You add a single TXT record to your DNS that names your legitimate senders — your mail host, your marketing platform, your CRM, and so on. When a receiving server gets a message claiming to be from you, it checks whether the sending server appears on that list.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

The include entries authorize specific providers; the ~all at the end tells receivers to treat anything not on the list as suspicious. Common mistakes include:

  • Forgetting to add a service you actually use, so its mail fails SPF and gets flagged.
  • Publishing more than one SPF record (only one is allowed — a second one breaks both).
  • Exceeding the 10 DNS lookup limit, which silently invalidates the whole record.

DKIM: a tamper-proof signature

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send. Your mail server signs each outgoing email with a private key, and you publish the matching public key in DNS. The receiving server uses that public key to confirm two things: the mail genuinely came from your domain, and nobody altered it in transit.

Think of SPF as a guest list and DKIM as a wax seal on the envelope. SPF says "this server is allowed to send," while DKIM proves "this exact message is authentic and untouched." You generally enable DKIM inside your email provider's admin console, which generates the key and gives you a TXT (or CNAME) record to publish.

Both matter — together

SPF checks the sending server. DKIM checks the message itself. A spoofed email will usually fail one or both, which is exactly the signal DMARC needs to act on.

DMARC: the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting and Conformance) is where the protection actually gets teeth. It's a policy record that tells receiving servers what to do when a message fails SPF and DKIM checks — and it asks them to send you reports on who is sending mail using your domain.

A DMARC record specifies a policy level:

  1. p=none — monitor only. Nothing is blocked, but you receive reports. This is the right starting point.
  2. p=quarantine — send failing mail to spam.
  3. p=reject — refuse failing mail outright. This is the goal — it makes spoofing your domain effectively impossible.

The mistake most businesses make is either never publishing DMARC at all, or jumping straight to p=reject before confirming their legitimate senders pass. Do that and you can block your own invoices and newsletters. The correct path is deliberate: start at none, read the reports, fix any legitimate source that's failing, then tighten to quarantine and finally reject.

How to set all three up correctly

  1. Inventory every service that sends mail as your domain — your mailbox provider, marketing tool, helpdesk, e-commerce platform, and any web forms.
  2. Publish one SPF record that authorizes all of them, staying under the 10 lookup limit and ending in ~all.
  3. Enable DKIM in each sending platform and publish the keys it provides. Multiple services can each have their own DKIM selector.
  4. Publish a DMARC record at p=none with a reporting address so you can see what's actually being sent.
  5. Monitor the reports for a few weeks, correct any legitimate source that's failing, then step the policy up to quarantine and eventually reject.
Alignment is the detail people miss

DMARC requires the domain in your visible "From" address to align with the domain that passed SPF or DKIM. Records can look correct and still fail because a sending service uses its own domain under the hood. Reading DMARC reports is the only reliable way to catch this.

Where this connects to the rest of your security

Email authentication is one layer of a bigger picture. A spoofed message that convinces a staff member to reset a password can lead straight to a compromised website. If that happens, tight DNS hygiene works hand in hand with hardened WordPress security and, when things go wrong, fast malware removal or full hacked-site cleanup. Deliverability and site integrity are two sides of the same trust relationship you have with your audience.

Key takeaways
  • By default, anyone can send email "as" your domain — SPF, DKIM, and DMARC are what stop them.
  • SPF lists who may send for you; DKIM cryptographically signs each message; DMARC tells receivers what to do with fakes and reports back.
  • Missing or broken records don't just enable spoofing — they push your real mail into spam.
  • Roll out DMARC gradually: none to monitor, then quarantine, then reject.
  • Gmail and Outlook now expect these records, so this is table stakes, not a nice-to-have.

How Wurdey handles this for clients

Most business owners should never have to think about SPF records or DKIM selectors — and with Wurdey managing your DNS, you don't. When we host and maintain a site, we configure and monitor email authentication as part of the package: publishing correct records for every legitimate sender, staging DMARC from monitoring to full enforcement without breaking your mail, and keeping it current as your tools change. It's part of how our WordPress maintenance plans and managed hosting keep your whole online presence trustworthy. If your mail is landing in spam or you're not sure whether your domain can be spoofed, get in touch and we'll audit it for you.

Next step

Rather not do all this yourself?

Wurdey care plans handle updates, backups, security and monitoring for one monthly price, hosting included, from $49 a month. Free migration, and a real team on the other end.