Email was designed in an era when everyone on the network was assumed to be honest. Nothing in the protocol itself stops a stranger from sending a message that claims to come from your domain, which is why a receiving server has to make a judgement about every message it accepts.
SPF, DKIM and DMARC are the three published records that judgement is based on. They are not security software and there is nothing to install: each is a line of text in your DNS, and each answers a different question about a message that claims to be from you.
The problem
Anyone can write your address in the From field.
Putting an address in the From line of an email is roughly as hard as writing a return address on an envelope. The protocol does not verify it, and nothing about receiving a message proves it came from the domain it names. This is the whole reason the three records exist.
So a receiving mail server is left deciding, for every message, whether to trust the claim. Without published records it has almost nothing to go on beyond reputation and content, and the safe default for anything uncertain is the spam folder — which is how a legitimate invoice from a real business ends up unread.
What the three records give the receiver is evidence you published yourself, in DNS, where anyone can read it. They do not make your email private and they do not stop anyone from sending. They let a receiver check a claim against something you said in advance.
Record 01
SPF lists the servers allowed to send for you.
SPF is a single TXT record on your domain naming the servers permitted to send mail as you. When a message arrives, the receiver checks the connecting server against that list. If the sender is not on it, the message failed SPF.
The most common way to get this wrong is to forget a sender. Your mailbox provider is usually included from the start, but the invoicing tool, the CRM, the newsletter platform and the website contact form each send on your behalf too, and each needs to be covered. Every one you miss is a category of your own mail that fails.
The second common mistake is size. SPF is capped at ten DNS lookups, and each include: costs one or more. Stacking providers quietly pushes you past the limit, at which point the record stops evaluating and the result is a permanent error rather than a pass.
- One SPF record only — two records on the same domain is itself a failure
- Every service that sends as you is covered, not just the mailbox provider
- The lookup count is under ten, counting everything each include: pulls in
- It ends with ~all or -all rather than trailing off with no policy
Record 02
DKIM proves the message was not altered on the way.
DKIM adds a cryptographic signature to messages as they leave, and publishes the matching public key in your DNS. The receiver recalculates the signature and compares. A pass means two things at once: the message really was signed by a key published under your domain, and the signed parts of it were not modified in transit.
Where SPF checks the envelope, DKIM checks the contents. That difference matters when mail is forwarded: forwarding changes the connecting server and breaks SPF, while a DKIM signature usually survives it. This is exactly why having both is worth more than having either.
The key is found through a selector — a label your provider chooses, published as selector._domainkey on your domain. There is no universal directory of selectors, which is the honest limit of any external DKIM check, including the one on this site: a checker can test the selector you supply plus a short list of common ones, and no more.
Record 03
DMARC decides what a failure means, and tells you about it.
SPF and DKIM produce results. On their own they do not say what a receiver should do with a failure, and different receivers will make different choices. DMARC is the record where you state the policy yourself, and where you ask to be told what is happening.
The policy has three settings. p=none asks receivers to change nothing and just report — it is a monitoring position, not protection. p=quarantine asks for failures to go to spam. p=reject asks for them to be refused outright. Almost everyone should start at none, read the reports for a few weeks, and only then tighten.
The reporting half is the part most domains never switch on, and it is the useful half. Add a rua address and receivers send you aggregate reports naming every source sending as your domain. That is how you discover the invoicing tool nobody documented, before you set a policy that would have started blocking it.
Doing it
The order matters, and so does what none of this proves.
Publish SPF first, because it is the easiest to get complete and the easiest to check. Enable DKIM at every provider that offers it, since each one signs with its own selector. Then add DMARC at p=none with a reporting address, leave it for a few weeks, and read what comes back before you tighten to quarantine and then reject.
What none of the three do is guarantee delivery. Passing all three checks does not put a message in the inbox: engagement history, content, list hygiene, the recipient's own filters and your sending IP's reputation all still apply. Authentication removes a reason to distrust you. It does not manufacture a reason to trust you.
They also say nothing about mail you receive. These records protect the use of your name by others; they do not filter what arrives in your own mailbox, and they are not a substitute for anything on that side.
- SPF published and complete before anything else
- DKIM enabled at every sending provider, each with its own selector
- DMARC at p=none with a rua reporting address
- Reports read for several weeks before moving to quarantine
- Only then p=reject, once no legitimate sender is failing
Keep reading