Validate email authentication records for any domain
SPF (Sender Policy Framework) is a TXT record on your domain listing the IP addresses and hostnames authorized to send email "From: yourdomain.com". Receiving servers query this record on every incoming message; if the sending IP is not in your SPF list and your policy is "-all", the message can be rejected. SPF protects your domain from being trivially spoofed by spammers.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing mail using a private key. The matching public key is published in DNS at <selector>._domainkey.<your-domain>. Receivers fetch the public key, verify the signature, and gain assurance that the message body and key headers were not modified in transit. Each sending service publishes under its own selector — Google uses "google", many mailers use "selector1" / "selector2", and your own infrastructure can use any name you choose.
DMARC ties SPF and DKIM together by telling receivers what action to take when authentication fails: do nothing (p=none), spam it (p=quarantine), or bounce it (p=reject). It also lets you receive aggregate reports about who is sending mail "as you", so you can find legitimate senders you missed and shut down impersonators. A strong setup is SPF "-all" + DKIM 2048-bit + DMARC "p=reject" with a working "rua=" mailbox.
SPF alone is rarely enough. Modern inbox providers (Gmail, Outlook, Yahoo) increasingly require all three of SPF, DKIM, and DMARC for reliable inbox placement, especially for bulk senders. If your SPF is "+all" or "?all", or if you have no DMARC record at all, your mail is treated as untrusted regardless of how clean your content is. Run a check, fix any errors and warnings shown, and re-test after DNS has propagated.
The selector is chosen by whoever sends mail on your behalf, and there is no universal default. Common ones to try: "google" (Google Workspace), "selector1" / "selector2" (Microsoft 365), "k1" (Mailchimp), "s1" / "s2" (SendGrid, others), "mxvault" (MXroute), "fm1" / "fm2" / "fm3" (Fastmail), "protonmail" (Proton). Our checker tries dozens automatically, but if you know your sender, enter the selector explicitly for the most accurate result.
"p=none" tells receivers to take no action on messages that fail SPF and DKIM, but it still requests reports. It is the right starting point — deploy DMARC at "p=none" with a "rua=" address, watch the aggregate reports for a few weeks, fix any legitimate sending sources that are failing, and then move to "p=quarantine" and finally "p=reject". Leaving DMARC at "p=none" forever provides visibility but no enforcement.
RFC 7208 limits SPF to 10 mechanisms that cause DNS lookups (include, a, mx, ptr, exists, redirect). Exceeding 10 causes receivers to treat your SPF as "PermError" — which DMARC will then count as a failure. Common cause: chaining many "include:" providers. Fix it by removing services you no longer use, flattening your record (replacing includes with explicit ip4: / ip6: ranges), or using an SPF-flattening service.
"aspf" controls SPF alignment. "r" (relaxed, the default) requires the SPF-authenticated domain to share the same organizational domain as the From: header — mail.example.com aligning with example.com is fine. "s" (strict) requires an exact match. The same applies to "adkim" for DKIM alignment. Most domains should leave both at "r"; only switch to "s" if you have specific impersonation concerns and have verified all your senders use the exact same domain.
