SPF DKIM DMARC for Bloggers: What to Actually Set Up
Short answer: SPF DKIM DMARC for bloggers comes down to three DNS records on your own domain. SPF lists which services may send mail as you. DKIM adds a signature that proves a message really came from your domain. DMARC tells inboxes what to do when those checks fail and asks them to send you reports. If you send a newsletter from an address on your own domain, set up all three. Your email tool gives you the exact SPF and DKIM values to paste; you write a simple DMARC record yourself.
That is the whole job for most small sites. The rest of this page explains what each record does, what Gmail now requires, and the handful of mistakes that quietly undo the setup.
Why your email tool keeps nagging you
Most newsletter tools now show a warning banner until you "authenticate your domain." That is not upselling. On February 1, 2024 Google started enforcing sender requirements for anyone mailing personal Gmail accounts, and email tools changed their onboarding to match.
According to Google's email sender guidelines (read on September 28, 2026), every sender to personal Gmail accounts needs SPF or DKIM, valid DNS, a TLS connection, and a spam complaint rate kept below 0.3%. Senders who pass 5,000 messages a day to personal Gmail accounts are classed as bulk senders and must have SPF and DKIM and DMARC, with the From domain aligned to one of them, plus one-click unsubscribe.
A blog with 800 subscribers is nowhere near 5,000 a day. So why bother? Two reasons. First, Google's own sender FAQ says bulk sender status has no expiration date once you cross that line, so it is easier to be compliant before a busy launch week than after. Second, authentication is one of the few deliverability signals you fully control. Content, engagement and reputation take months to build. Three DNS records take an afternoon.
What each record does, in plain terms
Think of your domain as a return address on an envelope. Anyone can write any return address. These three records let the receiving inbox check whether yours is real.
SPF: the guest list
SPF (Sender Policy Framework) is a TXT record on your domain that lists the servers and services allowed to send mail using it. When Gmail receives a message claiming to be from you, it checks whether the sending server is on that list.
A typical SPF record looks like v=spf1 include:_spf.google.com include:servers.example-esp.net ~all. Each include is a service you use. The ~all at the end says "anything else is suspicious."
DKIM: the wax seal
DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key held by your email service. You publish the matching public key in DNS, usually as a CNAME or TXT record your tool hands you. The inbox checks the signature against that key. If the message was altered on the way, or never came from an approved sender, the signature fails.
DKIM matters more than SPF for newsletters, because it survives forwarding and because most email tools send from their own servers, not yours.
DMARC: the instructions and the report card
DMARC (Domain-based Message Authentication, Reporting and Conformance) is one TXT record at _dmarc.yourdomain.com. It does two jobs. It tells inboxes what to do when a message fails authentication, and it asks them to email you summary reports about who is sending mail as your domain.
A safe starting record is v=DMARC1; p=none; rua=mailto:you@yourdomain.com. The p=none policy means "do not block anything yet, just report." Google's bulk sender requirements accept p=none; what they do not accept is having no DMARC record at all.
SPF DKIM DMARC for bloggers: which records you need, by how you send
This is the part most guides skip. What you set up depends on where your mail comes from, and bloggers usually send from more places than they realize.
| How you send | What to set up | The catch |
|---|---|---|
| Newsletter tool using a free address (for example a gmail.com From line) | Nothing you can set; you do not own gmail.com | Google's sender FAQ treats a gmail.com From address sent from non-Gmail servers as impersonation for bulk senders. Move to your own domain. |
| Newsletter tool using you@yourblog.com | DKIM records from the tool, the tool's SPF include (if it asks), one DMARC record | Many tools only need DKIM plus DMARC because they use their own return path for SPF. Follow the tool's own instructions, not a generic template. |
| WordPress sending notifications (password resets, comment alerts, form entries) | Route through an SMTP service and add that service to SPF and DKIM | Default WordPress mail often goes out from the web host's server, which may not be in your SPF record. |
| Google Workspace or another mailbox on your domain | That provider's SPF include and DKIM key | This is usually the record already sitting in your DNS, which creates the duplicate SPF problem below. |
If you only remember one row, make it the first. Sending a newsletter from a free webmail address through a third party service is the setup most likely to go wrong, and no DNS change can fix a domain you do not own.
How to set it up, in order
The order matters because each step is easier to check once the one before it works.
- Pick one sending address on your own domain. Something like
hello@yourblog.comornewsletter@yourblog.com. Use it everywhere. - Find your DNS. It lives wherever your nameservers point: your registrar, your host, or a service like Cloudflare. Look for a "DNS records" or "Zone editor" screen.
- Add DKIM first. In your newsletter tool, open the domain authentication or sender settings. It will list the records it needs. Copy them exactly, including any underscores.
- Add or edit SPF. If the tool asks for an SPF include, add it to your existing SPF record rather than creating a new one.
- Add DMARC with
p=none. Use the starting record above with a reporting address you actually read. - Verify. Click "verify" in the tool. DNS changes can take a while to show up, so if it fails straight away, wait and try again before editing anything.
- Send yourself a test. Open the message in Gmail, choose "Show original," and look for PASS next to SPF, DKIM and DMARC.
Once reports have come in for a few weeks and every legitimate sender passes, you can consider tightening DMARC to p=quarantine. There is no prize for rushing that step on a small blog. A strict policy set too early is how a forgotten sender, like the contact form plugin, starts silently failing.
The mistakes that break a working setup
These are the ones worth checking even if your tool says "verified."
Two SPF records
The SPF standard, RFC 7208 (read on September 28, 2026), says a domain "MUST NOT have multiple records" that would cause a check to select more than one. In practice this happens easily: the host adds one, Google Workspace adds another, and a newsletter guide says "add this record." The fix is one record with several include entries, not several records.
Too many lookups
The same RFC limits SPF evaluation to 10 DNS-querying terms. Every include can pull in more lookups behind it. Stack a host, a mailbox provider, a newsletter tool, a form plugin and an old tool you stopped using, and you can hit the limit. When that happens SPF fails. Remove includes for services you no longer send from.
Old tools still listed
This one ties email to your wider tool stack. If you have cycled through several email tools, your DNS may still carry records for services you cancelled. When you audit unused SaaS tools in your stack, add DNS to the checklist: every tool you drop should also leave your SPF record.
A DMARC address nobody reads
DMARC reports arrive as XML attachments that are hard to read raw. Use a mailbox you check, or a report viewer. The reports are the only way to see a sender you forgot about before it causes a problem.
What authentication will not fix
Honest limits, because this is where expectations go wrong. SPF, DKIM and DMARC prove the mail is really yours. They do not make people want it.
- They will not move mail out of Gmail's Promotions tab. That is a sorting decision about content, not a trust decision.
- They will not rescue a list full of addresses that never engage. Complaint rates still count, and Google publishes the 0.3% ceiling for a reason.
- They will not help if your tool's shared sending servers have a poor reputation. That is a question about the provider.
That last point matters when you are choosing a tool, especially a cheap one. Before you commit, check that it supports custom domain authentication with your own DKIM key, not just a shared domain. It belongs on any list of questions for how to vet a SaaS vendor before buying, and it is a fair reason to be cautious about email sending tools sold on a one-off lifetime price, a category covered in which SaaS tools you should never buy lifetime.
If any record involves a business mailbox you share with a team, or a domain someone else manages, ask whoever runs that DNS before you change it. An SPF edit on a shared domain can break mail for everyone on it.
A five-minute check for an existing setup
If you set this up a year ago and have not looked since, run through this quickly:
- Send a test newsletter to a Gmail address and confirm SPF, DKIM and DMARC all show PASS.
- Look up your domain's TXT records and count the SPF records. There should be exactly one.
- Check that the From address in your tool is on your domain, not a free webmail address.
- Trigger a WordPress password reset and confirm it arrives, and passes, too.
- Open a recent DMARC report and look for sending sources you do not recognize.
Requirements from inbox providers change. The figures on this page were checked against Google's published sender guidelines on September 28, 2026; review them again if you read this much later.
FAQ
Do bloggers really need SPF, DKIM and DMARC?
If you send any email from an address on your own domain, yes. Google requires SPF or DKIM for every sender to personal Gmail accounts, and all three plus alignment once you send more than 5,000 messages a day to them. Setting up all three from the start costs an afternoon.
Is p=none a good enough DMARC policy?
For a small blog starting out, yes. Google's bulk sender requirements accept a policy of none. It gives you reports without blocking anything, so you can find every legitimate sender before tightening the policy later.
Can I send my newsletter from a Gmail address?
You can try, but Google's sender FAQ treats a gmail.com From address sent from servers that are not Gmail's as impersonation for bulk senders, and you cannot add records to a domain you do not own. Using an address on your blog's domain is the dependable route.
Why does my email tool say verified but mail still goes to spam?
Verification only confirms the records exist. Spam placement also depends on complaint rates, engagement, list quality and the provider's sending reputation. Check for duplicate SPF records first, then look at who is on the list and how they signed up.
Do I need a developer to set this up?
Usually not. It is copying values from your email tool into your DNS screen. The exception is a domain whose DNS or mailboxes someone else manages, where you should ask them before changing anything.