SPF, DKIM & DMARC Checker

What does an SPF DKIM DMARC checker test, and why run one?

An SPF DKIM DMARC checker reads your domain's email authentication records from the outside. It shows you the verdict receiving servers will reach. Before Gmail, Outlook or Yahoo deliver a message, they ask three questions and look for the answers in your DNS. If one record is missing or broken, your message lands in spam or never arrives.

• SPF: may this server send for this domain?
• DKIM: did the message arrive unchanged, and who signed it?
• DMARC: does the From domain match one of those checks, and what happens if not?

I run this check in the first week of every business website I build. Contact form notifications and quote emails usually get lost because of a missing DNS record, not because of the design. That is why my web design projects keep DNS, SSL and email authentication on the same handover checklist. Starting business email from scratch? My guide to email on your own domain covers choosing a provider.

How does the SPF limit of 10 DNS lookups work?

An SPF record is more than its own line. Every include term calls the SPF record of another domain, and that record can contain further includes. RFC 7208 limits the combined number of include, a, mx, ptr, exists and redirect terms in that chain to 10. A record over the limit returns permerror, and SPF then passes for no message at all.

The problem tends to grow quietly. For example, your record shows three includes, but one of them opens five more lookups on its own. So the tool draws the tree with numbers: each line shows which lookup it is, and anything after the tenth turns red. It also counts void lookups, the ones that come back empty, separately; their limit is 2.

When a domain gets close to the limit, I work in this order:

1. Remove the includes of services you no longer use.
2. Keep marketing platforms out of the root record; most of them use their own Return-Path subdomain and align through DKIM.
3. Move heavy sending to a subdomain such as news.example.com, which gets its own SPF record.

Some tools suggest flattening includes into IP addresses. However, a flattened record goes stale without warning once a provider changes its IP ranges. So I only use it where someone monitors it.

Why do the DKIM selector and key length matter?

A DKIM key does not sit at the root of your domain; it lives at selector._domainkey.example.com. The provider picks the selector name. Google Workspace uses google by default, Microsoft 365 uses selector1 and selector2, and Yandex 360 uses mail. cPanel and Plesk use default. Services such as Amazon SES and Postmark generate random or date-based selectors that no tool can guess. In that case, take the s= value from the header of a message you sent and enter it in the selector field.

Once a key is found, length is the value to watch. RFC 8301 requires signers to use at least 1024 bits and recommends 2048. Google also refuses keys under 1024 bits for mail to personal Gmail accounts. The tool decodes the base64 key from DNS and prints the real bit length. If you see 1024 bits, I recommend a new 2048 bit key from your provider's panel.

• Empty p=: the key is revoked; fine for an old selector.
• t=y: the domain is testing DKIM; remove it once setup is done.
• CNAME without a key: normal for the standby selector on Microsoft 365, but if it is your only selector, DKIM does not work.

How do you move DMARC from none to reject?

The DMARC record lives at _dmarc.example.com. It tells receivers what to do with mail that fails authentication (p) and where to send reports (rua). p=none only monitors, so spoofed mail is still delivered. In contrast, p=quarantine sends that mail to spam and p=reject refuses it outright.

I never make the switch in a single step. First I start with p=none and rua and read the aggregate reports for two to four weeks. Meanwhile I align every legitimate sender through SPF or DKIM. When only spoofed sources remain in the reports, I move to p=quarantine, and after a few quiet weeks to p=reject.

RFC 9989, published in May 2026, replaced the old RFC 7489 and changed a few things:

• The pct tag is gone; a t=y testing flag replaces it. Google still reads pct during a staged rollout, though.
• The np tag sets a separate policy for subdomains that do not exist.
• A DNS tree walk replaces the public suffix list.
• For general-purpose domains whose users post to mailing lists, the RFC advises quarantine instead of reject.

The tool reads your record under both standards and flags obsolete tags separately.

Does your SPF DKIM DMARC checker result meet the bulk sender rules?

Google and Yahoo have required the same basics from bulk senders since February 2024. Microsoft followed for Outlook.com on May 5, 2025. Google defines a bulk sender as close to 5,000 messages to personal Gmail accounts within 24 hours. Microsoft says more than 5,000 a day, and Yahoo gives no number. Moreover, Microsoft rejects non-compliant mail with the code 550 5.7.515. Since November 2025, Gmail has also rejected such traffic temporarily or permanently.

DNS reveals some of these requirements and hides others. The Sender rules tab draws that line clearly:

• Visible in DNS: a valid SPF record, a DKIM key, a key of at least 1024 bits, a DMARC record of at least p=none.
• Needs a real message: From alignment, one-click unsubscribe, TLS when sending.
• Needs your sending platform: a complaint rate below 0.3 percent, reverse DNS for the sending IP, unsubscribes honored within two days.

In short, even with every DNS row green, run your newsletter's header through the header analyzer once. Google Postmaster Tools is a free and reliable place to watch your complaint rate.

What does the email header analyzer show you?

Correct DNS records are one thing; only the header shows how a real message was actually authenticated. Send yourself a message, open its header and paste it in. The tool parses the text entirely in your browser and sends nothing to a server. The header never becomes part of a share link either.

• Authentication-Results: the spf, dkim and dmarc verdict of the receiving server.
• Alignment table: relaxed or strict match between the From domain and the envelope (Return-Path) and signing (d=) domains.
• DKIM signatures: selector, algorithm, signed headers and a one-click check of that selector.
• One-click unsubscribe: the List-Unsubscribe and List-Unsubscribe-Post headers; RFC 8058 requires the DKIM signature to cover both.
• Delivery hops: delays between servers from the Received lines, and whether the last hop used TLS.

When a platform's message passes DKIM but fails alignment, the cause is almost always the same: the platform signs with its own domain. Turn on custom domain authentication in the platform's panel, and the signature moves to your domain, so DMARC passes.

Where do you add the records in cPanel and Plesk?

First find out where your DNS is managed: you add records at whichever company your domain's nameservers point to. The DNS lookup tool shows the nameservers, and a Whois lookup shows the registrar. If the nameservers are at a service like Cloudflare, the zone inside cPanel changes nothing.

• cPanel: the Email Deliverability screen installs the suggested SPF and DMARC records in one click. It also generates a DKIM key. To add records by hand, open Zone Editor, then Manage and Add Record.
• Plesk: under Websites & Domains, pick your domain and add a TXT record in DNS Settings. For DKIM, tick the DKIM box in Mail Settings; Plesk then publishes default._domainkey itself.

Keep two rules in mind. If the domain already has a v=spf1 record, edit it rather than adding a second one, because two SPF records cause permerror. Also, if you use MTA-STS, check the mta-sts subdomain with the SSL checker. Senders only read the policy file over a valid certificate. After any change, wait until the old record's TTL expires and run the tool again.