IT Infrastructure

SPF, DKIM and DMARC Explained: How a Small Nonprofit Sets Up Email Authentication

Cyanotype print seen from directly above, three round mesh sieves of different sizes overlapping on deep Prussian blue paper, each sieve leaving a crisp white silhouette with a finer grid of mesh than the one beneath it, a visual for SPF DKIM DMARC, the three DNS checks that work together to decide whether mail from a domain is trusted

SPF, DKIM and DMARC are three DNS records that let receiving mail servers check that a message from your domain really came from you. An SPF DKIM DMARC setup is now the price of reaching the inbox at Gmail, Yahoo and Outlook.com, and the bigger senders cannot skip any of the three.

Our post on Gmailify, POP fetch and Send As ending in January 2027 told nonprofits to check these records before staff change how they send. This piece explains each record with a sample for a made-up domain, example.org, then covers DMARC policies and reports, common mistakes, and what the big mailbox providers require.

The short version: SPF lists the servers allowed to send for your domain. DKIM signs each message. DMARC checks that one of them passed for the domain in the From line, and tells receivers what to do if not. Publish one SPF record naming every service that sends for you, turn on DKIM in each, start DMARC at p=none, read the reports, then tighten it.

Why moving off Gmailify raises the SPF DKIM DMARC question

With Gmail’s Send As, mail often went out through the org’s host. After the change, the same person may send from a phone app, webmail, or a new Google Workspace or Microsoft 365 mailbox. Each is a sending service. Each must be named in SPF or sign with DKIM, or receivers cannot tell it from a forger.

The SPF DKIM DMARC records live in DNS, often at the registrar rather than the email host. Our explainer on what DNS is and how it works covers TXT records and where to find your zone.

SPF: the list of servers allowed to send

SPF (Sender Policy Framework) is a TXT record at the root of your domain listing who may send mail for it. The standard is RFC 7208.

A sample for an org on Google Workspace that also uses a newsletter platform:

Host:  example.org
Type:  TXT
Value: v=spf1 include:_spf.google.com include:spf.newsletter-platform.example ~all

v=spf1 marks it as SPF. Each include: pulls in another service’s list of servers. The ~all at the end says any other server is probably not allowed, a "softfail."

Google’s SPF troubleshooting page recommends the tilde over a hyphen. It says "A hyphen can be overly restrictive and cause delivery issues for legitimate email." Each newsletter or donor platform publishes its own include value in its help pages.

SPF checks the hidden envelope sender (the Return-Path), not the From address people see. That gap is why DMARC exists.

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing message. The receiver checks it against your public key in DNS. If the message changed in transit, the check fails. The standard is RFC 6376.

A sample DKIM record:

Host:  s1._domainkey.example.org
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(long public key)

The s1 part is the selector. It lets one domain hold a key for each service. You do not make the key yourself. Each sending service generates it and shows you the record, or a CNAME, to add to DNS. Then you turn signing on.

Google’s email sender guidelines require a DKIM key of 1024 bits or longer for mail to personal Gmail accounts. Google recommends 2048 bits if your DNS host supports it.

DKIM has a gap too. RFC 6376 does not require the signing domain to match the From address.

DMARC: the rule that ties it to the From address

DMARC (Domain-based Message Authentication, Reporting and Conformance) closes both gaps. It asks one question: did SPF or DKIM pass for a domain that matches the From address? That match is called alignment. Under RFC 7489, only one of the two needs to pass and align.

A sample DMARC record:

Host:  _dmarc.example.org
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.org

p= is the policy, what you ask receivers to do with mail that fails. rua= is where daily summary reports go. Alignment is "relaxed" by default, so mail signed by news.example.org still aligns with example.org.

How SPF DKIM DMARC work together on one message

Say a staff member sends a renewal notice from a Workspace mailbox.

  1. The receiving server checks SPF. Google’s servers are in example.org’s SPF record through the include, so SPF passes.
  2. It checks DKIM. Workspace signed the message as example.org, so DKIM passes.
  3. It checks DMARC. The From address is example.org, and both passing domains match it. DMARC passes.

Now a forger sends a fake invoice "from" the same address. Their server is not in SPF, and they cannot sign as example.org without your private key. DMARC fails, and the receiver applies your policy.

Forwarding is the common edge case. When mail is forwarded, the forwarding server is not in your SPF record, so SPF fails. DKIM usually survives because the message is unchanged. That makes DKIM the more reliable of the two for DMARC.

DMARC policies: none, quarantine and reject

Policy What you ask receivers to do When to use it
p=none Deliver as normal, just send reports First weeks, while you find every sender
p=quarantine Treat failing mail as suspicious, usually the spam folder Once reports show all real mail passing
p=reject Refuse failing mail outright When you are sure, to stop spoofing fully

Google’s recommended DMARC rollout starts at none for at least a week. It then moves to quarantine for a small share of mail and raises that share over time. Google also says to set up SPF and DKIM at least 48 hours before DMARC.

Google’s samples use the pct= tag for that step. The newer DMARC standard drops pct, so do not rely on it.

Do not start at p=reject. A forgotten sender, such as a donation platform, will have its mail refused with no copy in any spam folder. Move up only after the reports are clean.

Reading DMARC reports

