SPF, DKIM and DMARC: How to Stop Email Spoofing Step by Step

In short: SPF lists the servers allowed to send mail for your domain, DKIM signs each message, and DMARC checks that one of them passes for the domain in the visible From address, then tells receivers what to do with mail that fails. Since February 2024, Gmail and Yahoo require SPF or DKIM from every sender and SPF, DKIM and DMARC from bulk senders, and Gmail has been enforcing harder since November 2025. Publish one SPF record, turn on DKIM at every service that sends for you, start DMARC at p=none with reports, and move to p=quarantine or p=reject once your legitimate mail passes.

Email was designed without any proof of who sent a message. Anyone can put [email protected] in the From line, and without authentication records, the receiving server has no way to tell that it's fake. That's how invoice fraud and phishing in your name work, and it's also why your real mail can look suspicious to Gmail.

SPF, DKIM and DMARC fix this with three DNS records. This guide explains how they fit together, what the big mailbox providers require, how our free SPF and DMARC checker reads your domain, and how to get from no records to an enforced policy without breaking your own mail.

How SPF, DKIM and DMARC work together

The weak spot of SPF and DKIM alone is the "which domain" row. RFC 7208 says SPF checks the MAIL FROM and HELO identities, which the recipient never sees. A spoofer can pass SPF for their own domain while showing yours in the From line. DMARC closes that gap with alignment: a message passes DMARC only if SPF or DKIM passes for a domain that matches the From domain (relaxed alignment allows subdomains of the same organization).

SPF in one record

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

Each include authorizes a provider's servers; -all at the end says everything else fails. RFC 7208 defines the qualifiers: - is fail, ~ is softfail ("probably not authorized"), ? is neutral and + is pass. +all authorizes the entire internet and defeats the purpose.

DKIM in one record

Your mail provider signs outgoing messages with a private key and gives you a public key to publish under a selector, for example google._domainkey.example.com. Each sending service uses its own selector, so you can have several DKIM keys at once (RFC 6376).

DMARC in one record

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p is the policy for the domain, sp for subdomains, and rua receives daily aggregate reports from receivers listing which servers sent mail as your domain and whether it passed.

The DMARC standard was updated in 2026

In May 2026 the IETF published RFC 9989, which obsoletes the original DMARC specification, RFC 7489, and moves DMARC to the Standards Track. Existing records keep working; the version tag is still v=DMARC1. The changes worth knowing:

• pct is removed. The RFC says it "was usually not accurately applied." A new t tag ("testing") replaces it: t=y asks receivers not to apply the policy, roughly like the old pct=0.
• np is added, a policy for non-existent subdomains.
• rf and ri are removed, and a DNS "tree walk" replaces the Public Suffix List for finding the organizational domain.

Receivers will move to the new rules at different speeds, and Google's own setup guide still recommends pct during rollout. Using pct doesn't break anything, but don't rely on it as a precise percentage.

What Gmail and Yahoo require

Both providers started enforcing sender requirements in February 2024.

Sources: Google's sender guidelines and Yahoo's sender best practices. Google warns that unauthenticated messages "might be marked as spam or rejected with a 5.7.26 error," and its FAQ says: "Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic," with temporary and permanent rejections. The same FAQ recommends aligning DMARC with both SPF and DKIM and says that alignment will likely become a requirement later.

Even if you send far fewer than 5,000 messages a day, these records decide whether your invoices, password resets and replies reach the inbox, and whether someone else can send convincing mail in your name.

How the Searvia SPF and DMARC checker works

The free SPF and DMARC checker is part of our website SEO checker and shows the email authentication check first. Enter a domain (a leading www. is removed) and it:

1. Looks up the TXT records of the domain and takes the ones that start with v=spf1. More than one is flagged, because SPF then fails.
2. Counts the DNS lookups the SPF record needs (include, a, mx, ptr, exists and redirect, following each include one level deep) and flags more than 10.
3. Looks up the TXT records of _dmarc. plus the domain and takes the one that starts with v=DMARC1.
4. Reads the p= policy from the DMARC record and checks for a rua report address.
5. Shows both records in full, with a tick or cross, and a DKIM row marked "Not checked".

In the overall audit this check has medium priority. Note how strict it is about DMARC: p=none meets Gmail's minimum but still shows a warning, because it doesn't stop spoofing.

What the free check does not cover:

• DKIM. DKIM keys sit under selectors chosen by each mail service, and there is no way to list them from DNS, so the report marks DKIM as not checked. Check DKIM in your mail provider's admin panel or in the headers of a message you sent (look for dkim=pass).
• All of SPF's rules. It flags duplicate records and more than 10 lookups, but not whether the record ends in -all or ~all. Includes are followed one level deep, so a deeply nested record can need more lookups than the count shows.
• DMARC details. It reads p= and checks for rua, but not sp= or alignment settings.

How to read your result

• Fail: your domain is open to spoofing and your mail misses requirements at Gmail and Yahoo. Start at step 1 below.
• "DMARC is missing" or "SPF is missing": half done. Add the missing record.
• "DMARC is set to none": the most common result. You are collecting reports (if rua is set), which is the right first stage. Plan the move to enforcement.
• Pass: good. Check the parts the free tool can't see: DKIM for every sender, deeply nested SPF includes and the sp policy for subdomains.

