Do I need all three of SPF, DKIM and DMARC?

If you send more than about 5,000 messages a day to Gmail or Outlook.com addresses, yes: both require SPF, DKIM and a DMARC record. Below that, Gmail asks for at least SPF or DKIM, but in practice you should set up all three. It costs a few DNS records and removes the most common reason for rejection.

Does DMARC p=none meet the Gmail and Yahoo requirement?

Yes. The bulk-sender rules require a DMARC record and accept p=none. They also require that SPF or DKIM passes for the domain in the From: header, which is the part people miss.

SPF, DKIM and DMARC all pass. Why is my mail still going to spam?

Authentication only proves who sent the message. Inbox placement then depends on reputation: complaint rate, bounce rate, sending volume patterns, how recipients engage, and the reputation of the links in the message. A brand-new domain or a sudden jump in volume also counts against you.

Should SPF end with ~all or -all?

Either works once DMARC is in place, because DMARC decides what happens to failing mail. Never use +all, which authorizes every server on the internet to send as you.

Email Deliverability Setup: SPF, DKIM, DMARC, Sender Rules

What authentication does and what it doesn’t

SPF, DKIM and DMARC answer one question for the receiving mail server: did this message really come from the domain it claims? They don’t make anyone want your mail.

That distinction explains most deliverability confusion. Without authentication, large receivers reject or junk your mail no matter how good it is. With authentication, you’ve earned a hearing, and the receiver moves on to reputation: how recipients react to your mail, how many messages bounce, whether your volume looks normal. Authenticated spam still goes to spam.

So the work comes in two halves. The setup below is the mechanical half, done once and checked occasionally. The reputation half is ongoing, and it’s covered after the setup.

Step 0: list everything that sends as your domain

Do this before touching DNS. Every system that puts your domain in the From: header needs to be covered:

Your mailbox provider (Google Workspace, Microsoft 365, your own mail server)
Marketing email (newsletters, campaigns)
Transactional email from your application (password resets, receipts), often through a service like Amazon SES, SendGrid, Postmark or Mailgun
CRM, helpdesk, billing, HR and survey tools
Web servers and devices that send mail directly: contact forms, monitoring alerts, the office scanner

The ones people forget are the third and fourth groups, and they’re exactly the ones that start bouncing when DMARC is tightened. If you already have a DMARC record with rua=, the aggregate reports list every source for you.

Step 1: SPF, one record listing who may send

SPF is a TXT record at your domain listing the servers allowed to send mail for it:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:amazonses.com -all"

Each provider documents its own include: value. The rules that matter:

One record only. Two TXT records starting with v=spf1 is a permanent error, and receivers treat it as if you had no SPF. Merge them.
Ten DNS lookups at most. include, a, mx, ptr, exists and redirect each cost one, and the includes inside your includes count too. Go over ten and SPF fails with PermError. A few providers can push you past the limit; SPF PermError: too many DNS lookups covers how to count and cut.
End with ~all or -all. Once DMARC is enforcing, the difference matters little. +all means anyone may send as you; never use it.

One detail changes how you think about SPF: it checks the envelope sender (the Return-Path, or MAIL FROM), not the From: address people see. Most email service providers use their own bounce domain by default, so their SPF passes for their domain, not yours. Adding their include to your record doesn’t change that. For DMARC, what helps is setting up a custom return-path (a “custom MAIL FROM” or “bounce domain” such as bounce.example.com) in the provider’s dashboard, which makes SPF pass for your domain.

SPF also breaks on plain forwarding, because the forwarding server isn’t in your list. That’s why DKIM matters more.

Step 2: DKIM, a signature on every message

DKIM signs each message with a private key; receivers check it with a public key you publish in DNS at selector._domainkey.example.com. You don’t generate this yourself in most cases. Each sending service gives you the records:

Google Workspace: generate the key in the Admin console (Gmail, Authenticate email), publish the TXT record at google._domainkey, then click “Start authentication”. Until you do, Google signs with a gappssmtp.com domain that doesn’t help DMARC.
Microsoft 365: publish the two CNAMEs, selector1._domainkey and selector2._domainkey, whose targets the Defender portal gives you, then enable DKIM for the domain. Until then, mail is signed with your onmicrosoft.com domain.
Email service providers: look for “domain authentication” or “sender authentication”. You’ll get CNAMEs or TXT records to add.
Your own server (OpenDKIM, Rspamd and similar): generate a key pair, publish the public half, configure the signer.

Use 2048-bit RSA keys; Google recommends them. A 2048-bit key is longer than the 255-character limit of a single TXT string, so it’s published as one record containing several quoted strings. Some DNS panels split it for you, some need you to do it, and some break it by creating two records. Check the result with dig +short TXT google._domainkey.example.com: you should see one answer, possibly made of several quoted pieces.

What matters for DMARC is the d= domain in the signature. It has to be your domain (or a subdomain of it), not the provider’s. Every sender from step 0 needs this.

If signatures are present but failing, see DKIM fail and “body hash did not verify”.

Step 3: DMARC, tying it to the From: address

DMARC is a TXT record at _dmarc.example.com:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

It does two things. It tells receivers to treat a message as authenticated only if SPF or DKIM passes for the domain in the From: header (that’s “alignment”), and it says what to do with mail that fails. Start at p=none with rua= so you receive reports, use the reports to fix every legitimate sender from step 0, then move to quarantine and reject. The full rollout, with how to read the reports, is in DMARC p=none vs quarantine vs reject.

Domains that never send mail should publish v=spf1 -all and v=DMARC1; p=reject from day one. Nobody legitimate uses them, so there’s nothing to break, and spoofers lose an easy target.

