Look up the SPF and DMARC records on any domain and see your DMARC policy strength. Missing or weak records let scammers send email as your brand and hurt deliverability.
⚡ Interactive demo — sample data
SPF found, DMARC found but set to monitor-only — this sample domain can still be spoofed in practice.
SPFv=spf1 include:_spf.example-mail.com ~all — record presentLooks good
DMARCv=DMARC1; p=none; rua=mailto:reports@example.com — record presentLooks good
DMARC policyp=none — monitoring only; move to quarantine, then reject, to actually block spoofingWarning
Look up the SPF and DMARC records on any domain and see your DMARC policy strength. Missing or weak records let scammers send email as your brand and hurt deliverability.
How it works
Enter your domain
Type your bare domain — example.com, not a full URL or an email address. We query your domain's public DNS for the TXT records that govern who is allowed to send email as you: SPF on the root domain and DMARC on the _dmarc subdomain.
We read your SPF and DMARC records
We pull the actual record text and parse it. For DMARC we extract the policy (p=none, quarantine or reject) so you can see whether you're only monitoring spoofing or actively blocking it. DKIM is selector-specific, so we point you at the common selectors to check with your email provider.
Fix the gaps and re-run
Add or tighten the records flagged as missing or weak in your DNS, wait for the change to propagate (usually minutes to a couple of hours), then re-run the check to confirm SPF, DMARC and your DMARC policy all read clean.
What we check
SPF record — Checks for a valid TXT record starting with v=spf1 on your root domain. SPF lists the mail servers allowed to send for you. Without it, anyone can forge mail from your domain and receiving servers have no way to tell real from fake.
DMARC record — Looks for a v=DMARC1 TXT record on _dmarc.yourdomain.com. DMARC tells receiving servers what to do with mail that fails SPF or DKIM, and is the record that actually stops spoofed mail from landing in inboxes.
DMARC policy strength — Reads the p= value in your DMARC record. p=none only monitors and reports — it blocks nothing. p=quarantine sends failing mail to spam, and p=reject rejects it outright. We flag p=none so you know you're not yet protected.
DKIM guidance — DKIM signs your outgoing mail with a cryptographic key published at a provider-specific selector (like google, k1, s1 or default). Because the selector varies by sender, we point you to the common ones to verify with your email platform rather than guessing.
Raw record text — Returns the full text of each record found, so you can see includes, mechanisms and qualifiers exactly as published — useful when an SPF record is present but built incorrectly.
Authentication score — Summarizes how complete your setup is — SPF present, DMARC present and policy enforcing — into a single readout so you can tell at a glance whether your domain is genuinely protected or just partially configured.
Common issues we catch
DMARC stuck on p=none — The most common gap. A p=none record looks like 'DMARC is set up,' but it only collects reports — it tells servers to take no action on spoofed mail. You're monitoring, not protected. The fix is to move to p=quarantine, then p=reject, once your reports confirm legitimate senders pass.
No SPF record at all — Without SPF, receiving servers can't verify which servers may send for you, so forged mail from your domain has nothing stopping it. New domains and small businesses frequently never set this up.
Multiple SPF records — A domain may only have one SPF TXT record. Two records (often added by different teams or services) is invalid and many receivers will fail SPF entirely, which can hurt your own legitimate mail. Merge them into a single record.
SPF too many DNS lookups — SPF allows a maximum of 10 DNS lookups when evaluating includes. Stacking too many third-party 'include:' mechanisms blows past the limit and causes a permerror — SPF silently breaks even though the record looks fine.
DKIM selector mismatch — DKIM only works if the public key is published at the exact selector your mail platform signs with. Switching providers or having an old selector left behind means signatures fail validation, quietly dragging down deliverability.
DMARC record on the wrong host — DMARC must live at _dmarc.yourdomain.com, not the root. A record published on the root domain isn't seen as DMARC, so the policy never applies even though you added it.
Weak SPF qualifier (~all or +all) — An SPF record ending in +all authorizes everyone — worse than no record. ~all (softfail) is permissive too. For enforcement you generally want -all (hardfail) once you're confident every legitimate sender is listed.
Where this matters
Gmail & Google Workspace — Google requires bulk senders to authenticate with SPF, DKIM and DMARC, and downranks or rejects unauthenticated mail. A clean setup here is essential to land in Gmail inboxes rather than spam.
Microsoft 365 & Outlook — Outlook.com and Microsoft 365 check SPF and DMARC and apply your policy. Missing or weak records mean your mail is more likely to be filtered, and your domain is easier to impersonate in phishing.
Email marketing & transactional senders — Newsletter, CRM and transactional sending platforms ask you to add their include to SPF and publish their DKIM selector. If those aren't in place, campaigns and receipts fail authentication and bounce or spam-folder.
DNS providers — SPF, DMARC and DKIM all live as TXT records in your DNS. Wherever your domain's DNS is hosted, these are the records you'll add or edit — and DNS caching is why changes take time to show up.
Receiving mail servers — Every inbox provider that receives your mail reads these records to decide deliver, spam-folder or reject. Strong, consistent authentication is what builds and protects your sending reputation across all of them.
Frequently asked questions
What's the difference between SPF, DKIM and DMARC?
SPF lists which servers may send mail for your domain. DKIM cryptographically signs each message so receivers can verify it wasn't tampered with. DMARC ties them together — it tells receivers what to do when a message fails SPF or DKIM, and where to send reports. You want all three.
What does p=none, p=quarantine and p=reject mean?
These are DMARC policies. p=none takes no action and only reports — it does not stop spoofing. p=quarantine sends failing mail to the spam folder. p=reject blocks it outright. Start at none to monitor, then tighten to quarantine and finally reject once you've confirmed your real senders pass.
Why is my email going to spam even though I have SPF?
SPF alone isn't enough for modern inbox providers. Without DKIM and an enforcing DMARC policy, your mail can still be filtered. SPF can also be misconfigured — too many DNS lookups, multiple records, or a permissive +all — which breaks it silently. Check all three records together.
What is a DKIM selector and why do I need it?
A DKIM selector is a label that points to the public key your mail platform uses to verify signatures, published at selector._domainkey.yourdomain.com. Each provider uses its own selector (google, k1, s1, default and others), which is why DKIM has to be checked against your specific email platform.
Can scammers really send email as my domain?
Yes. Without SPF and an enforcing DMARC policy, anyone can put your domain in the From address and most receivers can't tell it's fake. This is how phishing and business-email-compromise scams impersonate brands. Proper authentication is what shuts that down.
How long do DNS changes take to apply?
Usually minutes to a couple of hours, sometimes longer depending on the previous record's TTL and DNS caching. After you add or edit a record, re-run the check periodically until it shows up, rather than assuming it failed.
Will adding these records ever block my own email?
It can if you skip the monitoring step. That's why DMARC is designed to start at p=none — you collect reports, confirm every legitimate sender passes SPF or DKIM, then tighten the policy. Jumping straight to p=reject before listing all your senders is the main risk.
Do these records affect my SEO?
Not directly, but they protect your brand and your email deliverability, which underpin the trust your audience has in messages from you. A spoofed domain damages reputation, and poor deliverability undermines the campaigns and outreach that support your site's growth.
This is one of several free SEO tools from Custom Web Audits.
For a complete, prioritized analysis of your whole website,
run a full audit.
