Your newsletter goes out to members and half of them never see it. A board member's message to the township lands in junk. The website's contact form sends a confirmation that nobody receives. The content is fine. The problem is that the receiving inbox can't confirm the mail really came from you.
That check runs on three records in your domain's settings: SPF, DKIM and DMARC. They sound technical, but each one answers a simple question, and most small organizations can get all three right in an afternoon once they know what is sending mail on their behalf.
Why this matters more than it used to
In February 2024, Google and Yahoo began requiring bulk senders to authenticate their mail. Google draws the line at 5,000 messages a day to Gmail addresses, and those senders need SPF, DKIM and DMARC. Microsoft followed for Outlook and Hotmail in May 2025.
Most boards and small businesses send far less than that, but the direction is clear. Google expects every sender to have at least SPF or DKIM, and unauthenticated mail is increasingly filtered or rejected. Setting all three up now means your mail keeps arriving as the rules tighten.
The three records in plain language
| Record | The question it answers | What it looks like |
|---|---|---|
| SPF | Which services may send email for this domain? | One text record on your domain listing your senders |
| DKIM | Was this message really signed by this domain, and unchanged? | A public key record each sending service gives you |
| DMARC | What should inboxes do when a message fails, and who gets the reports? | One text record at _dmarc on your domain |
SPF: the guest list
SPF is a single record listing every service allowed to send mail as your domain. A typical one looks like this:
v=spf1 include:_spf.google.com include:spf.your-newsletter-tool.example ~all
Each include adds a service, here Google Workspace and a newsletter tool. Every service tells you the exact include to add. The ~all at the end tells inboxes to treat anything else as suspicious.
DKIM: the signature
DKIM adds a digital signature to every message. Each service that sends for you, whether your email provider, newsletter tool or website, gives you its own DKIM record to add. Inboxes check the signature against that record, which proves the message came from an approved sender and wasn't altered on the way.
DMARC: the policy and the reports
DMARC ties the other two to the address people actually see in the From line, and tells inboxes what to do when a message fails. It starts gently:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourorganization.org
p=none means "deliver as normal, but send me reports". Once the reports show everything legitimate passing, you move to p=quarantine (send failures to spam) and eventually p=reject (refuse them).
The mistakes we see most
- Two SPF records. A domain may only have one. Adding a second for a new service breaks both. Merge them into a single record.
- Too many lookups. SPF allows at most ten DNS lookups, and each
includecan use several. A long list of services can quietly push you over, and then SPF fails for everyone. - Forgetting the website. Contact forms, membership sign-ups and donation receipts often send as your domain through a plugin or a separate service. If it isn't in SPF and signing with DKIM, it lands in spam, or never sends at all.
- Newsletters from a free address. Sending a Mailchimp or MailerLite newsletter "from" a Gmail or Yahoo address fails, because those providers tell inboxes not to trust mail that claims to come from them but is sent by someone else. Send from your own domain.
- Jumping straight to reject. Setting
p=rejectbefore you have checked the reports can block your own legitimate mail, such as invoices from your accounting software. - Nobody knows who controls the DNS. These records live wherever your domain's DNS is managed, which may not be your web host or your email provider. Find out, and make sure the login is in the organization's name.
Set them up in this order
- List everything that sends mail as your domain. Your email provider, newsletter tool, website forms, booking or donation platforms, and any accounting or invoicing software. This is the step everyone skips.
- Publish one SPF record that includes every service on the list.
- Turn on DKIM in each service and add the record it gives you. Most have a "verify your domain" or "authenticate" screen.
- Publish DMARC at
p=nonewith a reports address. - Read the reports for a few weeks. They show every service sending as you, and whether it passes. Fix anything legitimate that fails.
- Move to
p=quarantine, thenp=reject, once only spoofed mail is failing.
What it looked like for one association
When we repaired the Loyalist Business Association's website, two email problems turned out to be authentication problems:
- The website couldn't send mail at all. Its connection ran through an account nobody at the association could reach. We moved site email to a service in the association's own name with a verified domain, which unblocked 31 member accounts stuck waiting for verification emails.
- Newsletters went out under a third-party stand-in address. We connected the newsletter platform to the association's own domain with SPF and DKIM, so issues now come from a recognizable association address and fewer of them land in spam.
Beyond the DNS records
Authentication gets you through the door, but inboxes also watch how people react to your mail:
- Only send to people who asked. Never import a bought or borrowed list.
- Make unsubscribing easy. Every newsletter needs a working one-click unsubscribe link.
- Keep complaints low. Google asks bulk senders to keep reported spam under 0.3%.
- Use a consistent sender name and address so members recognize you.
The short version
- SPF lists who may send for you. One record only.
- DKIM signs each message. Turn it on in every service that sends as you.
- DMARC sets the policy and sends you reports. Start at
p=none. - Inventory every sender first, including your website.
If you'd rather not touch your DNS, our business email service sets up all three for your email, newsletter and website, and checks the reports for you. If your board is also sorting out who owns which address, start with role-based email for boards.

Tim Miller
Co-founder, Rocket 5 Studios
Creative director and developer. Tim worked at LucasArts on Star Wars and Indiana Jones properties, and now builds websites, apps and games at Rocket 5, including sites for community organizations on Amherst Island and nearby.
