Scammers can email as your company: SPF, DKIM and DMARC explained
SPF lists who may send your email, DKIM signs it, and DMARC says what to do when neither passes for your From domain: start at p=none, then tighten it.
UB Web Developers team
Anyone can put your company's address in the From line of an email, and SPF, DKIM and DMARC are the three DNS records that let receiving mail servers tell your real mail from the fakes. Publish all three, start DMARC in monitoring mode (p=none), and move to quarantine and then reject only once its reports show your own mail passes.
Why can scammers send email from my domain?#
"By design," Microsoft (opens in new tab) explains, internet email "makes no effort to validate that the message sender is who they claim to be." Every message carries two senders: a hidden envelope address used for bounces, and the From address people see. SPF and DKIM on their own don't check that the domain they verify matches that visible From address. DMARC adds that check.
Gmail and Yahoo made these records a delivery rule in February 2024, a change Google announced (opens in new tab) on 3 October 2023. Google's sender guidelines (opens in new tab) cover mail sent to personal Gmail accounts, the addresses ending in @gmail.com or @googlemail.com. Everyone who sends to them must set up SPF or DKIM. Anyone sending more than 5,000 messages a day to those accounts needs SPF, DKIM and a DMARC record, with the From domain aligned. Yahoo's rules (opens in new tab) match: bulk senders need SPF and DKIM, plus DMARC at "at least p=none". Since November 2025, Google says (opens in new tab), mail that doesn't comply faces "temporary and permanent rejections".
What does each record do?#
SPF (Sender Policy Framework, RFC 7208 (opens in new tab), April 2014) is a TXT record on your domain that lists the servers allowed to send its mail. The receiving server checks the envelope sender's domain against that list. A domain may have only one SPF record, and checking it may take no more than 10 DNS lookups. Break either rule and SPF fails with a permanent error (Microsoft (opens in new tab)).
DKIM (DomainKeys Identified Mail, RFC 6376 (opens in new tab), September 2011) adds a digital signature to each message. Your mail provider signs with a private key, and you publish the matching public key in DNS under a selector name, such as google._domainkey.example.mn. A valid signature shows that the signing domain took responsibility for the message and that the signed parts weren't changed on the way.
DMARC (RFC 7489 (opens in new tab), March 2015, replaced by RFC 9989 (opens in new tab) in May 2026) is a TXT record at _dmarc.example.mn. A message passes DMARC when SPF or DKIM passes for a domain that matches the From address. The record tells receivers what to do with mail that fails (p=none, p=quarantine or p=reject) and where to send reports (Microsoft (opens in new tab)).
| Detail | SPF | DKIM | DMARC |
|---|---|---|---|
| Question it answers | Is this server allowed to send for the domain? | Did the domain sign this message, and is it unchanged? | Does a passing check match the From address, and what happens if not? |
| Where it lives | TXT at example.mn | Key at selector._domainkey.example.mn | TXT at _dmarc.example.mn |
| Domain it checks | Envelope sender | The signing domain (d=) | The visible From address |
| After forwarding | Usually breaks | Usually survives if the message isn't changed | Passes if an aligned DKIM signature survives |
| Standard | RFC 7208 (2014) | RFC 6376 (2011) | RFC 9989 (2026), replacing RFC 7489 (2015) |
| Our security check reads it | Yes | No | Yes |
Does this affect my business?#
Yes, if your company sends email from its own domain. Without a DMARC policy of quarantine or reject, receivers have no instruction from you to stop mail that fakes your exact domain (Microsoft (opens in new tab)).
Our free security check reads a domain's SPF and DMARC records. One SPF record ending in -all or ~all passes. A DMARC policy of quarantine or reject passes, and p=none shows as a warning. It doesn't read DKIM, because a DKIM key sits under a selector name that appears only inside your sent mail (RFC 6376 (opens in new tab)). To check DKIM, send a message to a mailbox at another provider, open its headers, and look for dkim=pass next to your domain in the Authentication-Results line, as in Microsoft's example (opens in new tab).
What does a sensible starting setup look like?#
These examples use example.mn. Your mail provider gives you the exact values, so copy theirs.
| Record | Name (host) | Type | Example value |
|---|---|---|---|
| SPF, Google Workspace only | example.mn | TXT | v=spf1 include:_spf.google.com ~all |
| SPF, Microsoft 365 only | example.mn | TXT | v=spf1 include:spf.protection.outlook.com -all |
| DKIM, Google Workspace | google._domainkey.example.mn | TXT | The public key from the Google Admin console |
| DKIM, Microsoft 365 | selector1._domainkey and selector2._domainkey | CNAME | The two values from the Microsoft Defender portal |
| DMARC, first weeks | _dmarc.example.mn | TXT | v=DMARC1; p=none; rua=mailto:dmarc-reports@example.mn |
A few details trip people up:
- If a newsletter tool or CRM also sends as you, add it to the same SPF record, or move it to a subdomain such as news.example.mn with its own record, as Microsoft suggests (opens in new tab).
- For Google, after you add the DKIM record, click Start authentication in the Admin console. Choose a 2048-bit key if your DNS host supports it (Google (opens in new tab)).
- Set up SPF and DKIM at least 48 hours before DMARC (Google (opens in new tab)).
- The rua address gets aggregate reports, usually daily, as XML files that a DMARC reporting service can make readable (Microsoft (opens in new tab)).
For a domain you own but never send email from, Microsoft recommends v=spf1 -all and a DMARC record of v=DMARC1; p=reject (SPF guide (opens in new tab), DMARC guide (opens in new tab)). Before you publish those, check that nothing sends from it, including a website contact form or an invoicing tool.
How do I move from p=none to p=reject?#
In steps, with the reports in front of you. A p=reject policy on day one can bounce your own invoices if a tool you forgot sends as your domain, and Microsoft (opens in new tab) calls some false positives "almost inevitable".
- p=none. Google recommends (opens in new tab) at least one week, checking reports daily. Find every service that sends as you and fix SPF or DKIM for each.
- p=quarantine. Receivers accept failing mail but mark it, for example by putting it in the spam folder (Microsoft (opens in new tab)). Move here once the reports show your own mail passing.
- p=reject. Failing mail is refused. Microsoft (opens in new tab) suggests starting with a low-volume subdomain and doing the main domain last.
The new standard agrees. RFC 9989 (opens in new tab) says domain owners usually start with p=none, and that problems found in SPF and DKIM must be fixed before an enforcing policy. It also removed the pct tag that Google's and Microsoft's guides use to apply a policy to only part of your mail, so plan each step as if it applies to all failing mail.
What can't these records stop?#
DMARC protects your exact domain. It doesn't stop a lookalike domain with one letter changed, or a scammer who puts your company name on a free email address. In April 2026 Guardio Labs (opens in new tab) found phishing emails posing as Meta Support that passed SPF, DKIM and DMARC, because they were sent through a Google service. In Guardio's words, that "proved only that the sending platform was legitimate, not that the message itself was." Teach your team to read the address and the request, not just the logo.
Sources#
- IETF, RFC 7208: Sender Policy Framework (SPF) (opens in new tab), April 2014
- IETF, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures (opens in new tab), September 2011
- IETF, RFC 7489: DMARC (opens in new tab), March 2015
- IETF, RFC 9989: DMARC (opens in new tab), May 2026
- Google, Email sender guidelines (opens in new tab), Gmail Help
- Google, Email sender guidelines FAQ (opens in new tab), Gmail Help
- Google, New Gmail protections for a safer, less spammy inbox (opens in new tab), 3 October 2023
- Google, Set up SPF (opens in new tab), Set up DKIM (opens in new tab) and Recommended DMARC rollout (opens in new tab), Google Workspace Admin Help
- Microsoft, How email authentication works (opens in new tab), Microsoft Learn
- Microsoft, Set up SPF (opens in new tab), Set up DKIM (opens in new tab) and Set up DMARC (opens in new tab), Microsoft Learn
- Yahoo, Sender best practices (opens in new tab), Yahoo Sender Hub
- Guardio Labs, AccountDumpling (opens in new tab), 29 April 2026
Frequently asked questions#
Do I need SPF, DKIM and DMARC, or is one enough?#
Set up all three, whatever your volume: that is our advice. Gmail's own rules are narrower and cover mail to personal Gmail accounts (@gmail.com or @googlemail.com). Gmail (opens in new tab) requires SPF or DKIM from everyone who sends to those accounts, and SPF, DKIM and DMARC from anyone sending them more than 5,000 messages a day. DMARC needs SPF or DKIM to pass for your domain, and DKIM usually survives forwarding when SPF doesn't (Microsoft (opens in new tab)).
Should my SPF record end in -all or ~all?#
Follow your mail provider. Google (opens in new tab) recommends ~all for Google Workspace, and Microsoft (opens in new tab) recommends -all for Microsoft 365. DMARC counts both as an SPF failure.
Is p=none enough?#
It is the right first step, and Gmail (opens in new tab) and Yahoo (opens in new tab) accept it for bulk senders. But p=none only collects reports. It doesn't ask receivers to stop fake mail (Microsoft (opens in new tab)), so move to p=quarantine and then p=reject once the reports show your own mail passes.
Can I have two SPF records, one for each email service?#
No. Two SPF records on one domain make SPF fail with a permanent error. Put every service into one record and keep it to 10 DNS lookups or fewer (Microsoft (opens in new tab)).
Will DMARC stop all phishing that uses my company's name?#
No. It protects your exact domain. It doesn't stop lookalike domains, free email addresses that use your company name, or phishing sent through other trusted services, such as the fake Meta Support emails that Guardio Labs (opens in new tab) found passing DMARC.