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
Section titled “The short version”Email providers don’t automatically trust email from MapleGather on your behalf. Three DNS records — SPF, DKIM, and DMARC — are 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.” Without those records, emails are more likely to land in spam or get rejected.
How it works
Section titled “How it works”Why DNS records matter for email
Section titled “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) lists which services (including MapleGather’s infrastructure) are authorized to send mail on behalf of your domain. Receiving servers check this list.
- DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing email, derived from a private key MapleGather holds. Receiving servers use the public key you publish in DNS 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.
What happens while DNS is unverified
Section titled “What happens while DNS is unverified”Until all three records are verified, MapleGather sends your emails from a functional fallback address — for example, yourorg@notifications.maplegather.com. Your members still receive the emails, but they see the fallback address as the sender, not your organization’s domain. The emails also lack the trust signals that the three DNS records provide.
Once all three records are verified, emails come from your configured From address with full authentication.
DKIM key rotation
Section titled “DKIM key rotation”The DKIM private key MapleGather uses to sign your emails is rotated periodically. Rotation is a security hygiene practice: if a signing key is ever compromised, a recent rotation limits the exposure window.
When rotation happens:
- MapleGather generates a new public/private key pair.
- You update the public key in DNS (the DKIM record value changes).
- The old key stays valid for 7 days so any emails already in transit can still be verified.
- On day 8, only the new key signs outgoing mail.
If you don’t update the DNS record within 7 days, the dashboard shows a rotation-overdue state, and emails dispatched after that point can’t be verified by receiving mail servers using the old key.
Bounce rate and sender reputation
Section titled “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
Section titled “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 7-day DKIM overlap window exists because email can be delayed for legitimate reasons — a member’s mailbox might be full, and the message queued for retry. An immediate cutover to a new key would make those in-transit messages unverifiable.
Edge cases and boundaries
Section titled “Edge cases and boundaries”- AOL and AIM domains: If your From address uses
@aol.comor@aim.com, those providers block email relayed through third-party services. You need a domain you own as your From address. - Multiple DNS providers: SPF records must be merged if your domain already has an SPF record — you can only have one per domain. A second SPF record doesn’t work additively; it confuses receiving servers.
- 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.