Step 4: the server side, if you run your own

If all your mail goes through Google Workspace, Microsoft 365 or an email service provider, they handle this part. If you run your own outgoing mail server, or send from a VPS, you own it:

Reverse DNS. The sending IP needs a PTR record pointing to a hostname, and that hostname must resolve back to the same IP. Gmail requires this for all senders. The PTR is set by whoever owns the IP (your hosting or cloud provider), not in your domain’s DNS. See the reverse DNS and PTR setup guide; the reverse DNS lookup checks the round trip.
A matching HELO name. The server should introduce itself with that same hostname.
TLS. Gmail requires senders to use TLS. Any current mail server supports STARTTLS; make sure it’s turned on with a valid certificate.
Port 25 outbound. Many cloud providers block it by default for new accounts. If your server can’t connect out on 25, nothing else matters.

What Gmail, Yahoo and Microsoft require

Since February 2024, Gmail and Yahoo have enforced published rules for senders, and Microsoft announced similar rules for Outlook.com, Hotmail and Live addresses in 2025. The core is the same:

Requirement	Gmail, all senders	Gmail bulk senders	Yahoo bulk senders	Outlook.com high-volume senders
SPF and DKIM	SPF or DKIM	Both	Both	Both
DMARC record (p=none accepted)	Recommended	Required, aligned with SPF or DKIM	Required, aligned	Required, aligned with SPF or DKIM
Valid forward and reverse DNS for sending IPs	Required	Required	Required	—
TLS for the SMTP connection	Required	Required	—	—
One-click unsubscribe for marketing mail	—	Required	Required	Recommended
Spam complaint rate	Below 0.3%	Below 0.3%	Below 0.3%	—

A dash means the item isn’t part of that provider’s stated requirements as far as we know. Do it anyway; none of these are optional in practice.

Details worth knowing:

Gmail’s bulk threshold is about 5,000 messages in 24 hours to personal Gmail accounts, counted across everything sent from your primary domain. Google says that once you cross it, you’re treated as a bulk sender from then on, even if your volume drops.
Microsoft’s threshold is also 5,000 messages a day, to Outlook.com consumer addresses. Microsoft’s announcement said failing mail would go to junk first and later be rejected with 550 5.7.515.
Yahoo hasn’t, as far as we know, published a fixed volume threshold. Its requirements match Google’s on the core points. Check Yahoo’s Sender Hub for the current wording.
One-click unsubscribe means RFC 8058: two headers, covered by your DKIM signature, plus a visible unsubscribe link in the body. Requests must be honoured within two days. It applies to marketing and subscription mail, not to receipts or password resets.

List-Unsubscribe: <https://example.com/unsub?u=8f3a2c>, <mailto:unsub@example.com?subject=unsub-8f3a2c>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Spam rate is the user-reported rate shown in Google Postmaster Tools. Google asks you to stay below 0.1% and never reach 0.3%. Note that Postmaster Tools only shows data once you send enough volume to Gmail.

Enforcement has tightened in stages since the rules started, from temporary errors to outright rejections. The requirements themselves change occasionally. Before a big launch, check each provider’s sender guidelines page rather than relying on any summary, this one included.

Everything passes and mail still goes to spam

Once SPF, DKIM and DMARC pass with alignment, the remaining causes are about reputation and content. In rough order of how often they turn out to be the problem:

Complaints. Every “Report spam” click counts. Mail people didn’t clearly ask for, or can’t easily stop receiving, generates complaints. A visible unsubscribe link costs you a subscriber; a spam report costs you reputation with everyone at that provider.

List quality. Sending to addresses that don’t exist (old lists, typos, purchased or scraped lists) produces hard bounces, and some old addresses are recycled as spam traps. Remove hard bounces immediately and stop mailing people who haven’t opened anything in a long time.

New domain or new IP, sudden volume. Receivers have no history for a new domain or IP and are cautious. Start with your most engaged recipients and increase volume over a few weeks. A dedicated IP with low volume is often worse than a provider’s well-run shared pool.

Links and content. The reputation of every domain you link to counts. Public URL shorteners, tracking domains shared with spammers, and links to freshly registered domains all hurt. So does an image-only message with almost no text.

Blocklists. If your sending IP or domain is listed on a DNS blocklist, some receivers reject outright. The mail server blacklist removal checklist covers delisting. One caution about our own tool: in domain mode, the email check tests the IPs of your MX hosts (up to 4) against SpamCop, Barracuda, PSBL and Spamhaus, which tells you about your inbound servers. If you send through a different service, check your actual sending IP by entering it in the same tool. Spamhaus can’t be queried through public DNS resolvers, so it always shows as “Could not check” there; check it on Spamhaus’s own lookup page.

How to test the whole thing

Run the domain through the email check. It shows MX, SPF (with a count of lookup mechanisms in the top-level record), DMARC policy, DKIM under 18 common selectors, BIMI, MTA-STS, TLS-RPT and DANE. A DKIM “not detected” there can simply mean your provider uses a selector outside that list.
Send a real message from each sending system to a Gmail address and to an Outlook.com address. In Gmail, “Show original” shows SPF, DKIM and DMARC results at the top. Check that DKIM passes with your domain, not the provider’s.
Paste the headers into the email header analyzer to see the verdicts and every hop the message took.
Once you send to Gmail in volume, register your domain in Google Postmaster Tools and watch the spam rate.

For a fast record-by-record check of an existing domain with dig, see how to check MX, SPF, DKIM and DMARC records.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.