SPF and DMARC check: how to look up, read and fix your records

What SPF, DKIM and DMARC each check

SPF and DKIM can both pass for a domain the reader never sees. DMARC closes that gap with alignment: a message passes when SPF or DKIM passes for a domain aligned with the From domain, and one aligned pass is enough. Relaxed alignment, the default, only needs the same organizational domain, so bounce.example.com aligns with example.com. Strict alignment needs an exact match.

A hypothetical newsletter service shows why this matters. It sends as news@example.com but uses its own bounce domain at example.net as the envelope sender. SPF passes for example.net, which does not align, so DMARC passes only if the service signs with DKIM as d=example.com.

How to look up the records with dig or nslookup

dig (Linux, macOS) or nslookup (Windows) is all you need:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
nslookup -type=TXT _dmarc.example.com

The SPF record is the TXT record that starts with v=spf1; verification tokens from other services often sit beside it. The DMARC record is the TXT record at _dmarc that starts with v=DMARC1. Check SPF on the envelope-sender domain, which can differ from the From domain; the Return-Path header of a delivered message shows it.

DKIM keys cannot be listed from outside, because each one sits under a selector. Read the s= and d= values in the DKIM-Signature header of a message you sent, then query that name, for example dig +short TXT s1._domainkey.example.com.

After a change, resolvers can serve the old answer until its TTL runs out. To see what is published now, find the authoritative servers with dig +short NS example.com and query one directly: dig +short TXT example.com @ns1.example.net. Then send a real message to a mailbox you control and read its Authentication-Results header. It shows what the receiver decided for SPF, DKIM and DMARC, and that is the result that counts.

How to read an SPF record

v=spf1 ip4:192.0.2.10 include:_spf.mail.example.net -all

Mechanisms are evaluated from left to right, and the first one that matches decides the result. Each can carry a qualifier: + pass (the default), - fail, ~ softfail, ? neutral.

~all or -all

~all says unlisted servers are probably not authorized, and receivers should not reject on that alone. -all says they are not authorized; what happens next is the receiver’s own policy. Both are reasonable, and Germany’s BSI accepts either. RFC 9989 adds one caution: with -all, a receiver that checks SPF early in the SMTP session can reject a message that aligned DKIM would have passed, typically forwarded mail, and that rejection never appears in DMARC reports. ?all or no all at all states nothing about unlisted servers. +all lets any IP address on the internet pass; never publish it.

The 10-lookup limit

Receivers evaluate at most 10 DNS-querying terms, counting those inside included records (section 4.6.4). Beyond that the result is permerror, and SPF can no longer help a message pass DMARC. A separate limit covers lookups that return no answer: more than two of these should also end in permerror. A record that shows four terms can still exceed the limit when the included records contain includes of their own, so count recursively. To get back under the limit, remove services you no longer use, write ip4/ip6 for addresses you control, and move high-volume services to their own bounce subdomain with its own SPF record. Flattening, which copies a provider’s IP ranges into your record, goes stale when the provider changes them.

One record per name

Two TXT records starting with v=spf1 on one name produce a permerror; merge them. A record longer than 255 characters goes into a single TXT record as several quoted strings, which receivers join without spaces. SPF is not inherited either: a record on example.com does not cover mail.example.com, so every name used as an envelope sender needs its own.

How to read a DMARC record

DMARC is now RFC 9989 (May 2026), a standards-track specification that replaces RFC 7489. The record still sits at _dmarc and starts with v=DMARC1:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

A record on example.com also covers subdomains that have none of their own; receivers find it with what RFC 9989 calls a DNS Tree Walk. Receivers that send aggregate reports deliver them as XML files, usually daily, listing the IP addresses that sent as your domain and their results. If rua points to another organizational domain, such as a report service, that domain must publish a TXT record like example.com._report._dmarc.reports.example.net starting with v=DMARC1 (RFC 9990, section 4), or receivers ignore the address.

From none to reject

1. List every service that sends as the domain: mailbox platform, newsletter, CRM, billing, support desk, website forms.
2. Publish p=none with rua and read the reports.
3. Fix each legitimate source until it passes with alignment, preferably through DKIM, which generally survives forwarding while SPF does not.
4. Move to quarantine, optionally with t=y first, then consider reject.

