An SPF record is a DNS TXT record listing the servers authorised to send mail for your domain. A receiver looks it up, checks whether the connecting server is on the list, and fails the message if it is not. The catch that trips most senders is the lookup limit: SPF permits 10 DNS-querying mechanisms, counted through every include, and going over turns the whole record into a permanent error. Read more in the SPF glossary entry.
DKIM signs each outgoing message with a private key and publishes the matching public key in DNS under a selector you choose. The receiver verifies the signature and learns two things: the message really came from your domain, and nothing changed in transit. Because the signature travels with the message, DKIM survives forwarding in cases where SPF does not.
DMARC sits on top of both. It publishes a policy — none, quarantine, or reject — and it adds alignment, the requirement that the domain which passed SPF or DKIM matches the domain your recipient actually sees. Alignment is the part that closes the spoofing loophole, and a policy of none is the part that leaves it open. The full walkthrough is in our deliverability guide.
SPF lists the servers allowed to send mail for your domain. DKIM signs each message so a receiver can prove it was not altered and genuinely came from you. DMARC ties the two together: it tells receivers what to do when a message fails, and it requires that the domain that passed SPF or DKIM matches the domain your recipients see in the From field.
The most common cause is the 10-lookup limit. SPF allows a maximum of 10 DNS-querying mechanisms — include, a, mx, ptr, exists, and redirect — counted recursively through every include. Go over it and the record is a permanent error, so SPF stops passing even though the record reads fine. This checker follows your includes and counts them for you.
DKIM keys are published under a selector you choose, and DNS gives no way to list them. We probe 14 selectors used by the major sending platforms. If you use a custom selector, your key is fine but will not show up here — check DKIM in your sending platform instead.
No. A policy of p=none asks receivers to report on spoofed mail and then deliver it anyway. It is the right place to start, because the aggregate reports show you which of your own senders are failing, but it protects nobody. Move to p=quarantine and then p=reject once your reports are clean.
It is a different problem. Authentication decides whether receivers trust mail claiming to be from you, which affects spam placement and blocking. Bounces come from addresses that do not exist. You need both: authenticate your domain, and verify addresses before you send to them.
Related terms
Get 100 free validations to test our service. No credit card required.
Start free trial