Email was designed in an era of trust — anyone can claim to be anyone. SPF, DKIM, DMARC and RBL blocklists are the four pillars that modern mail servers use to tell real senders from spammers and spoofers. Here is how each one works, in plain language, and how together they keep junk out of your inbox.
The core email protocol (SMTP) has no built-in way to verify the sender. Nothing stops a spammer from writing From: support@yourbank.com on a message that never touched the bank’s servers. This is called spoofing, and it powers most phishing and spam campaigns.
Authentication fixes this by answering three questions for every incoming message:
RBL blocklists add a fourth, independent layer based on the reputation of the sending IP address.
SPF answers: “which mail servers are authorized to send email for this domain?” The domain owner publishes a list of allowed servers as a special DNS TXT record. When a message arrives, the receiving server looks at the connecting IP address and checks it against that list.
This says: mail may come from Google’s servers or from the 203.0.113.0/24 block, and -all means “reject everything else.”
If a spammer sends a message pretending to be example.com but connects from an unlisted IP, SPF returns fail — a strong signal that the message is forged. The main limitation: SPF checks the envelope sender (Return-Path), not the visible From address, and it breaks when mail is forwarded. That is why DKIM and DMARC exist.
DKIM answers: “was this message really sent by the domain, and has it been altered?” The sending server adds a cryptographic signature to the message using a private key. The matching public key is published in DNS. The receiver uses it to verify the signature.
DKIM-Signature: header that includes the domain (d=) and a selector (s=).<selector>._domainkey.<domain> in DNS.A valid DKIM signature proves ownership of the domain and integrity of the content — a spammer cannot forge it without the private key. Unlike SPF, DKIM survives forwarding, because the signature travels with the message.
DMARC ties SPF and DKIM to the visible From address and tells receivers what to do on failure. On its own, passing SPF or DKIM for some domain isn’t enough — a spammer could pass checks for their own throwaway domain while spoofing yours in the From field. DMARC closes that gap with alignment: the domain that passes SPF/DKIM must match the domain in From:.
The policy p= tells receivers how to handle messages that fail alignment:
p=none — monitor only (collect reports, deliver normally);p=quarantine — send failing mail to spam;p=reject — refuse it outright.DMARC is what actually stops direct-domain spoofing. With p=reject, a phishing email that claims to be from your domain but fails authentication is blocked before it reaches anyone. The rua reports also give the domain owner visibility into who is sending — and abusing — their domain.
An RBL (Realtime Blackhole List), also called a DNSBL, is a published list of IP addresses known to send spam. It works independently of SPF/DKIM/DMARC and is checked over DNS: the receiver reverses the sender’s IP and queries a blocklist zone. A hit means the IP has a bad reputation.
To check IP 203.0.113.5 against a list like zen.spamhaus.org, the server queries 5.113.0.203.zen.spamhaus.org. If it resolves to a 127.0.0.x address, the IP is listed and the message can be rejected or scored as spam.
RBLs catch spam at the connection level — often before the message body is even received — which saves resources and blocks known botnets, hijacked servers and snowshoe spammers. Because listings are reputation-based, they also stop brand-new domains that pass SPF/DKIM but originate from dirty IP ranges.
No single mechanism is enough on its own — each covers the others’ blind spots. A typical receiving server runs them as layers:
| Layer | Question it answers | Main weakness it covers |
|---|---|---|
| RBL/DNSBL | Is the sending IP known-bad? | Blocks botnets before content is read |
| SPF | Is this server allowed to send? | Stops unauthorized servers |
| DKIM | Is the message genuine and unaltered? | Survives forwarding; proves integrity |
| DMARC | Does authentication match the From domain? | Stops direct-domain spoofing |
Together they turn “anyone can claim to be anyone” into “prove who you are, or your mail gets blocked.” That is the foundation of modern anti-spam — and the same signals we surface when you analyze a message on this site.
Paste raw email headers and instantly read the SPF, DKIM and DMARC results, trace the delivery path, and look up a domain’s live records.
Open the Header Analyzer →For sending: publish SPF and DKIM, then enforce them with DMARC (ideally p=reject). RBLs are used by receivers, not published by you — but you should keep your sending IPs off them. For receiving: use all four layers.
Most often because it was forwarded, or sent through a service you forgot to authorize in your SPF record. DKIM and DMARC alignment usually still let it through.
A label (the s= value) that lets a domain publish multiple DKIM keys. The receiver combines it with the domain to find the right public key at selector._domainkey.domain.
Yes — for their own domains. That is exactly why DMARC alignment and IP reputation (RBLs) matter: they judge whether the authenticated identity actually matches the sender you see, and whether that sender is trustworthy.