SPF and DMARC Check for Your Domain

When you ship an app or a store, the domain in your support email and store listing becomes part of your brand. If that domain has no email authentication, anyone can send mail that appears to come from you: fake "password reset" notices, fake invoices, fake refund offers aimed at your own customers. SPF and DMARC are the two DNS records that make spoofing your domain hard, and an SPF DMARC check looks for them before reviewers, partners, or attackers do.

For an indie developer or small store owner, this gap stays invisible until it bites — deliverability quietly suffers, or a phishing wave goes out under your name. A pre-launch SPF DMARC check turns that hidden weakness into a fixable line item.

What LaunchTrust checks

This detector (email_auth) is a passive DNS lookup. It never sends email and never touches your inbox. It does three things:

It reduces the scanned hostname to the registrable (organizational) domain, since SPF and DMARC live there. A deep subdomain like app.example.com collapses to example.com, and it is multi-part-TLD aware, so shop.example.co.uk resolves to example.co.uk.
It queries DNS over HTTPS for the TXT records on that domain (SPF) and on _dmarc.<domain> (DMARC).
It looks for an SPF record (a TXT value containing v=spf1) and a DMARC record (a TXT value containing v=DMARC1).

What the three signals mean here:

Detected — both records were found. An enforced DMARC policy is a clean signal; a p=none policy (monitoring only) is still detected but flagged as weaker, because p=none collects reports without rejecting spoofed mail.
Not detected — SPF, DMARC, or both are absent. The output names which one is missing (for example, "missing email anti-spoofing: DMARC"). This is the state that lets your domain be spoofed in phishing.
Unable to determine — the scan could not derive a host, or the DNS lookups failed. Not "you passed" — the check simply could not run.

This is a positive signal: SPF and DMARC are things you want present. The detector reads public DNS only and does not parse your full SPF mechanisms or evaluate alignment, so treat "detected" as "the records exist," not as proof your email setup is perfect.

Why it matters

No app-store rule literally says "you must have DMARC," but email authentication maps onto real anti-spoofing risk:

Phishing and brand integrity. SPF and DMARC are the baseline controls that stop your domain being used in phishing. A spoofable domain undermines every other trust signal on your site — including the contact and imprint details that point users back at you.
Deliverability. Transactional mail (receipts, magic links, password resets) sent from a domain with no SPF or DMARC is more likely to land in spam. Major mailbox providers increasingly expect both from bulk senders.
Security posture. Email authentication sits alongside your security headers and HTTPS transport as basic hygiene a reviewer or security-conscious partner expects.

These are commonly expected practices rather than a single hard legal line — expected for any domain that sends or receives business email.

A concrete example

A correctly configured pair of TXT records looks like this:

example.com.            TXT   "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com.     TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

The detector reports detected with an enforced policy here. Swap p=reject for p=none and it still reports detected, but flagged as weaker — p=none watches without rejecting. If no _dmarc TXT record exists at all, the result is not detected for DMARC.

How to address it

Publish an SPF record. Add one TXT record starting with v=spf1 that lists every service allowed to send as you (email provider, transactional sender, and so on), ending with ~all or -all. Keep it to a single SPF record — multiple records break the check.
Add a DMARC record in monitoring mode first. Create a TXT record at _dmarc.yourdomain with v=DMARC1; p=none; rua=mailto:you@yourdomain to start collecting reports without risking legitimate mail.
Set up DKIM at your mail provider. DKIM signing makes DMARC enforcement reliable, since DMARC passes on aligned SPF or DKIM.
Move DMARC to enforcement. Once reports confirm your real senders pass, change the policy from p=none to p=quarantine, then p=reject. This step actually stops spoofing.
Re-scan. Run the check again so the signal shows detected with an enforced policy.

Check this in 30 seconds

Paste your domain into the free LaunchTrust scanner and it runs this DNS lookup live — telling you whether SPF and DMARC are detected, which one is missing, and whether your DMARC policy is enforced or sitting on p=none. No DNS console digging, no email sent. Pair it with the security.txt detector and the exposed .env / .git check to round out your domain's security signals before you submit.

FAQ

Does an SPF/DMARC check prove my domain is legally in order? No. It surfaces signals — whether anti-spoofing records exist in your DNS — and nothing more. It is not legal advice, a certification, or a guarantee of deliverability or approval. It points you at a gap so you can decide how to address it.

What is the difference between SPF and DMARC? SPF lists which servers may send mail for your domain. DMARC tells receiving servers what to do when a message fails authentication (monitor, quarantine, or reject) and where to send reports. You generally want both, plus DKIM.

Why does the check sometimes say "unable to determine"? Because the DNS lookups failed or the URL had no usable host. That is not a clean result — it means the check could not run, so the SPF/DMARC state is unknown.

Is p=none good enough? It is a fine starting point because it collects reports without blocking mail, but it does not stop spoofing. The detector flags it as a weaker signal for that reason. Move to p=quarantine or p=reject once your real senders pass.

Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.