SPF, DKIM, DMARC: Stop Attackers From Sending Email as Your Domain

Email runs on a protocol from 1982 that takes the sender’s word for it: the “From” address is just text, and nothing in SMTP itself verifies it. Unless you publish the right DNS records, anyone can send mail that claims to be from your domain — to your customers, your suppliers, or your own team. Three TXT records close that gap, and you can set them up in an afternoon.

The problem: email believes whatever the sender types

A mail server receiving a message has no built-in way to check that billing@yourcompany.com really sent it. Attackers rely on this and automate it: tooling scans the internet for domains without email authentication, because their mail can be forged convincingly. A small site is not too small to be found — it is simply next on the list.

What that looks like in practice:

• Phishing your customers.“Your account will be suspended, click here” — sent from your real domain, so it passes the eyeball test.
• Invoice fraud.A fake “we’ve updated our bank details” email to your suppliers, apparently from your finance address.
• Internal spear-phishing.A password-reset lure to your own team, “from” your founder.

None of this requires breaking into anything. It only requires that your DNS is silent about who may send as you.

The trio, in plain words

SPF — which servers may send.SPF (RFC 7208) is a TXT record listing the mail servers authorized to send for your domain. When mail arrives, the receiver checks whether the connecting server’s IP is on your list.

DKIM — a tamper-evident seal. With DKIM (RFC 6376), your mail provider signs every outgoing message with a private key. The matching public key is published in your DNS. Receivers verify the signature; if the message was forged or altered in transit, verification fails.

DMARC — instructions for the bouncer. DMARC (RFC 7489) ties the two together. It tells receivers what to do when a message fails alignment with SPF and DKIM — deliver anyway (p=none), send it to spam (p=quarantine), or refuse it (p=reject) — and where to send aggregate reports showing who is sending as your domain.

You need all three. SPF and DKIM only produce pass/fail signals; DMARC is the record that tells the world to act on them.

Why p=none is only a starting point

p=nonemeans “check, but deliver anyway.” It is the right first step — reporting without risking legitimate mail — and zero protection if you stop there. Three traps show up constantly:

• Permanent monitoring mode. The DMARC record was added years ago with p=none and never revisited. Spoofed mail still lands in inboxes.
• Partial enforcement. pct=50 applies your policy to only half of failing mail, and sp=none exempts every subdomain — so forged mail from anything.yourcompany.com sails through.
• Broken records. Two SPF records, more than 10 DNS lookups, or a syntax error each cause a permanent error — receivers then behave as if your policy did not exist.

A malformed record is quieter than a missing one, which is why it is worth verifying rather than assuming.

Example records

A reasonable SPF record lists only the services that actually send for you:

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

-all means “everything else fails.” The softer ~all is fine during rollout.

DMARC at enforcement, with reporting:

_dmarc.yourcompany.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com"

and the end goal:

_dmarc.yourcompany.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com"

Your email provider (Google Workspace, SendGrid, Postmark) generates DKIM records for you, published at selector._domainkey.yourcompany.com. Enable DKIM in every service that sends as you, and remove keys for cancelled services — a revoked key still in DNS is one more thing failing silently.

Gmail and Yahoo made this mandatory

Since February 2024, Google and Yahoo require bulk senders (5,000+ messages a day to Gmail) to publish DMARC, sign with DKIM, and pass alignment — and every sender, whatever the volume, needs at least SPF or DKIM to reach inboxes reliably. Microsoft followed in 2025. Email authentication is now a deliverability requirement, not just a security control. If your password-reset emails drift into spam, look here first.

The supporting cast

Once the trio is in place, a few smaller records round out your domain’s posture:

• MTA-STS (RFC 8461) tells sending servers to require TLS when delivering mail to you.
• TLS-RPT (RFC 8460) sends you reports when that TLS delivery fails.
• BIMI displays your logo next to authenticated mail — and only works once DMARC is at enforcement.
• DNSSEC signs your DNS answers so resolvers can detect forged responses.
• CAA (RFC 8659) lists which certificate authorities may issue certificates for your domain — a one-line record that closes off mis-issuance. (Certificates have their own failure modes; see our TLS guide.)

How to check your domain right now

dig TXT yourcompany.com +short
dig TXT _dmarc.yourcompany.com +short

On Windows, use nslookup -type=TXT _dmarc.yourcompany.com. You want exactly one SPF record ending in -all or ~all, and a DMARC record whose p= is not none. While the zone is open, also look for forgotten records pointing at services you no longer use — see our subdomain takeover guide.

A staged rollout that won’t break your mail

1. Inventory your senders.Workspace or 365, transactional email, marketing platform, CRM, support desk — anything that sends “from” you.
2. Publish SPF and enable DKIM in each of those services.
3. Publish DMARC with p=none and a rua= reporting address. Let reports accumulate for two to four weeks.
4. Fix legitimate failures. Anything of yours failing in the reports is a sender you forgot in step 1.
5. Move to p=quarantine, then p=reject. Ramp pct=upward if you want to be careful — just don’t stop halfway.
6. Re-check whenever you add a tool. A new email service means a new include or DKIM key.

If you built your product with Cursor, Lovable, or Bolt, this is a classic gap: the AI scaffolds your app, but nobody scaffolds your DNS. Our vibe-coding security guide covers the other things that fall into that gap.

How BoringSec checks this

BoringSec’s DNS scanner is one of 24 runtime scanner modules, and it checks 11 record families: SPF, DMARC (including malformed and partial-enforcement policies), DKIM (including revoked keys), CAA, MTA-STS, SMTP TLS reporting, BIMI, DANE/TLSA, MX, DNSSEC (including broken chains), and nameserver posture. Every check is grounded in the relevant RFC, and the raw records we observed are captured as evidence in your report, so you can verify each finding yourself. That is deliberate: critical or high findings without captured proof are automatically downgraded to medium — we don’t sell fear. The full scoring model is documented in our methodology.

FAQ