If you have asked someone about your email problems and got back a wall of acronyms, you are not alone. SPF, DKIM and DMARC get talked about as one bundle, as if they were a single setting you switch on. They are not. They are three separate records that do three separate jobs, and understanding them one at a time is the fastest way to stop feeling lost when someone mentions your domain's DNS.
None of this needs you to know what DNS stands for. It helps to think of your domain, the part after the @ in your email address, as a business address. SPF, DKIM and DMARC are three different ways of proving that mail claiming to come from that address really did.
SPF: the guest list
SPF stands for Sender Policy Framework. It is a list, published in your domain's DNS, of every mail server allowed to send email on your behalf. When someone's inbox receives a message claiming to be from you, their mail server checks your SPF record and asks a simple question: is the server that sent this message actually on the list?
Think of it as a guest list at a door. If your company uses Google Workspace to send mail, and a marketing tool to send newsletters, and an invoicing platform to send bills, all three of those services need to be named on your SPF list. If one is missing, mail from that service can still get delivered, but it fails the SPF check, and a failed check makes the message look more like an impersonation attempt to the receiving server.
The catch with SPF is that the guest list has a maximum length: ten DNS lookups. Add enough tools and you can go over it without any warning, and the record starts failing silently. I covered that specific failure in the SPF ten lookup limit.
DKIM: the wax seal
DKIM stands for DomainKeys Identified Mail. Where SPF checks which server sent a message, DKIM checks whether the message itself was altered in transit. Your mail server attaches a digital signature to every outgoing message, generated from a private key only you hold. The receiving server looks up the matching public key in your DNS and checks whether the signature still matches the message.
The useful comparison is a wax seal on a letter. Anyone can see who the seal claims to belong to, but if the letter was opened and changed along the way, the seal breaks and the recipient knows something is wrong. DKIM does the same thing for the words in your email and its headers. It proves the message left your server intact and unmodified.
SPF and DKIM solve different problems. SPF answers "did this come from a server this domain trusts?" DKIM answers "was this message tampered with after it was sent?" A domain can pass one and fail the other, and mail providers look at both.
DMARC: the instructions for what happens next
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It does not check anything on its own. Instead, it tells receiving mail servers what to do when a message fails the SPF or DKIM checks, and it asks those servers to send you a report of what they saw.
This is the part most small business domains get wrong, not by omission but by half measure. A DMARC record published with a policy of p=none tells receiving servers "just let it through either way, and tell me about it." That is useful for gathering data, but it does not stop anyone from sending forged mail in your name. I went through exactly what that setting does and does not do in what p=none really means.
A DMARC policy set to quarantine or reject is the part that actually protects your domain, sending failed mail to spam or blocking it outright. Getting there safely means reading the reports DMARC generates first, which I walked through in reading a DMARC report without software.
Why all three, together
Here is the part that catches people out: DMARC needs SPF or DKIM to be working before it can do anything useful. A domain with a DMARC record but no working SPF or DKIM is publishing instructions with nothing behind them. It is telling mail servers "check my guest list and my wax seal" when neither exists yet.
This is not a hypothetical requirement. Google, Yahoo and Microsoft require SPF, DKIM and a published DMARC record from any domain sending more than 5,000 messages a day to their users, and mail that falls short gets no delivery support from Google at all (Google Workspace Admin Help). Most small businesses send far fewer messages than that threshold, but the underlying logic still applies to every domain: a mailbox provider that cannot verify a message is more likely to treat it with suspicion, threshold or not.
Where to start
If you have not touched any of this, start by finding out where you stand rather than guessing. Run a domain health check to see whether SPF, DKIM and DMARC are present, and if DMARC is present, what policy it is set to. Most domains I check have at least one of the three missing entirely, and it is rarely obvious from the inbox why mail is landing in spam.
Once you know which of the three is missing or broken, fixing it is a DNS record, not a rebuild. The order that works best is SPF first, then DKIM, then DMARC once both of those are passing consistently.