RFC 9989 says domains whose users post to mailing lists SHOULD NOT publish reject; those that still want it should first spend at least a month at none and as long again at quarantine, comparing the results. Any domain that publishes reject MUST sign its mail with DKIM. Germany’s BSI TR-03182 takes the stricter line: a sending domain SHOULD require reject. A domain used only for invoices and notifications is a different case from one your staff use on mailing lists. RFC 9989 also tells receivers not to reject on p=reject alone, but it acknowledges that in practice, list mail with an unchanged From line is often rejected.

Domains that send no mail

Parked, typo-protection and redirect-only domains can still appear in a forged From line. RFC 7208 calls an SPF record for domains that send no mail a well-established best practice. A complete set for a hypothetical parked domain:

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
example.net.         MX   0 .

The SPF record authorizes nobody, and p=reject costs nothing here because there is no legitimate mail to lose. The null MX from RFC 7505 says the domain accepts no mail, so the reports go to example.com, which must publish example.net._report._dmarc.example.com. BSI TR-03182 lists this same combination as a MUST for unused domains. The DMARC policy covers subdomains, but SPF does not, so give any subdomain with its own A or MX record a v=spf1 -all as well.

What Gmail, Yahoo and Outlook.com require from senders

Since November 2025 Gmail has been stepping up enforcement, including rejections. Google’s rules cover personal Gmail accounts, not Google Workspace recipients. Google and Yahoo require DKIM keys of at least 1024 bits. Microsoft rejects mail that misses its requirements with 550 5.7.515. All three accept p=none, which meets the rule but expresses no preference about forged mail; treat it as a stage, not the finished setup.

MTA-STS and CAA: two more records to check

MTA-STS (RFC 8461) protects incoming mail: it tells senders not to deliver to your MX hosts unless they offer TLS with a trusted certificate. It needs a TXT record at _mta-sts.example.com such as v=STSv1; id=20261001000000Z; and a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt listing the mode, MX names and max_age. Start in testing mode, where senders still deliver and report failures if TLS reporting is set up at _smtp._tls.example.com, then switch to enforce. Change the id whenever the policy changes.

CAA (RFC 8659) names the certificate authorities allowed to issue TLS certificates for the domain, for example CAA 0 issue "ca.example.net". Public CAs must check it before issuing; it does not stop an authorized CA from mis-issuing, and browsers do not use it. A record on example.com covers subdomains that have none of their own. List every CA you use, including your CDN’s, or renewals can fail. The TLS and security headers guide covers certificates in more detail.

Common SPF and DMARC mistakes and how to fix them

What the free Launch Readiness Snapshot checks in your mail DNS

The free Launch Readiness Snapshot runs eight passive checks on one public origin without signup. It is not a pentest and not the six-area audit. One of the eight checks reads mail DNS records:

• Exact hostname. MX, TXT, _dmarc, _mta-sts and CAA are queried on the hostname you enter, with no fallback to the parent domain. A missing record on www.example.com does not mean example.com is unprotected. To have the records of your mail domain read, enter that domain itself (example.com rather than www.example.com); it needs to resolve to an address for the snapshot to produce a score.
• SPF. A missing record is flagged (medium) only when the host has MX records. +all is flagged as high risk and ?all as low; ~all and -all raise nothing. More than ten DNS-querying terms is flagged (medium), but only terms in the top-level record are counted, because include: is not followed.
• DMARC. A missing record is flagged (medium) only when the host has MX records. p=none is flagged as monitoring mode (low), and quarantine or reject counts as passed. sp, pct, rua and alignment are not evaluated.
• MTA-STS and CAA. A missing _mta-sts TXT record is flagged (low) only when the host has MX records; the policy file is not fetched. Any CAA record counts as passed and none is a low signal; its contents are not compared with your certificate.
• Not checked: DKIM, TLS reporting and DNSSEC.

You get one score and grade, a hardening grade, counts of risk signals and passed checks, and up to three signals, most severe first, so a mail finding can be outranked by a web finding. A name that does not resolve to an address gets no score. The website launch checklist walks through all eight checks, and the DNS and email security guide covers ongoing review.