SPF, DKIM, and DMARC are three separate DNS records that together tell mailbox providers your email is really from you, and getting them right is genuinely the single highest-leverage fix in email deliverability, it's the first thing I check on every audit before looking at anything else. None of the three is complicated on its own, they just have to be set up correctly and in the right order, which is what this walks through.
SPF is a list, published as a DNS TXT record, of every server allowed to send mail on behalf of your domain. When a message arrives, the receiving server checks the sending server's IP against your SPF record, and if it's not on the list, the message fails that check.
DKIM adds a cryptographic signature to each outgoing message, generated with a private key your sending platform holds, and verified against a public key published in your DNS. If anything in the message changes in transit, the signature breaks, which proves both who sent it and that it wasn't tampered with.
DMARC sits on top of the other two and tells receiving servers what to do when a message fails SPF or DKIM, whether to let it through anyway, send it to spam, or reject it outright. It also gives you a reporting address so you can see who's sending mail using your domain, including anyone spoofing it.
Add a single TXT record at your domain's root that lists your approved senders. A basic record for a domain sending through Google Workspace looks like v=spf1 include:_spf.google.com ~all, and if you're also sending through a tool like Klaviyo or Instantly, you add its include statement to the same record rather than creating a second one.
The most common mistake here is publishing two separate SPF records because a second platform's setup instructions told you to add "a TXT record" without mentioning you likely already have one. DNS only allows one SPF record per domain, so the fix is merging both include statements into a single record, not adding a second.
DKIM is generated and enabled inside whatever platform you're sending through, whether that's Google Workspace, Klaviyo, or a cold email tool, since it needs to hold the private key that matches the public key you publish. The platform will give you a TXT record with a selector, something like google._domainkey.yourdomain.com, and a long public key value to paste into your DNS.
If you send from more than one platform, each one needs its own DKIM selector and key, they don't share. Skipping this step for a secondary sending tool is a common reason one platform's mail lands fine while another's doesn't, even on the same domain.
A starting DMARC record looks like v=DMARC1; p=none; rua=mailto:you@yourdomain.com, published as a TXT record at _dmarc.yourdomain.com. Starting at p=none means nothing gets rejected yet, you're just collecting reports on what's passing and failing, which matters because you want to see all your legitimate senders are covered before you start blocking anything.
After a few weeks of clean reports, move to p=quarantine, which sends failing mail to spam, and eventually p=reject, which blocks it outright. Jumping straight to reject before confirming every legitimate sender passes is how people accidentally block their own transactional email or a marketing platform they forgot was sending on their behalf.
Once the records are live, send a test email to a free checker like mail-tester.com or use Google's Admin Toolbox, both will show you a pass or fail on all three records within a couple of minutes. You can also check the raw records yourself with a terminal command like dig TXT yourdomain.com if you want to confirm exactly what's published.
The mistakes I see most often are a duplicate SPF record, a DKIM selector that was never actually turned on inside the sending platform even though the DNS record exists, and a DMARC policy left at p=none indefinitely, which means you're collecting reports but not actually enforcing anything. If you're also setting up a dedicated sending domain, pair this with custom return-path domain setup, and if you're sending meaningful volume to Gmail or Yahoo specifically, check Gmail and Yahoo's sender requirements, since both now require DMARC at minimum for bulk senders.
Yes, Gmail and Yahoo apply authentication checks to all mail, not just bulk senders, and low-volume domains without proper records are often treated with more suspicion since they have less sending history to fall back on.
Start at p=none so you can review reports without affecting delivery, then move to p=quarantine and eventually p=reject over several weeks once you've confirmed every legitimate sender is passing.
No, DNS only supports one SPF record per domain, and having two will cause SPF to fail entirely, the fix is combining all your approved senders into a single record.
The free Inbox Scorecard checks your SPF, DKIM, and DMARC records automatically, and the audit walks through fixing anything that's missing or misconfigured.