Shypset

Email spoofing: SPF and DMARC for your domain

You bought a domain for your app, and with it the risk that someone else sends email from it. SPF and DMARC are two DNS records that tell mail servers what to do with messages that only pretend to be yours. Many new domains have neither.

Public Runs on every scan. We only read what a browser or a public lookup would.

What it is

SPF is a TXT record that lists the servers allowed to send mail for your domain, for example v=spf1 include:_spf.google.com ~all. DKIM signs your outgoing mail with a key published in DNS. DMARC, a TXT record at _dmarc.yourdomain.com, ties them together: it tells receivers whether to accept, quarantine or reject mail that fails the checks, and where to send reports. You need all three for receivers to trust your mail and distrust forgeries.

What can happen

Without DMARC enforcement, anyone can send an email with your domain in the From line: a fake password reset, an invoice from “billing@yourapp.com”, a message to your users asking them to log in on a lookalike site. Your users cannot tell the difference. As a side effect, your own transactional mail is more likely to land in spam, because receivers cannot tell your real messages from fakes.

How Shypset checks it

This is a Public check: we read your public DNS records, the same lookup any mail server makes. We report:

  • No SPF record, or more than one, which makes SPF invalid.
  • SPF that allows everyone (+all) or only says “neutral” (?all).
  • SPF over the limit of 10 DNS lookups, which makes it fail at receivers.
  • No DMARC record, a p=none policy that only monitors, or a policy applied to only part of the mail.
  • Missing DMARC aggregate reports (rua) and no DKIM key on common selectors.

We also look at MTA-STS, TLS-RPT and BIMI, and combine everything into an email security grade in the report.

How to fix it

  • Publish one SPF record listing every service that sends mail for you (your mailbox provider, your transactional email service), ending in ~all or -all.
  • Turn on DKIM in each of those services and add the DNS records they give you.
  • Add _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com to start collecting reports.
  • After a couple of weeks with clean reports, move to p=quarantine, then p=reject.
  • If the domain sends no mail at all, publish v=spf1 -all and p=reject.

Example finding

How the finding looks in a report, with its fix prompt.

mediumNo DMARC Record Found

Evidence

DNS TXT _dmarc.example.com: no record
SPF: v=spf1 include:_spf.google.com ~all

Fix prompt

Our domain example.com has SPF but no DMARC record. Give me the exact DNS records to add: a DMARC TXT record at _dmarc with p=none and an rua address for reports, plus the DKIM records for the services in our SPF. Then give me a short plan for moving to p=quarantine and p=reject.

Questions

My app does not send email. Do I still need this?
Yes. A domain with no records is easy to spoof. Publish a reject-all SPF and DMARC policy.
Do you send any email to test this?
No. We only read public DNS records.

Check your email records

Paste your URL on the home page; email security is part of every scan.

Check your domain

Related checks