How to fix it, step by step

Step 1: List everything that sends mail as your domain

Your mailbox provider (Google Workspace, Microsoft 365), newsletter tool, CRM, help desk, invoicing software, e-commerce platform, website contact form and any server that sends notifications. Missing one here is the main reason DMARC enforcement goes wrong later.

Step 2: Publish one SPF record

1. Collect the include: value each provider documents.
2. Combine them into one record. RFC 7208 is explicit: if more than one SPF record exists, the result is "permerror".
3. End with ~all while you test, then -all.
4. Count lookups. include, a, mx, ptr, exists and redirect each cost a DNS lookup, and the limit is 10, including lookups inside nested includes. Over 10 is a permerror. Remove services you no longer use, and drop ptr, which the RFC says "SHOULD NOT be published."

If a provider sends with its own envelope domain (common for newsletter tools), it doesn't need to be in your SPF at all; it needs DKIM with your domain for DMARC to pass.

Step 3: Turn on DKIM for every sender

In each service, find the domain authentication or DKIM setting, publish the record it gives you (a TXT or CNAME under a selector) and activate signing. Google recommends allowing 48 hours after setting up SPF and DKIM before adding DMARC. Then send a test message to a Gmail address and check "Show original": you want SPF: PASS, DKIM: PASS and DMARC: PASS.

Step 4: Publish DMARC at p=none with reports

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Google recommends starting with p=none and always including rua. Aggregate reports are XML files; a DMARC report service or a parser makes them readable. If the report address is on another domain, that domain has to authorize it with a DNS record.

Step 5: Read the reports and fix failures

For two to four weeks, look for legitimate services that fail SPF or DKIM alignment. Each one needs DKIM signing with your domain or an SPF include. Forwarded mail and mailing lists can fail for legitimate reasons; RFC 9989 suggests that domains whose users post to mailing lists spend at least a month at p=none and a similar period at p=quarantine before p=reject.

Step 6: Move to quarantine, then reject

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Change one step at a time and keep watching reports. When you reach p=quarantine, our checker passes. p=reject is the goal: receivers refuse mail that fails.

Step 7: Lock down domains that don't send mail

Parked domains and redirect-only domains are attractive to spoofers because nobody watches them. The UK government's guidance recommends:

example.net.               TXT  "v=spf1 -all"
_dmarc.example.net.        TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
*._domainkey.example.net.  TXT  "v=DKIM1; p="
example.net.               MX   0 .

Check the records yourself

The checker reads SPF and DMARC; you can see all three records with standard DNS tools. On macOS or Linux:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT google._domainkey.example.com

On Windows, nslookup -type=TXT _dmarc.example.com does the same. For DKIM you need the selector, which your provider shows in its DKIM settings and which appears as s= in the DKIM-Signature header of any message you sent; google is the default for Google Workspace. Some providers publish the key as a CNAME that points to their own DNS, which is fine.

The most reliable end-to-end test is a real message. Send one from each service to a Gmail address and open "Show original": it lists the SPF, DKIM and DMARC result and the domain each one passed for. A DKIM pass for the provider's domain instead of yours means DMARC alignment still fails, so look for your own domain in the result.

Common mistakes

Worked example (hypothetical)

The following is a hypothetical example, not real data. Pinecrest Dental, an invented clinic, hears from patients that they received a fake payment request "from" the clinic. The SPF and DMARC checker shows:

• SPF: v=spf1 include:_spf.google.com ~all
• DMARC: missing. Result: warning, "DMARC is missing."

Step 1 finds three senders: Google Workspace, the booking system that emails reminders and an email newsletter tool. The booking system needs an SPF include; the newsletter tool uses its own envelope domain, so it gets DKIM with the clinic's domain instead. The clinic publishes DMARC at p=none with a report address. Two weeks of reports show the booking system passing SPF and the newsletter passing DKIM, plus a few hundred messages from unknown servers in other countries failing both: the spoofing. The clinic moves to p=quarantine, where the checker passes, and a month later to p=reject. Fake messages in its name are now refused by receivers that apply DMARC.

A checklist you can finish this week

1. Run the SPF and DMARC checker on every domain you own, including parked ones.
2. List all services that send mail as your domain.
3. Merge SPF into one record, under 10 lookups, ending in ~all or -all.
4. Turn on DKIM in each service and test with "Show original" in Gmail.
5. Publish DMARC at p=none with rua, and read the reports.
6. Move to p=quarantine, then p=reject.
7. Publish v=spf1 -all and p=reject on domains that send nothing.

How Searvia watches your email authentication

The free SPF and DMARC checker reads your records in seconds, with no sign-up, as part of a 38-check audit that also covers your website's search appearance, speed and security.

A free Searvia account adds a weekly security scan that goes further on email: it flags an SPF record that is missing or too open (+all, ?all or no all at all), a DMARC policy that is missing or still p=none, and a missing CAA record, with the DNS lookup behind each finding and a record you can copy. The scan repeats every Thursday, so a DNS change that breaks your records shows up within a week. For the website side of security, see our security headers guide.