Email Tools

An email authentication check answers two questions about a domain: can other people send mail that appears to come from it, and will mail that genuinely comes from it be delivered. SPF, DKIM and DMARC are the three records that decide both. Without them, the visible From address of an email is simply a text field an attacker can set to anything.

A domain is properly protected when SPF lists every legitimate sending source and ends in -all or ~all, DKIM signs outbound mail with a key published in DNS, and DMARC is set to p=reject or p=quarantine with alignment enforced. Any one of the three alone is insufficient: SPF breaks on forwarding, DKIM alone does not tell receivers what to do with failures, and DMARC has nothing to enforce without at least one of the other two.

Ten. RFC 7208 §4.6.4 caps SPF evaluation at ten DNS-querying mechanisms. The mechanisms that count are include, a, mx, ptr and exists, plus the redirect modifier. They count recursively: every include spends one lookup itself and then charges you for everything inside it.

The mechanisms ip4, ip6 and all require no DNS query and are free. Exceeding ten produces a permerror, and RFC 7208 requires receivers to treat a permerror as though the domain published no SPF record at all, so an over-long SPF record is worse than a short one and can be worse than none. The usual fix is SPF flattening: replacing deep include chains with the ip4 and ip6 ranges they resolve to.

A separate and often-missed limit in the same section caps void lookups (queries returning NXDOMAIN or an empty answer) at two.

The p= tag tells receiving mail servers what to do with a message that fails DMARC alignment. p=none takes no action and only generates reports. It is a monitoring mode, not protection. p=quarantine asks receivers to accept the message but treat it as suspicious, which in practice means the spam folder. p=reject asks receivers to refuse the message at SMTP time, so it is never delivered anywhere.

Only p=reject actually stops domain spoofing. The standard rollout is to publish p=none with a rua= reporting address, read the aggregate reports until every legitimate sender is aligned, then move to p=quarantine and finally p=reject. The sp= tag sets a separate policy for subdomains, and pct= applies the policy to a percentage of mail during a staged rollout.

The DKIM selector is the label that appears before ._domainkey in the DNS name holding the public key. In google._domainkey.example.com the selector is google. There is no way to enumerate selectors from DNS, because a TXT record can only be looked up by exact name, which is why every DKIM checker asks you for one.

The reliable method is to read it off a message the domain has actually sent: open the raw headers, find the DKIM-Signature header, and take the value of its s= tag. Failing a sample message, the selector is usually predictable from the provider: google for Google Workspace, selector1 and selector2 for Microsoft 365, k1 for Mailchimp and Klaviyo, s1 and s2 for SendGrid, zmail for Zoho, and default for many self-hosted servers.

Authentication proves a message is genuinely from your domain. It says nothing about whether recipients want it, and the filters that decide the spam folder weigh reputation far more heavily than authentication. Passing SPF, DKIM and DMARC is a prerequisite for inbox placement, not a cause of it.

The common causes with authentication already correct are: a sending IP or domain listed on a DNSBL; a new domain or IP with no sending history, sent at volume; low engagement and high complaint rates from recipients; missing or broken one-click unsubscribe headers, which Google and Yahoo have required for bulk senders since February 2024; a mismatch between the From domain and the links in the body; and missing reverse DNS or forward-confirmed reverse DNS on the sending IP.