How email deliverability and DNS setup work

This page explains why your organization’s domain needs DNS records before sending email, what those records do, and what the DKIM rotation and bounce-rate systems are protecting.

The short version

Email providers don’t automatically trust email from MapleGather on your behalf. When you save your From address at a new domain, MapleGather first asks your organization to prove it owns the domain by publishing one TXT record. Only once that record is found does MapleGather reserve the domain for your organization and register it with the email provider it sends through. [amended pre-merge 2026-10-21, c21 track BQ] Three DNS records — SPF, DKIM, and DMARC — are then your organization’s way of telling the internet’s email infrastructure: “MapleGather is authorized to send mail for us, and here’s a cryptographic proof you can verify.” Once they verify, MapleGather sends from your domain.

How it works

Why DNS records matter for email

When your member’s email provider receives a message claiming to be from yourorg.org, it can’t tell by looking at the message whether that claim is true. SPF, DKIM, and DMARC are the standard way domains prove their sending identity — they’re published in DNS, which is publicly readable and controlled only by the domain owner.

SPF (Sender Policy Framework) tells receiving servers which services are authorized to send mail for a domain. MapleGather’s email provider checks SPF on a bounce (Return-Path) subdomain of yours, pm-bounces. followed by your domain, which you point at the provider with a CNAME record. Because it lives on that subdomain, your domain’s existing SPF record doesn’t change.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing email. The signing key is generated and held by MapleGather’s email provider — MapleGather itself never generates or holds it. Receiving servers use the public key you publish in DNS (a TXT record) to verify the signature. This confirms the email genuinely came from your authorized sender and wasn’t modified in transit.
DMARC (Domain-based Message Authentication, Reporting & Conformance) tells receiving servers what to do when SPF or DKIM checks fail — for example, quarantine the message or reject it. It also enables reporting so you can see if anyone is impersonating your domain.

Why ownership is proven first

A domain can belong to only one organization in MapleGather. If saving an address were enough to reserve its domain, anyone could save an address at a domain they don’t own and block the real owner. So saving an address reserves nothing. MapleGather shows a TXT record at _maplegather-verify. followed by your domain, with a value generated for your organization and that domain, and the domain is reserved only once MapleGather finds that exact value in your DNS. Only someone who controls the domain’s DNS can publish it.

Several organizations can be waiting on the same domain. Whichever publishes its own record and passes the check first gets the domain; the others are then told “Another organization proved this domain first” by Check ownership.
One organization’s record never proves the domain for another — each value is different, and it can’t be guessed before MapleGather shows it.
If DNS can’t be read, the check counts as not found. MapleGather never reserves a domain it couldn’t confirm.
There’s no expiry. An ownership check can wait as long as you need, and while it waits your current From address (if you have one) keeps working.

After ownership is proven, the SPF, DKIM, and DMARC records are a second round. They let MapleGather’s email provider send and sign for the domain. [amended 2026-10-21, c21 track BQ]

What happens while DNS is unverified

Until all three records are verified, MapleGather sends your emails from a functional fallback address — usually an address like riverside-club@notifications.maplegather.com, or MapleGather’s own no-reply@maplegather.com in some cases (for example, when your organization’s short name reads like a role mailbox such as support or billing). Your members still receive the emails, but they see the fallback address as the sender, not your organization’s domain. The fallback covers everything your organization sends to members and contacts, including the test send; notices MapleGather sends to your organization itself keep MapleGather’s own sender.

Once all three records are verified, emails come from your configured From address. Once a domain is registered for your organization, the deliverability page says which address mail is going out from; while ownership is pending, the ownership card names the current sender. [amended pre-merge 2026-10-21, panel r1] If a record stops verifying later, mail goes back to the fallback the next time the records are checked — when an admin selects Verify, or while the deliverability page is open (up to 20 automatic checks per visit, paused while the tab is hidden) — so your email keeps sending either way. MapleGather’s email provider keeps a DKIM key verified once it has passed, so each check also looks your DKIM record up in DNS: if you remove or change it, the DKIM card shows Failed again and says the record is no longer published. [amended pre-merge 2026-10-20, c21 E panel-r2]

DKIM key rotation

You can rotate your DKIM signing key when you choose — as regular security hygiene, for a compliance audit, or if you suspect a key was compromised.

When you rotate:

MapleGather asks its email provider for a new key pair. The provider generates it.
The new key’s public record appears on a New DKIM key card, at a new DNS name. You add it as a new TXT record and keep the current one.
Your current key keeps signing your email until the new record verifies, so sending is never interrupted.
When the new record verifies, the new key becomes your DKIM key.

If the new record hasn’t verified within 7 days, the dashboard shows “DKIM rotation incomplete — verify DNS record”. That’s a reminder, not a cut-off — the current key is still signing.

Bounce rate and sender reputation

When emails can’t be delivered — because an address doesn’t exist, a mailbox is full, or a server is blocking mail from your domain — they generate a bounce. Email infrastructure providers track senders’ bounce rates. A high bounce rate signals poor list hygiene and reduces trust in your domain.

MapleGather tracks your 7-day rolling bounce rate and alerts you when it exceeds 2% — the threshold most email providers use as a signal to start applying more aggressive spam filtering. Acting on a high bounce rate (correcting or removing invalid addresses) protects your sending reputation and keeps future emails landing in inboxes.

Why it works this way

These mechanisms exist because email was designed before internet-wide authentication — the From: header can say anything. SPF, DKIM, and DMARC were developed after the fact as retrofitted solutions to prove sender identity. They’re widely adopted but require domain-owner participation, which is why you need to add the DNS records yourself.

The current DKIM key keeps signing until the new one is in DNS because a switch to a key nobody has published yet would leave your mail unverifiable. Waiting for the new record to verify means there’s never a moment when your email is signed with a key receivers can’t find.

Edge cases and boundaries

A domain you own: your From address must be at a domain your organization controls. Public email providers (such as Gmail, Yahoo, Outlook, AOL, and AIM) and MapleGather’s own domains can’t be used, because no organization can publish DNS records for them.
One organization per domain: a domain can belong to only one organization in MapleGather — the first to prove it owns the domain (see Why ownership is proven first). If another organization has already proven it, Check ownership refuses it (“Another organization proved this domain first…”) without naming the other organization; the domain stays registered to that organization, and MapleGather has no way to move a proven domain, so the cure is an address at a different domain. [amended pre-merge 2026-10-21, c21 track BQ; 2026-11-01, c21 track CM] After the ownership check, a domain the email provider already has a record for that no organization here holds is refused too (“Our email provider already has a record for this domain that no organization here holds…”) — the record may be an orphan, possibly left by your own organization’s earlier attempt that timed out; MapleGather doesn’t take such a record over or remove it automatically, and nothing in the product releases it, so use an address at a different domain. [amended pre-merge 2026-10-20, c21 E panel-r2; 2026-11-01, c21 track CM]
Look-alike domains: an internationalized domain that only looks like a MapleGather domain or a public email provider’s domain (for example, maplegather.com spelled with a Cyrillic “а”) is refused like the domain it imitates. [amended pre-merge 2026-10-21, c21 track BQ]
Your existing SPF record: you don’t need to edit it — MapleGather’s SPF check uses the separate pm-bounces. CNAME record.
DNS propagation time: DNS changes can take anywhere from minutes to 48 hours to appear globally. Verification checks may fail temporarily while propagation is still in progress.