Scammers Sending Email From Your Address? How to Check and Fix SPF, DKIM and DMARC

If fake invoices are going out under your name, or your real mail lands in spam, your domain is missing its email security records. Here's a two-minute check and a step-by-step fix.

A customer forwards you an invoice "from" your own email address, with bank details you've never seen. Or a supplier asks why you emailed them a strange login link. Or your own invoices have started landing in clients' spam folders. All three point to the same gap: nothing is telling the world's mail servers which email from your domain is real.

Email was designed in the early 1980s for a small, trusting network, so it never checked who a message was really from. Typing someone else's address in the "From" line is still about as hard as writing a fake return address on an envelope. That's called spoofing. Three DNS records fix it: SPF, DKIM and DMARC. You can check where you stand in about two minutes.

Check your domain in two minutes

Check 1: does your domain publish a DMARC policy?

  1. Go to a free lookup such as MxToolbox's DMARC Check.
  2. Type just your domain (yourbusiness.com, not an email address) and run the lookup.
  3. Look at the policy it reports, the part that reads p= followed by a word.

What the result means:

  • No DMARC record found: anyone can send mail as your domain and receiving servers have no instructions from you. Start at the setup plan below.
  • The policy is none: you're monitoring, not protecting. Fake mail still gets delivered. You're partway there.
  • The policy is quarantine or reject: receiving servers are told to junk or refuse mail that fails the checks. That's the goal.

Check 2: does your real mail pass?

  1. Send an email from your business account to a personal Gmail address.
  2. Open it in Gmail on a computer, click the three-dot More menu next to Reply and choose Show original (Google's instructions).
  3. Near the top you'll see lines for SPF, DKIM and DMARC. All three should say PASS.

Repeat it for every tool that sends mail as you: your invoicing software, newsletter platform, booking system. A FAIL, or a missing DKIM line, tells you which sender still needs setting up.

Why it matters

Spoofed and lookalike email is the engine behind business email compromise, the scam where a criminal poses as someone you trust to get a payment sent or bank details changed. The FBI's Internet Crime Complaint Center logged about $3 billion in reported BEC losses in 2025. When the fake email comes from your exact address, the usual advice ("check the sender") fails completely. This is social engineering with a perfect disguise.

There's a second, more everyday reason: the big mailbox providers now expect these records. Google and Yahoo have required SPF, DKIM and DMARC from bulk senders (about 5,000 or more messages a day to their users) since February 2024, and Google's sender guidelines ask every sender to use SPF or DKIM. Microsoft added the same requirements for high-volume senders to Outlook.com in May 2025. Even if you send nowhere near that much, authenticated mail is what reliably reaches the inbox.

Where these records live

All three are short text notes published in your domain's DNS, the internet's address book that turns a name like managednerds.tech into the numeric address computers use. You add them in your DNS host's control panel, which is usually your domain registrar (GoDaddy, Namecheap, Cloudflare and so on) or your website host. Receiving mail servers read the notes to decide whether a message claiming to be from you is genuine. If you want more on why the address book itself needs protecting, see our piece on DNS security.

SPF: the guest list

SPF (Sender Policy Framework) lists the services allowed to send email for your domain: your email host, newsletter tool, invoicing software and so on. When a message arrives claiming to be from you, the receiving server checks whether it came from a service on the list.

An SPF record is one TXT record on your domain. For a business on Google Workspace that also sends through SendGrid, it looks like this:

yourdomain.com   TXT   "v=spf1 include:_spf.google.com include:sendgrid.net -all"

In plain English: "Mail from this domain comes from Google and SendGrid. Reject anything else." The -all at the end is the "reject everything else" part. Each sending service tells you exactly what include: line to add.

SPF's limits: it checks a behind-the-scenes sender address rather than the "From" address people see, and it breaks when mail is forwarded. Helpful, but leaky on its own.

DKIM: the tamper-proof seal

DKIM (DomainKeys Identified Mail) puts a digital signature on every message you send. Your mail service holds a private key and signs each message with it; you publish the matching public key in DNS so anyone can check the signature. A valid signature proves the message really came from your domain and wasn't altered on the way. A scammer can't forge it without your private key.

The public key sits at a "selector" name under your domain and looks like this (the real key is much longer):

selector1._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ...QAB"

You almost never write this yourself. Your email provider generates it and gives you the record to paste in, and each sending service gets its own selector, so several DKIM records is normal. In Microsoft 365 and Google Workspace you also have to switch DKIM signing on in the admin center after publishing the record.

DMARC: the instructions for everyone else

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two together. It does three jobs.

  • Alignment. It requires that the domain which passed SPF or DKIM matches the domain in the visible "From" address. This is what actually stops someone from passing the checks with an unrelated domain while showing your name.
  • Policy. It tells receiving servers what to do with mail that fails: none (deliver it anyway and report), quarantine (send it to spam) or reject (refuse it).
  • Reports. It asks receiving servers to send you daily summaries of who is sending mail as your domain and whether it passed.

A starter DMARC record looks like this:

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Here p=none is the policy and rua= is where the reports go.

Your setup plan

  1. List every service that sends email as your domain. Email host, newsletter platform, invoicing or CRM tool, booking software, online shop, website contact form. You can't authenticate what you haven't found.
  2. Publish one SPF record that includes all of them and ends in -all. Only one SPF record per domain; two records break it.
  3. Turn on DKIM in every sending service and publish the record each one gives you.
  4. Publish DMARC with a policy of none and a reporting address, as in the example above.
  5. Send the reports to a reader. Raw DMARC reports are XML files that are miserable to read. Free and low-cost dashboards (dmarcian, Valimail, Postmark and others) turn them into a simple list of who is sending as you and whether they pass. Point your rua= address at one.
  6. Watch for two to four weeks and fix the gaps. Every legitimate sender should pass. Anything failing that you recognize is a service you missed; anything you don't recognize is likely someone spoofing you.
  7. Move to quarantine, then reject. Change p=none to p=quarantine, watch for another couple of weeks, then change it to p=reject. This is the step that actually stops spoofing.
  8. Re-run the two-minute check whenever you add a new tool that sends email.

Don't jump straight to reject on day one. If your invoicing tool isn't set up yet, you'll block your own invoices. Monitoring first is how you find the surprises safely.

Why "none" isn't protection

A DMARC record set to none is a security camera with the doors unlocked: you get reports, but fake mail still lands in inboxes. Plenty of businesses publish the record, see it listed as "present" in a checker and stop there. Protection starts at quarantine and is complete at reject.

What DMARC can't do is stop lookalike domains. If a scammer registers yourbusinesss.com (three s's) and sets up their own records, their mail can pass every check because they really do own that domain. That's why the human rule in our BEC guide, confirming any payment change by phone on a number you already have, still matters.

A bonus once you're at enforcement: BIMI

With DMARC at quarantine or reject, you can publish one more record, BIMI (Brand Indicators for Message Identification), to show your logo next to your emails in supporting inboxes such as Gmail. It needs a mark certificate from a certificate authority. Since September 2024 Gmail also accepts Common Mark Certificates, which don't need a registered trademark, so smaller brands can use it. It's optional, and it costs money; the security work above doesn't.

When to call someone

  • The lookup shows two SPF records, or SPF errors you can't untangle.
  • Your reports show a sender you can't identify, and you're not sure whether it's yours or an impostor.
  • You're ready to move to reject but worried about blocking your own invoices or newsletters.
  • Customers are already receiving fake email from your address.

This is fiddly, unglamorous work, and it's part of what our cybersecurity service handles if you'd rather not own it.

Related reading