The rua address receives aggregate reports, usually once a day from each large provider. RFC 7489 says they are XML files, often gzipped. Each lists the servers that sent as your domain and whether SPF and DKIM passed and aligned.

Most small orgs point rua at a DMARC report service that turns the files into a dashboard. Reports are the feedback loop for your whole SPF DKIM DMARC setup.

What to look for in the first weeks:

  • A real service failing. Fix its DKIM before you tighten the policy.
  • Unknown servers passing. Find out what sends for you.
  • Unknown servers failing. Often spoofing, which quarantine and reject will stop.

The ruf tag asks for per-message failure reports. Most small orgs can leave it out.

Setting up SPF DKIM DMARC at a small nonprofit

Most of the work is the inventory, not the records.

  1. List every service that sends as your domain: staff mailboxes, website forms, the newsletter platform, the donor or membership database, and event registration.
  2. Build one SPF record with an include for each service. Check the lookup count.
  3. Turn on DKIM in each service and add the records it gives you.
  4. Wait two days, then publish DMARC at p=none with a rua address.
  5. Read reports for at least a week, longer if you have many senders. Fix each real sender that fails.
  6. Move to quarantine, then reject when the reports are clean.

Our guide to choosing an email marketing platform can help. Ask each vendor how it supports an SPF DKIM DMARC setup on your own domain.

Common SPF DKIM DMARC mistakes

  • Too many SPF lookups. RFC 7208 caps the terms that need DNS lookups at 10. Includes inside includes count too. Go over and SPF returns “permerror,” which is not a pass. Drop services you no longer use.
  • Two SPF records. A new vendor tells you to “add an SPF record,” and now you have two. RFC 7208 says that also returns permerror. Merge them into one.
  • Forgetting the newsletter platform. Staff mail passes, then the newsletter lands in spam once you move to quarantine.
  • Website forms that send “from” the visitor. A form that sends as the donor’s Gmail address will fail DMARC at Gmail. Send from your own domain and put the visitor in Reply-To.
  • Leaving p=none forever. It meets the bulk minimum but stops no spoofing.

Spoofed mail from a trusted domain is a staple of phishing attacks. Enforced DMARC is the main defense.

What Gmail, Yahoo and Outlook.com require (as of October 2026)

Gmail and Yahoo set a floor for every sender. All three want the full SPF DKIM DMARC set from bulk senders. Google’s sender guidelines FAQ defines bulk as close to 5,000 or more messages a day to personal Gmail accounts. Once you hit it, the status is permanent. Mail from subdomains counts toward the main domain.

Requirement Gmail Yahoo Outlook.com
All senders SPF or DKIM, valid PTR records, TLS, spam rate under 0.3% SPF or DKIM, valid PTR records, spam rate under 0.3% No separate list on the page we checked
Bulk threshold About 5,000 a day to personal Gmail Not defined on its page 5,000 or more to Microsoft consumer mail
Bulk authentication SPF and DKIM, DMARC at p=none or stricter, one aligned SPF and DKIM, DMARC at p=none or stricter, must pass SPF and DKIM pass, DMARC at p=none or stricter, one aligned
Bulk unsubscribe One-click for marketing mail, honored within 48 hours One-click header, honored within 2 days Not in the requirements we verified

Yahoo’s Sender Hub best practices say enforcement began in February 2024. Microsoft’s support page for error 550 5.7.515 covers Outlook.com, Hotmail and Live.com and shows what rejection looks like. Microsoft’s requirements took effect May 5, 2025, according to Mailgun’s summary of Microsoft’s announcement. Our post on email marketing in the AI inbox covers how these providers sort mail once it arrives.

On the standards: SPF and DKIM are Standards Track RFCs. DMARC was an Informational RFC until May 2026, when the IETF published RFC 9989 on the Standards Track. It replaces RFC 7489, keeps none, quarantine and reject, and drops the pct tag. It also moves reporting into two companion RFCs.

Frequently Asked Questions

What is the difference between SPF, DKIM and DMARC?

SPF lists who may send for your domain. DKIM signs each message. DMARC checks that one of them passed for the From domain and sets what happens if not.

Do small nonprofits need SPF DKIM DMARC records?

Gmail and Yahoo require SPF or DKIM from all senders, and all three from bulk senders. Most small nonprofits are under the bulk threshold. All three still help receipts reach the inbox and make your domain harder to spoof.

Can I have more than one SPF record?

No. A domain must have only one SPF record. Two records cause a permanent error, which does not count as a pass. Merge every service into one record.

Should my SPF record end in ~all or -all?

Google recommends ~all and warns that -all can cause delivery problems for real mail. DMARC does the enforcing.

Which DMARC policy should we start with?

Start with p=none and a rua address for reports. Move to quarantine after the reports show all your real mail passing, then to reject.

Where do DMARC reports go?

To the address in the rua tag. They arrive as XML files, usually daily. A report service can turn them into a readable summary.

Why does our newsletter fail an SPF DKIM DMARC check when staff mail passes?

The platform sends from its own servers. If it is not in your SPF record and does not sign with DKIM for your domain, its mail fails DMARC. Set up domain authentication in the platform.

Is DMARC still RFC 7489?

No. In May 2026 the IETF published RFC 9989, which replaces RFC 7489 and puts DMARC on the Standards Track. The three policies are the same.

Digital Matters

IT Infrastructure Desk