SPF & DMARC Checker

Test a domain's email authentication: SPF, DKIM and DMARC records are checked for syntax, lookup limits and policy strength, with plain-English fixes.

Email authentication for bbc.co.uk

SPFValid
DKIMNot found on common selectors
DMARCp=reject

SPF (Sender Policy Framework)

4/10 DNS lookups
v=spf1 ip4:212.58.224.0/19 ip4:132.185.0.0/16 +include:spf.sis.bbc.co.uk +include:spf.messagelabs.com ~all
  • SPF record is valid and ends with ~all.

DKIM (DomainKeys Identified Mail)

We checked common selectors (google, selector1, selector2, default, k1, s1, s2, dkim, mail, smtp, mandrill, everlytickey1) and found no DKIM key.

DKIM keys live at <selector>._domainkey.bbc.co.uk and selectors are chosen by each email provider, so a key can exist even when we cannot guess the selector. Find the selector in the s= value of a DKIM-Signature header in an email from this domain and enter it above.

DMARC

v=DMARC1;p=reject;aspf=s;adkim=s;pct=100;fo=0;ri=86400; rua=mailto:dmarc_agg@vali.email;
Policy (p)
reject
Subdomain policy (sp)
same as p
Aggregate reports (rua)
mailto:dmarc_agg@vali.email
Percentage (pct)
100%
Alignment
DKIM: S, SPF: S (R = relaxed, S = strict)
  • DMARC is enforced with p=reject and reporting enabled.

See the MX records for bbc.co.uk.

Why SPF, DKIM and DMARC matter

Email was designed without sender verification, so anyone can put your domain in the "From" line. Three DNS-based standards fix that. Since February 2024, Google and Yahoo have required them from bulk senders, and missing records are now a common reason legitimate mail lands in spam.

  • SPF lists the servers allowed to send mail for your domain, in a TXT record starting with v=spf1.
  • DKIM adds a cryptographic signature to each message; receivers verify it with a public key published at selector._domainkey.yourdomain.
  • DMARC (at _dmarc.yourdomain) tells receivers what to do when SPF and DKIM fail to align with the From domain (none, quarantine or reject) and where to send reports.

What this checker tests

  • SPF exists, there is only one record, it ends in ~all or -all (never +all), and the total number of DNS lookups including nested include: mechanisms stays within the RFC 7208 limit of 10.
  • DKIM keys on the selector you supply, or on a dozen common selectors used by Google Workspace, Microsoft 365 and popular sending services.
  • DMARC exists, has a valid policy, applies to 100% of mail and sends aggregate reports so you can see who is sending as you.

Example records

example.com.         TXT  "v=spf1 include:_spf.example.net ip4:192.0.2.0/24 -all"
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s"
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"

Recommended rollout

  1. Publish SPF covering every service that sends for you, ending with ~all.
  2. Turn on DKIM signing in each provider.
  3. Publish DMARC with p=none and an rua address, and review reports for two to four weeks.
  4. Move to p=quarantine, then p=reject, once all legitimate mail passes.

Full walkthrough: SPF, DKIM and DMARC explained.

Frequently asked questions

Should I use ~all or -all?

With DMARC in place, either works; DMARC decides the outcome. ~all is the safer starting point; -all is stricter once you are confident every sender is listed.

What does "too many DNS lookups" mean?

Each include, a, mx, exists and redirect costs a lookup, including those inside included records. Over 10, SPF fails for everyone. Remove unused services or replace includes with ip4/ip6 ranges.

Do parked domains need these records?

Yes. Protect domains that never send email with v=spf1 -all and v=DMARC1; p=reject.

Copied to clipboard