NEWSLETTERS · HOSTING
Independent Publishing Infrastructure
Three DNS records decide whether your newsletter reaches the inbox or the junk folder. Here is what each one does, the order to check them in, and the mistakes that undo all three.
DMARC, SPF and DKIM are three DNS records that together let a receiving mail server verify that an email claiming to be from your domain is actually authorised by you. SPF lists which servers may send on your behalf; DKIM cryptographically signs each message so it cannot be altered in transit; DMARC tells the receiver what to do if a message fails those checks, and where to send a report about it. Get all three right, in that order, before your first campaign, and authentication stops being a reason your newsletter lands in spam.
| Record | What it actually does | Most common mistake |
|---|---|---|
| SPF | A TXT record on your domain listing which mail servers are allowed to send as you. Receivers check the sending server's IP against this list. | Two SPF records on one domain (only one is valid, per the spec) or exceeding the 10-DNS-lookup limit once several services are chained together. |
| DKIM | A cryptographic signature added to every outgoing message, verified against a public key published as a TXT record on a selector._domainkey subdomain. | Forgetting to publish the selector record after rotating keys, or signing with a key that does not match what DNS actually serves. |
| DMARC | A policy TXT record on _dmarc stating what to do when SPF or DKIM fail — monitor only, quarantine, or reject — plus an address for aggregate reports. | Jumping straight to p=reject before confirming, via reports, that every legitimate sending source actually passes. |
None of the three work in isolation. SPF alone breaks the moment a message is forwarded (the forwarding server is not in your SPF list). DKIM alone verifies the message but does not tell a receiver what to do about a failure. DMARC needs at least one of SPF or DKIM to pass, and ties the result to the domain shown in the visible "From" address — which is why all three are checked together, not as separate boxes to tick.
p=none. Publish a monitoring-only policy and read the aggregate reports for one to two weeks. This is where you discover sending sources you forgot about, before they start failing loudly.p=quarantine, then eventually p=reject.A brand-new sending domain, or a large migrated list, with perfect SPF/DKIM/DMARC can still land in spam — because mailbox providers also weigh sending reputation, which is built over time, not declared in DNS. A short, honest ramp matters: start with a smaller, most-engaged segment of the list, send at a modest volume for the first week or two, watch open rates and bounce rates, then widen. Reputation earned slowly holds; volume dumped on day one from a domain with no sending history reads as suspicious no matter how correct the records are.
p=reject immediately, before confirming every legitimate source passes — this can silently drop your own mail.“Deliverability is not a feature you switch on. It is a set of records and habits, configured correctly once and then maintained.”
Send a real campaign to an inbox you control. In Gmail, open the message and choose "Show original"; in Outlook, view the message's internet headers. Look for three lines near the top: spf=pass, dkim=pass and dmarc=pass, each referencing your sending domain. If any of them read fail or none, that is the record to fix first.
Separately, you can query your own domain's DNS directly: an SPF record is a TXT entry on the domain root starting with v=spf1; DKIM lives as a TXT entry on selector._domainkey.yourdomain; DMARC is a TXT entry on _dmarc.yourdomain starting with v=DMARC1. Any standard DNS lookup tool will resolve these — if a record does not resolve at all, it was never published, which is a different problem from a record that resolves but fails validation.
We configure and verify all three on your sending domain before your first campaign goes out, then keep watching the DMARC aggregate reports as your list and sending pattern evolve.
SPF, DKIM and DMARC set up correctly before your first send, plus bounce handling and suppression lists, included on every plan.
What is DMARC in plain words?
DMARC is a DNS record that tells receiving mail servers two things: what to do with a message claiming to be from your domain if it fails SPF and DKIM checks (monitor it, quarantine it, or reject it), and where to send a daily report about who is sending mail as your domain. It is the enforcement layer sitting on top of SPF and DKIM, not a replacement for either.
Do I need a dedicated IP?
Only at meaningful volume. A shared sending IP, warmed up properly and kept clean, is enough for most newsletters — its reputation is a pooled average across many well-behaved senders. A dedicated IP starts to matter once you are sending large volumes regularly and want your reputation to depend only on your own sending behaviour, not your neighbours'. Our Publisher tier includes one; smaller tiers share a warmed, monitored pool.
Why do my newsletters land in spam?
Almost always one of: a missing or misaligned SPF/DKIM/DMARC record, sending a large volume suddenly from a brand-new domain with no warm-up, a stale list full of dead addresses generating bounces and spam-trap hits, or content patterns (spammy subject lines, link-heavy templates, no plain-text part) that filters flag regardless of authentication. Check authentication first — it is the most common single cause and the easiest to verify.
How do I test my setup?
Send a real campaign to an inbox you control (Gmail, Outlook or similar), open the message, and view its original headers or source. Look for three lines: spf=pass, dkim=pass and dmarc=pass, each showing your sending domain. Separately, query your domain's own DNS for the SPF (TXT on the root), DKIM (TXT on the selector._domainkey subdomain) and DMARC (TXT on _dmarc) records to confirm they resolve to what you expect.